Token导航 LogoToken导航TokenDH.com
研究检索敏感数据github未标认证来源可访问clear审计通过

docs-starter-kit文档入门套件

Agent Skill

用于辅助文档、README、Markdown、说明文和内容稿件的整理与改写。它适合让 Agent 提炼结构、补齐章节、统一术语、检查链接或把零散材料整理成可读文档。使用时应保留项目已有事实、命令和路径,不要把未确认的信息写成确定结论;涉及对外文案时,还需要控制语气,避免过度营销或夸大能力。

总安装

2,182

周安装

90

GitHub Stars

32

下载量

713
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

3

许可证

MIT

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:docs-starter-kit(文档入门套件)
来源仓库:https://github.com/patricio0312rev/skills
仓库路径:skills/docs-starter-kit
安装命令:
npx skills add https://github.com/patricio0312rev/skills --skill docs-starter-kit
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。不同来源提供的安装方式可能略有差异;本站展示可直接复制的安装命令,安装前请核对来源页面。

skills.shnpx skills
npx skills add https://github.com/patricio0312rev/skills --skill docs-starter-kit

简介

一键生成包含 README、CHANGELOG、CONTRIBUTING 等全套专业文档。

  • 根据开源项目、内部工具或应用类项目自动匹配模板。
  • 支持填充项目名称、特性列表、安装步骤等关键元数据。
  • 包含许可证选择、CI/CD 集成建议等扩展配置选项。
  • 输出结果需经人工审阅确保信息真实性与完整性。docs-starter-kit 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

SKILL.md

Docs Starter Kit

Generate complete, professional documentation for any project.

Core Workflow

  1. Determine project type: OSS public, internal, library, application
  2. Select templates: Choose appropriate docs based on project type
  3. Customize content: Fill in project-specific information
  4. Add sections: Include relevant sections for the project
  5. Review completeness: Ensure all essential docs are present
  6. Format consistently: Apply consistent style and structure

Essential Documentation Files

README.md (Required)

Project overview and getting started guide

  • Project description and purpose
  • Features and capabilities
  • Quick start guide
  • Installation instructions
  • Usage examples
  • Configuration options
  • Contributing link
  • License information

CONTRIBUTING.md (Recommended)

Guide for contributors

  • How to contribute
  • Development setup
  • Code style guidelines
  • Testing requirements
  • Pull request process
  • Code of conduct link

LICENSE (Required for OSS)

Project license

  • MIT, Apache 2.0, GPL, BSD, etc.
  • Copyright holder and year

CODE_OF_CONDUCT.md (OSS Best Practice)

Community guidelines

  • Expected behavior
  • Unacceptable behavior
  • Enforcement procedures
  • Contact information

SECURITY.md (Recommended)

Security policy and reporting

  • Supported versions
  • Reporting vulnerabilities
  • Response timeline
  • Security update process

CHANGELOG.md (Recommended)

Version history

  • Notable changes per version
  • Breaking changes highlighted
  • Release dates
  • Following Keep a Changelog format

README.md Template

# Project Name

Brief description of what this project does and who it's for.

## Features

- ✨ Feature 1
- 🚀 Feature 2
- 🎯 Feature 3

## Quick Start

Clone the repository

git clone https://github.com/username/project-name.git

Install dependencies

npm install

Run development server

npm run dev

Installation

Prerequisites

  • Node.js 20+
  • npm or pnpm
  • PostgreSQL 15+ (if applicable)

Setup

  1. Clone and install: git clone <repo> npm install
  2. Configure environment: cp.env.example.env # Edit.env with your values
  3. Setup database (if applicable): npm run db:migrate npm run db:seed
  4. Start development: npm run dev

Usage

Basic Example

import { something } from "project-name";

const result = something();

Advanced Usage

[More detailed examples]

Configuration

Available environment variables:

VariableDescriptionDefault
API_KEYAPI authentication key-
PORTServer port3000
DATABASE_URLDatabase connection-

Documentation

Testing

# Run all tests
npm test

# Run with coverage
npm run test:coverage

# Run specific test file
npm test path/to/test

Deployment

[Deployment instructions]

Built With

Contributing

Contributions are welcome! Please read CONTRIBUTING.md for details on our code of conduct and the process for submitting pull requests.

License

This project is licensed under the MIT License - see the LICENSE file for details.

Authors

Acknowledgments

  • Hat tip to anyone whose code was used
  • Inspiration
  • References
## CONTRIBUTING.md Template

Contributing to [Project Name]

Thank you for your interest in contributing! This document provides guidelines for contributing to this project.

Code of Conduct

This project adheres to a Code of Conduct. By participating, you are expected to uphold this code.

How Can I Contribute?

Reporting Bugs

Before creating bug reports, please check existing issues to avoid duplicates. When creating a bug report, include:

  • Clear and descriptive title
  • Detailed description of the issue
  • Steps to reproduce
  • Expected vs actual behavior
  • Environment details (OS, Node version, etc.)
  • Screenshots if applicable

Suggesting Enhancements

Enhancement suggestions are tracked as GitHub issues. When creating an enhancement suggestion, include:

  • Clear and descriptive title
  • Detailed description of the proposed feature
  • Explanation of why this enhancement would be useful
  • Possible implementation approach

Pull Requests

  1. Fork the repository
  2. Create a feature branch (git checkout -b feature/amazing-feature)
  3. Make your changes
  4. Add tests for new functionality
  5. Ensure all tests pass (npm test)
  6. Commit using conventional commits (git commit -m 'feat: add amazing feature')
  7. Push to your fork (git push origin feature/amazing-feature)
  8. Open a Pull Request

Development Setup

See README.md for initial setup instructions.

Development Workflow

# Install dependencies
npm install

# Start development server
npm run dev

# Run tests in watch mode
npm run test:watch

# Run linter
npm run lint

# Format code
npm run format

Code Style

  • Follow existing code style
  • Use TypeScript for all new code
  • Run npm run lint and npm run format before committing
  • Write meaningful commit messages following Conventional Commits

Commit Message Format

<type>(<scope>): <description>

[optional body]

[optional footer]

Types: feat, fix, docs, style, refactor, test, chore

Testing

  • Write tests for all new features
  • Maintain test coverage above 80%
  • Run tests before submitting PR
  • Include both unit and integration tests where appropriate

Documentation

  • Update README.md if adding features
  • Document new environment variables
  • Add JSDoc comments for public APIs
  • Update CHANGELOG.md for notable changes

Review Process

  1. Automated checks must pass (tests, linting, build)
  2. At least one maintainer approval required
  3. Address all review comments
  4. Maintainer will merge when approved

Questions?

Feel free to open an issue with your question or contact maintainer@email.com.

License

By contributing, you agree that your contributions will be licensed under the same license as the project.

## SECURITY.md Template

Security Policy

Supported Versions

VersionSupported
2.x.x:white_check_mark:
1.x.x:x:

Reporting a Vulnerability

We take security seriously. If you discover a security vulnerability, please follow these steps:

Do Not

  • Open a public GitHub issue
  • Disclose the vulnerability publicly before we've addressed it

Do

  1. Email us at security@projectname.com
  2. Include details:

- Description of the vulnerability - Steps to reproduce - Potential impact - Suggested fix (if any)

What to Expect

  • Acknowledgment: Within 48 hours
  • Initial assessment: Within 1 week
  • Regular updates: Every 2 weeks
  • Resolution: Depends on severity and complexity

Disclosure Policy

  • We will investigate and respond promptly
  • We will work with you to understand the issue
  • We will keep you informed of our progress
  • We will credit you for the discovery (unless you prefer to remain anonymous)

Security Update Process

  1. Patch is developed and tested
  2. Security advisory is prepared
  3. New version is released
  4. Advisory is published
  5. Users are notified

