| name | requirement-doc-writer |
| description | 撰写 artifacts/requirement.md（阶段 2 产出物），严格执行"刨根问底"——每条关键信息必须有来源、或标记待确认/待补充。 |
什么时候用
在 definition 阶段，用户要求撰写或修订需求文档时。
核心流程
- 调用
universal-context-collector Agent（Phase 3 前：主 Agent 自己按 context/team/engineering-spec/design-guidance/context-engineering.md 的优先级检索）
- 先输出 3-5 条关键确认点（见
ai-collaboration.md 渐进式输出规则）：
- 已获取的关键上下文来源
- 需要用户确认的信息
- 涉及选择的决策点
- 用户确认后，基于
templates/requirement.md.tmpl 撰写正式文档
- 刨根问底：按
reference/sourcing-rules.md 的三态规则标注每条关键信息
- 本地自检：成稿后跑
python3 scripts/gates/run.py --trigger=adapter --legacy=check-sourcing --requirement <REQ-ID>，期望退出码 = 0；有 error 必须修复后再进入下一阶段（/workflow:next [F-012 待落地] 门禁会再跑一次）
- 提示补 meta.yaml 语义字段：requirement.md 成稿后，提醒用户补齐
meta.yaml 的语义组（feature_area / change_type / affected_modules / tags）——这些字段是跨需求检索的基础，bootstrap 阶段为空，离开 definition 阶段前必须补齐
硬约束
- ❌ 禁止出现"没来源但看起来合理就写了"的第四种状态
- ❌ 禁止一次性输出完整长文档（必须先出关键确认点）
- ❌ 禁止跳过"提示补语义字段"这一步——后续
/workflow:next [F-012 待落地] 门禁会校验，不提示会让用户在门禁处被卡住
- ✅ 每条事实性信息必须是三态之一：有引用 /
[待用户确认] / [待补充]
- ✅
[待补充] 必须附假设（内容、依据、风险、验证时机）
meta.yaml 语义字段速查（用于提示用户）
| 字段 | 含义 | 合法值来源 |
|---|
feature_area | 所属业务域 | context/project/<project>/areas.yaml 白名单 |
change_type | 变更类型 | context/team/engineering-spec/meta-schema.yaml 枚举（feature/bugfix/refactor/perf/security） |
affected_modules | 涉及模块 | 自由词，建议与 services 子模块对齐 |
tags | 细粒度标签 | 自由词，可选 |
参考资源
