Token导航 LogoToken导航

Agent Skill · 前端设计

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

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

tech-docs-generator 是前端设计类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为需要联网;许可证信息还不明确,第三方扫描有未通过项,按安装量在前端设计类的 10,216 个 Skill 里排第 5,430。

总安装 675周安装 29GitHub Stars 1下载 237核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

复制提示词发给支持本地命令或 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

这个 Skill 是做什么的

前端设计类 Skill 关注页面结构、视觉规范和组件写法,输出通常是可运行的界面代码。

用于辅助文档和 Markdown 稿件整理。适合提炼结构、统一术语或补齐章节。应保留项目已有事实和路径信息。tech-docs-generator 属于前端设计类 Skill,可作为该场景下的辅助能力补充。涉及对外文案时需控制语气避免夸大。不要把未确认信息写成确定结论。

适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

来源仓库内路径:skills/tech-docs-generator

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/pixel-process-ug/superkit-agents --skill tech-…;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要需要联网,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

tech-docs-generator 怎么安装?

在终端执行 npx skills add https://github.com/pixel-process-ug/superkit-agents --skill tech-docs-gener…。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

tech-docs-generator 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

tech-docs-generator 需要什么权限?

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

tech-docs-generator 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

tech-docs-generator 用的人多吗?

公开数据是累计安装 675 次,近一周安装 29 次,下载 237 次,GitHub 1 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

tech-docs-generator 安全吗?

第三方扫描有未通过项,风险较高。除非你确认过源码,否则不建议直接安装到常用环境。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。

先想清楚的地方

  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方扫描存在提醒项或未通过项,需要人工逐条确认。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理前端设计类任务、又不想每次都手写提示词的人。

不太适合

  • 需要明确授权才能用到公司项目里的场景。
  • 需要厂商级技术支持和 SLA 的生产系统。

前端设计类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
frontend-design

前端设计 · Codex、Claude

8,823,360126,072只读MIT通过
vercel-composition-patterns

Vercel 组合模式 · Codex、Claude

3,858,81625,893需要联网MIT通过
vercel-react-native-skills

Vercel React native skills 前端 · Codex、Claude

2,468,66425,878只读MIT通过
adapt

adapt 搜索 · Codex、Claude

2,027,04023,125操作浏览器未明确通过
bolder

bolder 分析 · Codex、Claude

2,004,28823,130只读未明确通过
tech-docs-generator

技术文档生成器 · 本页

6751需要联网未明确未通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

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.

平台分布

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 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在提醒或未通过项,安装前请自行复核。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills