managing-requirement-lifecycle

name	managing-requirement-lifecycle
description	中央调度——驱动需求在五阶段四门禁之间流转，维护 state.json，调用门禁 Agent，更新追溯链。任何需求相关操作的总入口。
allowed-tools	Read, Write, Edit, Bash, Glob, Grep, Task

Skill: managing-requirement-lifecycle

这是整个 Harness Engineering 的"中央调度"。需求工作通过它推进，以保证阶段、门禁和上下文口径一致。

触发条件

• 用户执行任何 /requirement:* 命令
• 用户对话中提到"我要做一个需求"/"继续上次的需求"/"评审通过吗"等
• 其他 Skill 需要查询当前需求状态

核心职责

1. 意图识别：把用户输入解析为标准动作（new / continue / next / gate-check / done）
2. 阶段检查：读 state.json 判断当前阶段，决定下一步合法动作
3. 门禁验证：调用对应 reviewer Agent，记录结论到 gates/*.md
4. 债务检查：列出当前未清债务，阻塞进入新阶段
5. 计划更新：更新 state.json 与 requirement.md 元数据

工作流

入参标准化

input = { action: "new"|"continue"|"next"|"gate-check"|"done",
          requirement_id?: string,
          extra?: object }

state.json 结构

{
  "requirement_id": "T12345",
  "project": "demo-project",
  "current_stage": "3.2",
  "passed_gates": ["2.2"],
  "pending_debts": [
    { "id": "DEBT-001", "desc": "补充 C2.2.7 风险章节", "due": "..." }
  ],
  "branch": "feature/koka/T12345",
  "last_updated": "2026-05-28T10:00:00Z"
}

阶段进入决策表

当前	用户请求	检查	通过后动作
1.1	next	requirement.md 存在	→ 2.1
2.1	next	requirement.md 模板字段非空	→ 2.2（触发门禁）
2.2	gate-check	调用 requirement-quality-reviewer	通过 → 3.1；不通过 → 留在 2.1
3.x	next	设计文档存在	→ 3.3（触发设计门禁）
3.3	gate-check	调用 detail-design-quality-reviewer + traceability-gate-checker	通过 → 4.1
4.1	next	features.json 存在	→ 4.2（触发 Dev 门禁）
4.2	gate-check	校验 features.json	通过 → 4.3
4.3	gate-check	调用 scripts/check-three-repo-sync.sh	通过 → 4.4
4.4	next	所有 features 状态为 done	→ 5.1
5.x	next	测试报告存在	→ 5.2
5.2	done	self-refinement 已触发	→ 归档

输出协议

每次执行后，输出三段：

[STAGE] 当前阶段：3.2 → 3.3
[GATES] 通过：2.2，待跑：3.3
[NEXT]  建议执行：/requirement:gate-check（设计评审）

不可越权的事情

• 不允许跳过门禁：除非 fast-track 且记录债务
• 不允许直接改 state.json 的 passed_gates：必须经过对应 reviewer
• 不允许在错误阶段写代码：4.2 / 4.3 未通过禁止进入 4.4

与其他 Skill 的关系

• 调用 traceability-gate-checker（追溯校验）
• 调用 service-dependency-analyzer（影响面）
• 调用 self-refinement（5.2 经验沉淀）
• 被所有 /requirement:* Command 触发