Token导航 LogoToken导航TokenDH.com
前端设计需要联网github未标认证来源可访问许可证需确认审计异常

tech-docs-generator技术文档生成器

Agent Skill

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

总安装

675

周安装

29

GitHub Stars

1

下载量

237
CodexClaudeCursorGemini CLI

安装说明

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

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

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

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

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/pixel-process-ug/superkit-agents --skill tech-docs-generator

简介

用于辅助文档和 Markdown 稿件整理。

  • 适合提炼结构、统一术语或补齐章节。
  • 应保留项目已有事实和路径信息。tech-docs-generator 属于前端设计类 Skill,可作为该场景下的辅助能力补充。
  • 涉及对外文案时需控制语气避免夸大。
  • 不要把未确认信息写成确定结论。适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

SKILL.md

Technical Documentation Generator

Overview

Generate comprehensive technical documentation by analyzing the actual codebase. Produces API references, architecture overviews, getting started guides, and component documentation with real examples extracted from project code, not invented ones.

Announce at start: "I'm using the tech-docs-generator skill to create documentation."

Phase 1: Codebase Analysis

Scan the codebase to identify what needs documenting. Deploy parallel subagents via the Agent tool (up to 500, with subagent_type="Explore") to analyze:

Analysis TargetWhat to Capture
Exported functions/classesPublic API surface, signatures, return types
API routes/endpointsREST, GraphQL, tRPC definitions with methods
ConfigurationEnv vars, config files, feature flags
Database schemasModels, migrations, relationships
Component hierarchyUI components and their props/interfaces
Type definitionsInterfaces, types, Zod schemas, enums
Entry pointsCLI commands, main files, server bootstrap
DependenciesExternal packages and their roles

STOP after analysis — present a summary of what was found and ask which documentation types are needed.

Phase 2: Documentation Type Selection

TypeWhen to UseOutput PathTypical Size
API ReferenceDocumenting endpoints or public functionsdocs/api-reference.md200-1000 lines
Architecture OverviewExplaining system design and data flowdocs/architecture.md100-300 lines
Getting StartedOnboarding new developersdocs/getting-started.md50-150 lines
Component DocsDocumenting UI componentsdocs/components/[name].md50-200 lines
Contributing GuideExplaining how to contributedocs/contributing.md50-100 lines
Configuration GuideDocumenting config optionsdocs/configuration.md50-200 lines
Migration GuideDocumenting version upgradesdocs/migration/v[X]-to-v[Y].md50-150 lines

Ask the user which type(s) they need if not specified. If multiple types are requested, dispatch parallel subagents via the Agent tool — one per doc type.

Phase 3: Generate Documentation

Dispatch doc-generator agent with:

  • File analysis results from Phase 1
  • Documentation type selected in Phase 2
  • Existing documentation (to update, not replace)
  • Project context from memory files

STOP after generation — present each section for review before saving.

Documentation Format Standards

API Reference format:

## `functionName(param1, param2)`

Description of what this function does.

**Parameters:**
| Name | Type | Required | Description |
|------|------|----------|-------------|
| param1 | `string` | Yes | What it does |
| param2 | `Options` | No | Configuration options |

**Returns:** `Promise<Result>`

**Example:**

const result = await functionName('value', { option: true });


**Throws:** `ValidationError` if param1 is empty

Architecture Overview format:

## System Architecture

### Overview
[High-level description with ASCII diagram]

### Components
| Component | Responsibility | Key Files |
|-----------|---------------|-----------|

### Data Flow
[How data moves through the system — request lifecycle]

### Key Decisions
| Decision | Rationale | Alternatives Considered |
|----------|-----------|------------------------|

Getting Started format:

## Prerequisites
[Required tools, versions, accounts]

## Installation
[Step-by-step with copy-pasteable commands]

## Configuration
[Required env vars and config]

## First Run
[How to start the app and verify it works]

## Next Steps
[Links to deeper documentation]

Phase 4: Review and Save

Present documentation section by section:

  1. Ask after each section: "Does this accurately describe the code?"
  2. Cross-reference with actual code to verify accuracy
  3. Include real examples from the codebase — never invented ones
  4. After approval, save to docs/ directory
  5. Commit with message: docs(<scope>): add/update <doc-type>

Accuracy Verification Checklist

CheckHow to Verify
Function signatures match codeRead the source file
Examples actually workTrace the code path
Config options are currentCheck actual config files
Dependencies listed are installedCheck package.json / requirements
File paths referenced existGlob for the files

Anti-Patterns / Common Mistakes

MistakeWhy It Is WrongWhat To Do Instead
Inventing code examplesReaders copy-paste and get errorsExtract real examples from the codebase
Documenting internal/private APIsCreates coupling to implementationOnly document public/exported surface
Writing docs that duplicate source codeGoes stale immediatelyReference behavior, not implementation
Giant monolithic doc fileHard to navigate and maintainSplit by concern (API, architecture, config)
Documenting aspirational behaviorMisleads users about current capabilitiesDocument what actually works today
Skipping the analysis phaseMiss important APIs or get signatures wrongAlways analyze code first
Not verifying examples compile/runBroken docs worse than no docsTest every code example

Anti-Rationalization Guards

  • Do NOT generate documentation without first analyzing the actual code
  • Do NOT invent examples — every code snippet must come from or be verified against the codebase
  • Do NOT document private/internal APIs unless explicitly requested
  • Do NOT skip the review phase — present each section for user verification
  • Do NOT duplicate information already covered in other docs — reference instead

Integration Points

SkillRelationship
prd-generationUpstream: PRD defines what needs documenting
self-learningParallel: both analyze codebase; self-learning populates memory files used here
api-designUpstream: API design specs inform API reference docs
spec-writingParallel: specs define behavior; docs explain usage
reverse-engineering-specsUpstream: reverse-engineered specs provide behavioral understanding
code-reviewDownstream: reviewer checks if docs were updated alongside code changes

Verification Gate

Before claiming documentation is complete:

  1. VERIFY all public APIs are documented with correct signatures
  2. VERIFY code examples actually work (not invented)
  3. VERIFY cross-references link to existing content
  4. VERIFY documentation matches current code state
  5. VERIFY the user has approved each section
  6. RUN any documented commands to confirm they work

Concrete Example: API Reference Entry

Given this source code:

export async function createUser(data: CreateUserInput): Promise<User> {
  // validates, hashes password, inserts into DB
}

Generate this documentation:

## `createUser(data)`

Create a new user account with the provided details.

**Parameters:**
| Name | Type | Required | Description |
|------|------|----------|-------------|
| data | `CreateUserInput` | Yes | User registration data |

**`CreateUserInput` shape:**
| Field | Type | Required | Constraints |
|-------|------|----------|-------------|
| email | `string` | Yes | Valid email format |
| password | `string` | Yes | Minimum 8 characters |
| name | `string` | Yes | 1-100 characters |

**Returns:** `Promise<User>` — the created user object (password excluded)

**Throws:**
- `ValidationError` — if input fails validation
- `ConflictError` — if email already exists

Skill Type

Flexible — Adapt documentation depth and format to project needs while preserving the analyze-first principle and accuracy verification.

适合场景

01

用户想查找某类 Agent Skill 时

02

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

03

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

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

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

能力 4

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

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

平台分布

Codex

38.46%
按下载量换算91

Claude

28.03%
按下载量换算66

Cursor

17.61%
按下载量换算42

Gemini CLI

8.61%
按下载量换算20

安全审计

Gen Agent Trust Hub

未通过

Socket

通过

Snyk

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在 warning/failed 结果,不能写成本站确认安全。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills