| name | dev-doc-writer |
| description | 根据任意编程语言（Java、Python、TypeScript、Go 等）的源代码、架构说明或功能描述， 生成结构规范、语言专业的开发技术文档。当用户需要为模块、功能、类/函数/接口撰写开发文档、 技术说明、架构文档、接口文档、模块说明时使用此技能。 触发关键词：生成文档、写文档、开发文档、技术文档、模块说明、架构文档、接口文档、写说明。 |
开发文档生成器
为任意语言的项目生成结构规范、语言专业的技术开发文档。
第一步：识别语言，加载语言规范
读取用户提供的代码或描述，判断编程语言，然后读取对应的语言规范文件：
| 语言 | 加载路径 |
|---|
| Java / Kotlin | {skillPath}/references/lang/java.md |
| Python | {skillPath}/references/lang/python.md |
| TypeScript / JavaScript | {skillPath}/references/lang/typescript.md |
| Go | {skillPath}/references/lang/go.md |
| 其他 / 未知 | 不加载语言文件，仅依赖通用规范 |
语言规范文件定义了：该语言的代码块展示规则（保留什么、删什么）和分层命名惯例（该语言生态中的标准层次划分）。
加载语言规范后，继续执行以下步骤。
第二步：理解输入
- 判断用户提供的是源代码、架构描述还是功能说明
- 提取：模块名称、核心组件列表（类/函数/模块）、各组件所属层次
- 若语言无法从代码特征判断，询问用户使用的语言
第三步：生成文档
按以下固定章节顺序生成，不可随意省略或调换：
章节一：标题
直接用模块/功能名称，不加任何修饰词。
章节二：背景需求
100–200 字，一段话，覆盖三点：
- 业务/技术背景：当前系统面临什么问题，或有什么演进驱动
- 模块定位：以什么为核心，整合了哪些能力，服务于哪个上层需求
- 关键约束与目标：需要支持什么特性，兼顾什么质量要求
若用户未提供背景，根据代码功能推断补全，不留空。
章节三：架构总览（仅多层结构时使用）
当模块涉及明确的分层架构时生成此章节，单层模块跳过。用缩进列表描述每一层的名称、定位与核心组件。
章节四：模块结构
以目录树形式呈现项目的文件/包结构，每个核心文件或组件后用 # 注释一句话职责。
注释格式遵循目标语言惯例（见已加载的语言规范文件）。
章节五：整体数据流向
用伪代码风格描述请求从入口到出口的完整链路，使用 │ ├─ └─ ▼ → 等字符呈现调用层次感。
- 每个关键步骤前用
├─①②③ 标注顺序
- 分支逻辑和异步操作用缩进层次体现
- 若有事件流（SSE/WebSocket/消息队列），在末尾列出事件序列
章节六：功能实现
这是文档正文，按调用链从底到顶逐层展开，每层用 ### 标题标注层名。
每个组件的固定格式（不可变）：
#### 组件名
[代码块：签名/接口定义，无实现体]
[职责说明：1–3 句话，说明是什么、关键设计决策、协作关系]
代码块的具体规范（保留什么、删除什么）见已加载的语言规范文件。
职责说明规范见：{skillPath}/references/writing-style-guide.md
输出格式要求
- Markdown 格式，章节用
##，层名用 ###，组件名用 ####
- 组件名、方法名、字段名在正文中用
反引号 标注，不加粗
- 数据流使用缩进 +
│ ├─ └─ ▼ → 符号
- 文档末尾无需总结段落，最后一个组件说明完即结束
- 代码块语言标识符与实际语言一致（如
```python ```typescript ）
边界说明
- 若用户只提供了部分代码，只为已提供的组件生成文档，不臆造未知内容
- 若涉及多个模块，先询问用户是生成单个模块还是全量文档
- 不生成单元测试文档、部署文档、运维手册，那些属于其他技能范畴
- 若代码量极大（超过 500 行），先列出组件清单请用户确认范围再生成
