Skill.md
Harness Step 2 — 填充 docs/ 知识库内容
docs/ 骨架创建后，最常见的问题是：文件存在，但内容是占位符。agent 读到"命名规则：见代码"这种文字，等于什么都没读。这个 skill 解决这一问题——深度读懂代码，把隐性知识变成显式文档，每条规则都有代码实例支撑。
会填充哪些文件
| 文件 | 填充内容 |
|---|---|
docs/ARCHITECTURE.md | 模块职责、依赖方向规则（带原因）、主要数据流 |
docs/CONVENTIONS.md | 文件命名规律（含实际示例）、变量/函数命名规律 |
docs/TECH_DECISIONS.md | 每个主要库/框架的选型原因（能推断则推断，不能则标注「待补充」） |
docs/QUALITY.md | 项目特有的完成定义、代码审查检查清单 |
docs/exec-plans/tech-debt-tracker.md | 扫描中发现的重复代码、命名不一致、TODO 注释等 |
核心原则
推断出来的内容标注来源，无法确定的内容标注「待补充」——不用模糊占位符糊弄过去。
扫描结束后，skill 会给出一份「待补充」清单，这是需要你人工确认的部分。大多数项目通常有 3-5 个这样的条目，主要集中在：
- 技术选型的历史原因（代码里只有结论）
- 性能基准和 SLA（需要实测数据）
- 团队约定俗成的习惯（没有写在代码里的规范）
支持的使用场景
- Step 1 建好骨架后，立即填充实质内容
- 项目经历重大重构后，更新文档与代码的一致性
- 接手他人项目，快速生成自己能看懂的架构说明
使用方式
- 确认项目中已有
AGENTS.md和docs/目录（运行 Step 1 生成） - 说"填充文档内容"或"写 ARCHITECTURE.md"
- Skill 扫描入口文件、模块边界、依赖声明、命名模式
- 写入所有 docs/ 文件，列出「待补充」清单
- 你只需要确认或补充那些 skill 无法推断的内容
局限说明
Skill 从代码推断，不访问 git history 或团队沟通记录。历史决策原因（"为什么当时选了 X"）通常需要人工补充；运行时行为（API 响应格式、实际查询性能）无法从文件中读取。