用途：在需求、plan 和实现闭环后，把已落地的业务行为沉淀到 docs/spec/，重点不是复述源码，而是说明需求落成了什么行为、代码如何支撑、改动会影响哪些契约、当前有哪些真实边界。
适用场景：用户要求根据需求、plan、diff、文件、tool、service、接口链路或模块实现生成 docs/spec/ 规范文档；或要求总结核心逻辑、影响范围、当前边界、TODO、文件名、方法名、行号，或把本轮实现沉淀到文档时使用。若只是临时问一句代码做什么，可直接简短回答，不进入完整流程。
非目标：不顺手改业务代码，不重新设计方案，不做完整 code review。发现 bug、风险、实现与需求不一致或旧文档冲突时，需在沉淀前客观指出，不把不符合需求的实现写成新规范。
工作流程：读取需求、plan、实现入口或 git diff；读取 docs/spec/index.md 及相关子索引；读取目标模块已有规格文档；顺着 import、schema、type、service、prompt、controller、query 查直接依赖；判断更新旧文档、新建文档还是先反馈冲突；形成正文和索引草稿并润色核对；写入 docs/spec 并同步更新索引；检查 git diff / git status 确认只产生预期文档变更。
文档结构：首要章节为核心逻辑，说明模块定位、最终行为、输入输出、主流程和关键设计取舍；需求落地章节说明关键需求点由哪些代码路径支撑；详细代码逻辑按调用顺序写入口、参数处理、核心编排、关键算法、输出组装，并带文件名和行号；影响范围写 schema、type、prompt、调用方、query、前端协议、事件语义、checkpoint、缓存等真实依赖；当前边界写已存在的边界；TODO 注释归纳写检查到的 TODO、FIXME、待办及检查范围。
写入规则：默认存放在 docs/spec/* 下对应模块目录，命名如“业务名总结.md”。已有同主题文档优先更新，不创建重叠文档。新增或迁移后必须同步更新 docs/spec/index.md 及子索引。行号必须来自实际读取或搜索结果。humanizer-zh 可用时必须调用并应用其 SKILL.md；不可用时按大白话规则润色并继续写入，在回报中说明采用了大白话规则。
限制：不编造需求、待办或未来规划；不把计划或推测写成已实现行为；代码、标识符、命令、路径、行号、URL 保持原样；不无限扩散到无关模块。