实码文档生成

文档和代码对不上，比没文档更危险

接口文档里多出一个字段、路径写错 HTTP 方法、错误码是「拍脑袋」的——这类问题往往来自让模型「根据项目名猜一版」。线上联调或交接时，错误文档会直接拖慢排障，甚至引发误用。

code-to-docs 把角色固定为「Senior Technical Writer + 全栈工程师」：先读真实代码，再落笔，禁止在信息不足时编造路径、DTO 字段或业务逻辑。

技能如何执行

流程是强制顺序的：

• Step 0：未提供代码则直接要求上传文件或片段，不空转。
• Step 1：按优先级扫读——路由 → Controller → Service → DTO/Schema → 中间件/Guard，并在内部整理路径、入参、响应、权限、限流与代码里的 TODO。
• Step 2：若未指定文档类型，一次性询问 API / 模块开发 / README / 架构等选项。
• Step 3：套用对应 Markdown 模板输出，文末标注来源文件；输出前自检路径、字段类型、错误码是否均来自代码。
• Step 4：生成后询问是否要补细节、调粒度或同步 README/Changelog。

模板覆盖 API 接口文档（含示例 JSON）、模块开发文档（类型与来源注释）、README（安装与目录结构）等形态，风格要求前后一致。

适用边界

• 大仓库可先问是否要先梳理目录结构，避免一次塞满超长单文档。
• 不会把代码注释原样当用户文档；注释面向实现，文档面向使用者。
• 红线明确：与代码不符的内容、忽略已知限制、一次性输出难以维护的超长文档，都在禁止之列。