Description

从代码和 UI 逆向提取业务逻辑，生成不同类型的项目文档（BRD/MRD、PRD、HLD概要设计、DDD领域设计、LLD详细设计、编码指南、测试文档BDD/SIT/E2E/UAT、运营手册、SLI/SLO监控文档、CI/CD文档）。约束文档的写作维度、分析视角和格式规范。适用于任意项目类型（Web、后端服务、移动...

README (SKILL.md)

\r \r

业务文档生成器\r

Name: Code To Doc
Author: suifei

\r 核心定位：文档漂移是熵增，不是疏忽。代码有 CI/lint/编译错误作为反馈回路，文档没有——它必然腐烂。此 skill 是解法：以代码为真相源，持续生成或校准文档，把文档维护从"事后补救"变成"代码变更不可分割的一部分"。\r \r 操作角色：本 skill 以技术专家身份工作，服务于以下使用者（根据所生成的文档类型匹配）：开发者/架构师（LLD/HLD/DDD/编码指南）、产品经理（PRD/BRD/MRD）、QA 工程师（测试文档）、SRE/运维（SLI/SLO/监控文档）、DevOps（CI/CD 文档）、运营/管理人员（运营手册）。与用户的交互语言保持技术精确性；输出文档的语言和深度根据各文档类型的目标受众独立调整。\r \r ---\r \r

第零步：确定模式与文档类型\r

\r 在做任何事之前，先明确两件事。\r \r

模式选择\r

\r A. 生成模式：文档不存在或需要从头建立，从代码逆向提炼后生成。 \r B. 反向同步模式：文档已存在但可能与代码漂移，以代码为真相源校准文档。\r \r 按以下步骤确定模式：\r \r

用户提到以下任一关键词 → 进入模式 B（反向同步），立即转至 references/reverse-sync.md 按其流程工作，停止阅读本文件，不执行下方四轮工作流： \r
- "更新文档"、"同步文档"、"代码改了文档没跟上"、"文档和代码对不上"、"文档漂移"、"反向同步"\r \r
其他情况（"生成文档"、"写文档"、"没有文档"、"帮我写个 HLD/PRD/LLD"、"整理架构文档"、"出测试用例"等）→ 进入模式 A（生成），继续下方流程。\r \r ---\r \r

文档类型选择（模式 A 必须确认）\r

\r

⛔ 硬阻断规则：文档类型必须来自用户的明确表述，不得从上下文推断或自主选择。 分析或生成步骤在类型确认前禁止启动。\r \r 按以下顺序判断：\r \r

用户已明确写出文档类型（如"帮我写 HLD"、"生成 PRD"）→ 直接确认并继续，无需提问。 \r
用户未明确说明文档类型 → 立即向用户提问并等待回答，不得根据上下文猜测后自行开始：\r \r

要生成哪种文档？（对应软件交付链路的哪个阶段）\r
\r
立项阶段\r
  A. BRD/MRD — 商业需求/市场需求文档，面向决策层，说明做这件事的价值与边界\r
\r
需求阶段\r
  B. PRD — 产品需求文档，面向产品/研发，描述功能需求与验收标准\r
\r
架构阶段\r
  C. HLD — 概要设计，面向架构师/技术负责人，描述模块划分与关键设计决策\r
  D. DDD/领域设计 — 领域模型文档，描述核心域、聚合、领域事件\r
\r
实现阶段\r
  E. LLD — 详细设计，面向开发者，描述接口、数据结构、流程逻辑\r
  F. 编码指南 — 面向贡献者，描述实现约定、禁忌、常见陷阱\r
\r
验证阶段\r
  G. 测试文档（BDD/TDD/SIT/E2E/UAT）— 面向 QA/开发，描述测试场景与验收标准\r
\r
运维阶段\r
  H. 运营手册 — 面向操作/管理人员，说明如何使用与配置系统\r
  I. SLI/SLO/监控文档 — 面向 SRE/运维，描述可观测性指标与告警策略\r
\r
其他\r
  J. CI/CD 流水线文档 — 面向 DevOps/开发，描述发布流程与自动化配置\r
  K. 管理员速查手册 — 面向系统管理员，Q&A 格式，覆盖所有管理功能的操作步骤与业务影响，支持按章节独立速查\r
\r
需要说明的模块范围或特别关注点？（留空则覆盖整个项目）\r
```\r
\r
> ⛔ 收到用户回答后，才能进入第一轮。在此之前：不读代码、不分析结构、不建 todo 列表。\r
\r
---\r
\r
## 四轮工作流（模式 A 通用骨架）\r
\r
> 每轮的**关注重点**由文档类型决定。  \r
> `references/` 中的文件均为**按需扩展材料**，不是必读——只在需要完整模板或脚本片段时才打开。\r
\r
---\r
\r
### 第一轮：识别项目类型与入口\r
\r
1. 读根目录（不递归），识别技术栈：\r
   - `package.json` / `bun.lock` → Web 前端或 Node 服务\r
   - `go.mod` / `Cargo.toml` / `pom.xml` / `*.csproj` / `requirements.txt` → 后端服务\r
   - `*.xcodeproj` / `AndroidManifest.xml` / `pubspec.yaml` → 移动端\r
   - `*.sln` + XAML → 桌面（WPF/WinForms）；`CMakeLists.txt` / `*.pro` → Qt/C++\r
   - `electron.js` / `main.js` + `renderer/` → Electron 桌面\r
   - 多种并存 → 多端项目，分别处理\r
\r
2. 找程序入口（`main.*` / `index.*` / `App.*` / `Program.*`）。\r
\r
3. 先读现有文档（`README.md`、`docs/`、`wiki/`）——最快的模块清单来源。\r
\r
4. **输出**：项目类型 + 技术栈摘要 + 初始模块清单，写入 todo 工具。\r
\r
---\r
\r
### 第二轮：结构扫描与信息骨架提取\r
\r
**按文档类型关注不同的高信息密度位置：**\r
\r
| 信息类型 | 在哪里找 | 重要的文档类型 |\r
|---------|---------|--------------|\r
| 功能入口/导航 | 路由表、菜单配置、命令注册表 | 运营手册、PRD |\r
| 界面文案 | i18n 文件、字符串资源 | 运营手册、PRD |\r
| 数据模型 | 数据库实体、Schema、DTO、聚合根 | HLD、LLD、DDD、PRD |\r
| 模块/包边界 | 目录结构、命名空间划分、包依赖 | HLD、DDD |\r
| 接口契约 | 函数签名、接口定义 | LLD |\r
| 业务规则 | Service/UseCase/BLL 层、公式、状态机 | PRD、LLD、DDD、运营手册 |\r
| 权限规则 | 中间件、角色枚举、权限常量 | 运营手册、PRD |\r
| 异常/错误边界 | 错误码、异常处理分支、校验规则 | LLD、测试文档 |\r
| 代码约定 | 注释规范、命名模式、Lint 配置 | 编码指南 |\r
| 可观测性/CI配置 | 日志埋点、`workflows/`、`Makefile` | SLI/SLO、CI/CD |\r
\r
**可写脚本加速**（脚本模板见 [references/exploration-strategy.md](./references/exploration-strategy.md)）：\r
- 批量提取路由/菜单列表 → 功能清单骨架\r
- 搜索中文字符串 → UI 实际文案\r
- 统计目录代码量 → 定位核心模块\r
\r
---\r
\r
### 第三轮：逐模块深度分析\r
\r
**按文档类型决定分析重点：**\r
\r
- **运营手册**：对每个功能点逐一提炼七个维度——\r
  1. **操作基础**：功能入口、权限要求、操作步骤、表单字段含义\r
  2. **状态影响**：操作后哪些数据变化、生效时机（立即/下次请求/下次同步）、是否可撤销\r
  3. **危险等级**：不可逆操作 → `⚠️ 危险`；影响范围广 → `📌 注意`；可随时撤销 → 不标注\r
  4. **设计背景**：为什么有这个功能？没有它会遇到什么真实问题？（推断不出则省略）\r
  5. **业务规则**：公式、条件判断、上下限；触发的底层策略必须**命名**（如"负载均衡路由算法"），不能只写"影响路由"\r
  6. **关联影响**：改此配置后哪些其他模块/用户受影响（表格：影响范围 | 具体变化）\r
  7. **已知局限**：当前版本做不到的事，有无 workaround（每章 3-5 条）\r
\r
  每章开头还须收集两个固定节的素材（质检会核查）：\r
  - **🔗 前置依赖链路**：完整的 `上游模块 ➔ 上游模块 ➔ **当前** ➔ 下游模块` 链路（数清楚深度N），以及每个前置条件的两种情况（有/无、开/关）\r
  - **📊 影响追踪矩阵**：本模块每个配置项 → 影响的对象 → 影响的功能 → **触发的策略（必须命名+说机制）**\r
\r
  > 格式模板见 [references/document-structure.md](./references/document-structure.md)，深度说明见 [references/analysis-dimensions.md](./references/analysis-dimensions.md)。\r
- **BRD/MRD**：提炼业务问题 + 市场背景 + 目标指标 + 范围边界\r
- **PRD**：提炼用户故事 + 验收标准（必须可测试）+ 业务规则 + 约束条件\r
- **HLD / DDD**：提炼模块/域职责 + 依赖关系 + 关键设计决策（含 trade-off）+ 领域事件\r
- **LLD**：提炼接口签名 + 数据结构 + 流程逻辑（含异常路径）+ 错误码\r
- **编码指南**：提炼实现模式（正例+反例+原因）+ 约定规范 + 常见陷阱\r
- **测试文档**：提炼输入/输出边界 + 业务规则 + 状态转换 + 异常场景\r
- **SLI/SLO**：提炼服务目标 + 指标定义 + 告警阈值 + 降级策略\r
- **CI/CD**：提炼流水线阶段 + 触发条件 + 环境矩阵 + 回滚策略\r
\r
- **管理员速查手册**：面向有系统权限的管理员，Q&A 格式组织，分析重点：\r
  1. **系统定位**：用一句话 + 一张 Mermaid 架构图说明系统在业务中的角色（"用户→网关→上游"链路）\r
  2. **设计理念**：整理 3-7 条核心设计决策（分层权限/预扣计费/路由策略等），每条说明"这样设计解决了什么问题"\r
  3. **读者路径图**：用 Mermaid flowchart 画出「第一次部署 / 运营提升 / 遇到问题」三类读者的推荐阅读路径\r
  4. **功能章节**：每章以 🔗前置依赖链路 + 📊影响追踪矩阵 开头，正文全部以"如何…？"/"什么是…？"/"为什么…？"等问句作子标题，答案含操作步骤 + 危险等级 + 业务影响\r
  5. **附录体系**：根据项目的管理目的自行设计，不强制固定数量和名称。常见附录类型供参考（按需取用）：\r
     - 权限快速对比表（各角色能做/不能做的矩阵）\r
     - 业务场景解决方案（按"我遇到的问题"索引到解决步骤）\r
     - 财务与计费精细化手册（计费公式、倍率逻辑、对账方法）\r
     - 运营最佳实践（可分入门/进阶/高级三级）\r
     - 配置速查索引、常见报错排查、术语表等（视项目需要增减）\r
  6. **无技术术语**（同运营手册规则，完整替换表见 [references/document-structure.md](./references/document-structure.md)）\r
\r
通用原则：\r
- 遇到看不懂的逻辑，先搜索**调用方**推断语义\r
- 枚举值找**定义处+使用处**，理解每个值的含义\r
- 无法确定的细节标注 `〔INFER〕`，不猜测\r
- 每模块分析完立即整理，不攒到最后\r
\r
---\r
\r
### 第四轮：生成文档\r
\r
按文档类型读取 [references/document-types.md](./references/document-types.md) 中**对应类型的章节结构模板**（定位到具体类型节，不需要读整个文件）。\r
\r
通用生成策略：\r
- **先生成骨架**（所有章节标题），再填充内容，避免遗漏章节\r
- Mermaid 图先用文字描述逻辑，再转为图语法\r
- 章节间交叉引用用"参见第X章"，不重复内容\r
- 所有 AI 推断内容用 `〔INFER〕` 标注，直接从代码验证的事实用 `〔FACT｜文件:行号〕` 标注\r
\r
---\r
\r
### 完成后：保存、同步检查与汇报\r
\r
1. **保存**：新建存到 `docs/[项目名]/[文档全称]-[系统名].md`；文件名使用与用户对话相同的语言，不使用缩写。缩写对应全称：\r
\r
   | 缩写 | 中文全称 | 英文全称 |\r
   |------|---------|---------|\r
   | BRD | 商业需求文档 | Business Requirements Document |\r
   | MRD | 市场需求文档 | Market Requirements Document |\r
   | PRD | 产品需求文档 | Product Requirements Document |\r
   | HLD | 概要设计 | High-Level Design |\r
   | DDD | 领域设计 | Domain-Driven Design |\r
   | LLD | 详细设计 | Low-Level Design |\r
   | SLI/SLO | 监控文档 | Monitoring Document |\r
   | CI/CD | 流水线文档 | Pipeline Document |\r
   | 编码指南 | 编码指南 | Coding Guide |\r
   | 测试文档 | 测试文档 | Test Document |\r
   | 运营手册 | 运营手册 | Operations Manual |\r
   | 管理员速查手册 | 管理员速查手册 | Admin Quick Reference |\r
\r
   更新则在原文件增量修改\r
2. **文档同步铁律**（每次新建/更新文档后必须执行，不可跳过）：\r
\r
| 步骤 | 操作 |\r
|------|------|\r
| 评估影响范围 | 以本次新建/更新文档涉及的模块名为关键词，搜索 `docs/[项目名]/` 全文 |\r
| 强制三选一 | ①文档与实现一致 → 无需变更 ②文档落后 → 立即更新 ③实现偏离设计意图 → 告知用户请求裁决 |\r
| 禁止"待定" | 不允许输出"文档待后续更新"—— "后续"是文档腐烂的最大单一来源 |\r
\r
   > 完整反向同步任务（模式 B）额外执行六项收尾清单，详见 [references/reverse-sync.md §任务收尾强制清单](./references/reverse-sync.md)。\r
\r
3. **汇报**：覆盖了几个模块、发现哪些关键信息、哪些地方打了 `〔INFER〕` 标注\r
\r
---\r
\r
## 通用质量检查\r
\r
| 检查项 | 标准 |\r
|--------|------|\r
| 受众匹配 | 语言和深度符合目标读者（运营≠开发≠测试） |\r
| 流程图 | 多步操作或决策分支有 Mermaid 图 |\r
| 标注完整 | AI 推断内容有 `〔INFER〕`, 代码验证事实有 `〔FACT｜文件:行号〕`。生成完成后检查：若某份文档零标注, 视为执行失误——任何有业务规则推断的文档都不可能一处标注都没有, 须回头补充 |\r
| 无歧义术语 | 技术词有解释，或已转为目标受众语言 |\r
| 无"待定"承诺 | 所有不确定项已三选一处理 |\r
\r
**运营手册**额外检查：\r
\r
| 检查项 | 标准 |\r
|--------|------|\r
| 前置依赖节 | 每章有 `🔗 功能前置条件与依赖链路`，含最多3层深度标注（逐层列出上下游依赖方向）|\r
| 影响矩阵节 | 每章有 `📊 影响追踪矩阵`，含第4列「影响的算法/策略」 |\r
| 设计痛点 | 可推断处有 `💡 设计背景` 提示块 |\r
| 危险标注 | 不可逆操作有 `⚠️ 危险` 警告块 |\r
| 无技术术语 | 无 API/Token/JSON/HTTP 等词汇；常见替换：API→接入方式、Token→令牌、JSON→配置内容、Webhook→回调通知、正则→匹配规则（完整替换表见 [references/document-structure.md](./references/document-structure.md)） |\r
\r
**管理员速查手册**额外检查：\r
\r
| 检查项 | 标准 |\r
|--------|------|\r
| 系统定位节 | 文档开头有"系统是什么"说明 + Mermaid 架构图 |\r
| 设计理念节 | 开头有 3-7 条设计理念，每条说明解决了什么问题 |\r
| 读者路径图 | 有 Mermaid flowchart 引导不同类型读者 |\r
| Q&A 格式 | 所有正文子标题均为问句（"如何…？"/"什么是…？"/"为什么…？"）|\r
| 前置依赖节 | 每章有 `🔗 功能前置条件与依赖链路` |\r
| 影响矩阵节 | 每章有 `📊 影响追踪矩阵`，含第4列「影响的算法/策略」 |\r
| 附录体系 | 至少有1个附录，内容与项目管理目的匹配；各附录有明确的使用场景说明 |\r
| 危险标注 | 不可逆操作有 🔴 危险 / 🟡 谨慎 / 🟢 安全 三级标注 |\r
| 无技术术语 | 同运营手册规则 |\r

Usage Guidance

Before installing, be comfortable with an agent reading your project source/docs and writing markdown under docs plus OBSERVATIONS.md. Run it in the correct repository, avoid exposing secrets, and review generated or synchronized documentation before committing.

Capability Analysis

Type: OpenClaw Skill Name: code-to-doc-generator Version: 1.0.0 The code-to-doc-generator bundle is a comprehensive set of instructions and templates designed to help an AI agent reverse-engineer source code into technical documentation (PRD, HLD, LLD, etc.). The skill utilizes standard local search utilities like grep and find (detailed in exploration-strategy.md) to identify project structures and business logic. It includes strong safety constraints, such as 'Red Lines' in reverse-sync.md that explicitly forbid the agent from modifying source code or configuration files, and 'Hard Block Rules' in SKILL.md that prevent the agent from proceeding without explicit user confirmation of document types. No indicators of data exfiltration, malicious execution, or prompt injection attacks were identified.

Capability Tags

requires-oauth-tokenrequires-sensitive-credentials

Capability Assessment

ℹ Purpose & Capability

The skill’s purpose is coherent: it analyzes code/UI/docs and generates BRD/PRD/HLD/LLD/test/operations/CI/CD documentation. That necessarily involves broad project inspection and markdown output, which is disclosed.

ℹ Instruction Scope

The workflow requires explicit document-type confirmation before analysis, which is a useful control. Reverse-sync mode uses strong mandatory language for updating docs after code changes, so users should review resulting diffs.

✓ Install Mechanism

There is no install spec, no required binaries, no dependencies, and no executable helper code. The static scan reported no findings.

ℹ Credentials

Local directory listing, grep/find-style searches, and optional scripts are proportionate for code-to-documentation generation, but should be scoped to the intended project directory.

ℹ Persistence & Privilege

The skill writes generated/synchronized documentation and may maintain OBSERVATIONS.md for future scans. No background process, privilege escalation, or credential persistence is shown.

Version History

v1.0.0

Initial release of code-to-doc-generator. - Generates multiple types of project documentation (BRD/MRD, PRD, HLD, DDD, LLD, coding guides, test docs, ops/manuals, SLI/SLO, CI/CD) by reverse extracting business logic from code/UI. - Enforces clear workflow: mode and document type must be confirmed by the user before analysis begins. - Provides structured, multi-round approach for document generation, tailored to the chosen doc type (including quality/consistency checks). - Adapts output language and technical depth to the target audience for each document type. - Supports both new doc generation and reverse-syncing existing docs with code as the source of truth. - Includes detailed guidelines and quality checklists for each document type, including special requirements for operations and admin manuals.

Metadata

Slug code-to-doc-generator

Version 1.0.0

License MIT-0

All-time Installs 0

Active Installs 0

Total Versions 1

Frequently Asked Questions

What is Code To Doc?

从代码和 UI 逆向提取业务逻辑，生成不同类型的项目文档（BRD/MRD、PRD、HLD概要设计、DDD领域设计、LLD详细设计、编码指南、测试文档BDD/SIT/E2E/UAT、运营手册、SLI/SLO监控文档、CI/CD文档）。约束文档的写作维度、分析视角和格式规范。适用于任意项目类型（Web、后端服务、移动... It is an AI Agent Skill for Claude Code / OpenClaw, with 50 downloads so far.

How do I install Code To Doc?

Run "/install code-to-doc-generator" in the OpenClaw or Claude Code chat to install it in one step — no extra setup required.

Is Code To Doc free?

Yes, Code To Doc is completely free, licensed under MIT-0. You can download, install and use it at no cost.

Which platforms does Code To Doc support?

Code To Doc is cross-platform and runs anywhere OpenClaw / Claude Code is available (cross-platform).

Who created Code To Doc?

It is built and maintained by SuiFei (@suifei); the current version is v1.0.0.

More Skills

Code To Doc