Best Practices

When using this project:

  • Keep dependencies up to date
  • Use environment variables for secrets
  • Enable security features in production
  • Follow principle of least privilege
  • Regularly review access logs

Known Security Considerations

[Document any known security considerations or limitations]

Security-Related Configuration

[Document security-related configuration options]


## CODE_OF_CONDUCT.md Template

Code of Conduct

Our Pledge

We pledge to make participation in our project a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.

Our Standards

Positive Behavior

  • Using welcoming and inclusive language
  • Being respectful of differing viewpoints and experiences
  • Gracefully accepting constructive criticism
  • Focusing on what is best for the community
  • Showing empathy towards other community members

Unacceptable Behavior

  • Trolling, insulting/derogatory comments, and personal attacks
  • Public or private harassment
  • Publishing others' private information without permission
  • Other conduct which could reasonably be considered inappropriate

Our Responsibilities

Project maintainers are responsible for clarifying standards of acceptable behavior and will take appropriate and fair corrective action in response to unacceptable behavior.

Scope

This Code of Conduct applies within all project spaces and when representing the project or its community.

Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the project team at [conduct@projectname.com]. All complaints will be reviewed and investigated promptly and fairly.

Attribution

This Code of Conduct is adapted from the Contributor Covenant, version 2.0.


## LICENSE Templates

### MIT License

MIT License

Copyright (c) [year] [fullname]

Permission is hereby granted, free of charge, to any person obtaining a copy...


### Apache 2.0

Apache License Version 2.0, January 2004 http://www.apache.org/licenses/


## CHANGELOG.md Template

Changelog

All notable changes to this project will be documented in this file.

The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.

[Unreleased]

Added

  • New feature X

Changed

  • Updated dependency Y

Fixed

  • Bug Z

[1.0.0] - 2024-01-15

Added

  • Initial release
  • Feature A
  • Feature B

Security

  • Fixed vulnerability in dependency

[unreleased]: https://github.com/user/project/compare/v1.0.0...HEAD [1.0.0]: https://github.com/user/project/releases/tag/v1.0.0


## Additional Documentation

### API.md

API reference documentation

### ARCHITECTURE.md

System design and architecture

### DEPLOYMENT.md

Deployment instructions

### DEVELOPMENT.md

Development environment setup

### FAQ.md

Frequently asked questions

### TROUBLESHOOTING.md

Common issues and solutions

## Documentation Best Practices

1. **Keep it updated**: Review docs with each release
2. **Be concise**: Clear and to the point
3. **Use examples**: Show, don't just tell
4. **Link related docs**: Cross-reference appropriately
5. **Consider audience**: Write for your users' level
6. **Use consistent formatting**: Follow style guides
7. **Include visuals**: Diagrams, screenshots, examples

## Project Type Variations

### Library/Package

Focus on: API reference, usage examples, installation

### Application

Focus on: Setup, configuration, deployment

### CLI Tool

Focus on: Commands, options, examples

### Internal Tool

Focus on: Access, authentication, company-specific processes

## Checklist

For complete project documentation:

- README.md with clear description and quick start
- CONTRIBUTING.md with development guidelines
- LICENSE file (if open source)
- CODE_OF_CONDUCT.md (if open source)
- SECURITY.md with vulnerability reporting
- CHANGELOG.md for version history
- .github/ISSUE_TEMPLATE/ for bug reports and features
- .github/PULL_REQUEST_TEMPLATE.md
- docs/ folder for additional documentation
- API reference (if library)
- Architecture documentation (if complex)

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

04

需要参考平台分布和安装热度时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

能力 5

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Claude Code

26.32%
按下载量换算188

Gemini CLI

23.62%
按下载量换算168

Antigravity

16.96%
按下载量换算121

windsurf

11.53%
按下载量换算82

Codex

7.99%
按下载量换算57

OpenCode

3.67%
按下载量换算26

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

敏感数据

该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。

来源信息

继续浏览同类 Skills