敏捷管理入口 (Using Agile)
1. 定位
本技能是敏捷套件的唯一入口,承担三件事:
- 初始化:项目无
agile-docs/时,建空骨架 +DOD.md模板 +interfaces/sprint-schema.yaml。 - 检测路由:项目有
agile-docs/时,先做 .done.yaml 回填检测(存在即默认执行闭环),再扫描三层状态 → 输出状态表 → 逐层询问"更新 or 继续" → 路由到对应业务技能。 - 变更协调:当用户说"需求变了"时,引用
references/change-matrix.md做变更分级 + 影响面评估 → 路由到对应业务技能就地更新。
本技能绝不自己 Write 任何业务 .md 文档(VISION / ARCHITECTURE / ADR / PRODUCT-BACKLOG / Sprint 等)。所有业务文档由对应业务技能在用户确认后产出。
设计哲学
本套件面向单人 + agent,保留敏捷的「优先级驱动 + 增量迭代 + 快速响应变化」,抛弃大团队重量级。
反模式(不做):
- ❌ 多角色访谈 / 分权(PO / 技术 / 用户代表)
- ❌ 会议仪式(站会 / 评审 / 回顾)
- ❌ 长篇用户故事(INVEST / Given-When-Then / epic)
- ❌ 故事点精修会(planning poker)
保留:
- ✅ 优先级驱动(MoSCoW)
- ✅ 增量 Sprint(短周期、可交付)
- ✅ 快速响应变化(变更分级 + 就地更新)
- ✅ 决策选择题问询 + agent 自检 checklist
2. 三层模型与业务技能路由
| 层 | 产出物 | 负责技能 |
|---|---|---|
| 战略与约束层 | 愿景 VISION、架构图 ARCHITECTURE、决策 ADR | agile-strategic(两阶段一体化) |
| 执行层 | DoD、PRODUCT-BACKLOG(.md + .yaml)、Sprint(规划/关闭) | agile-backlog / agile-sprint |
| 跨层(变更协调) | 变更传播矩阵评估 + 路由 | using-agile(本技能,引用 references/change-matrix.md) |
Sprint 规划由 agile-sprint 承担:纯规划器(规划→DoD关闭),不含执行态追踪。关闭后保留作历史,闭环即止。
3. 激活流程(有 agile-docs/ 时)
- .done.yaml 回填检测(必做,第 1 步):扫描
sprints/*.done.yaml。存在即视为用户意图"处理回填闭环",默认执行,不问"是否先关 Sprint":- 对应 Sprint 非"已关闭" → 路由
agile-sprint环节 B/C 做 DoD 关闭(含 feedback 读取) - Sprint 已关闭 → 跳过关闭,直接进入同步
- 路由
agile-backlog阶段 5 同步 Backlog(更新 status;issue转新条目候选、decision停下请用户裁决) - 闭环完成 →
.done.yaml改后缀.done.processed.yaml留痕(不删除) - 机械步骤(DoD 核对 / 关闭 / 同步 / 改名)自动执行,仅裁决点停下确认;多个
.done.yaml逐个处理;完成输出结果报告,再回到第 2 步 - 无
.done.yaml→ 直接进入第 2 步
- 对应 Sprint 非"已关闭" → 路由
- 检测
agile-docs/下各文件存在性:VISION.md+ARCHITECTURE.md+ADR.md→ 战略层PRODUCT-BACKLOG.md+PRODUCT-BACKLOG.yaml→ 执行层待办池DOD.md→ 完成定义sprints/下未关闭的.md→ 活跃 Sprint(若检测到 >1 个活跃 Sprint,警告并请用户选择关闭/合并其一后再继续,见references/status-routing.md)
- 双文件一致性检查:若
PRODUCT-BACKLOG.md和.yaml均存在,对比 id 集合、条目数、同 id 的 priority/status(唯一权威口径见agile-backlog/references/backlog-rules.md §七)。不一致 → 停下报告差异,请用户确认以哪份为准后再继续路由。 - 输出三层状态表(见
references/status-routing.md)。 - 逐层询问"更新 or 继续下一步"(话术见 reference)。
- 按用户选择路由到对应业务技能,不自己写。
4. 初始化流程(无 agile-docs/ 时)
- 最小项目画像采集(下游三个业务技能问询的公共输入,用选择题问,节奏遵循
references/probing-protocol.md §三,分两轮):- 第一轮:项目名称 / 一句话定位 / 项目类型(Web 应用、API 服务、工具库…)
- 第二轮:团队人数与主要技能栈 / 全新项目还是存量代码
- 采集结果写入
agile-docs/DOD.md头部「项目画像」备注区,供下游技能读取;用户明确跳过的项标{待确认}
- 建
agile-docs/目录骨架(仅目录 +DOD.md模板 +interfaces/sprint-schema.yaml)+ 项目根建sprints/空目录。不创建业务文档占位文件(VISION/ARCHITECTURE/ADR/PRODUCT-BACKLOG.* 由对应技能在用户确认后产出)——路由以文件存在性为准,占位文件会误判状态已就绪。 - 生成
agile-docs/DOD.md模板(按references/init-template.md §二)+agile-docs/interfaces/sprint-schema.yaml(按references/sprint-schema.yaml)。 - 停,问:"骨架已就绪。是否调用
agile-strategic产出愿景?" - ❌ 不写任何业务文档(VISION / ARCHITECTURE / ADR / PRODUCT-BACKLOG / Sprint)。不生成 meta.json。
5. 写前战略门禁(最高优先级)
在路由到任何业务技能产出前,若检测到以下情况立即停下,按 references/strategy-conflict-template.md 生成 STRATEGY_CONFLICT.md,用表格列冲突/歧义清单请用户裁决:
- 多份输入文档战略方向矛盾;
- 需求存在未界定的关键规则(MVP 边界、核心流程等);
- 待写内容与现有 Vision / ADR 冲突。
缺失即问:若目标层的必答话题存在未覆盖项(用户没提 ≠ 不需要),同样属于门禁触发,但动作是停下问询而非停下裁决——用选择题问(references/interview-protocol.md),追问/跳过规则见 references/probing-protocol.md。
在用户裁决前,不写任何产物文件(仅允许建目录骨架或写 STRATEGY_CONFLICT.md)。冲突记录去重:STRATEGY_CONFLICT.md 由先检测到冲突的技能生成;后续技能激活时发现已存在 → 跳过不重复生成,仅引用。详见 references/gate-protocol.md。
6. 变更协调
当用户说"需求变了""要改故事""依赖检查"时:
- 引用
references/change-matrix.md先做变更分级(L1 措辞 / L2 同层 / L3 跨层),决定重访粒度——避免「任何小改都整层重访」的慢响应。 - 用表格呈现"改 X 会影响 Y、Z",请用户确认范围。
- 用户确认后,路由到对应业务技能就地更新(本入口不自己改业务正文):
- 改 VISION / ARCHITECTURE / ADR →
agile-strategic - 改 PRODUCT-BACKLOG 任务 / 加新任务到 Backlog →
agile-backlog(即使 Sprint 执行中提出,不路由到 agile-sprint) - 改 Sprint 规划 / 关闭 →
agile-sprint(执行期状态变更由消费 Agent 自行处理,不进规范层) - 改 DoD 模板 → 本入口(DoD 模板就是本技能生成的)
- 同步 Sprint 执行结果到 Backlog →
agile-backlog(检测 .done.yaml 后默认闭环时触发)
- 改 VISION / ARCHITECTURE / ADR →
- 跨层变更按依赖顺序逐层路由:如改 VISION 原则影响 Backlog 排序 → 先 agile-strategic 改 VISION,再回本入口做状态检测,再路由 agile-backlog 改标注(不要并行触发多个业务技能)
- L2 走增量问询、L3 走完整问询(
references/change-matrix.md §二/§三):L2 只重问受影响维度,已确认维度复用现有文档;L3 走完整问询 + 变更传播评估,跨层按依赖顺序逐层路由。 - 底层变更做下游影响评估(
references/change-matrix.md §四):如 Backlog 变更后评估 Sprint 是否需调整,作为审阅清单一项,由用户裁决是否触发下游重规划。 - 不重新生成全部
agile-docs/内容——只改受影响文件 - ADR 走替代而非 in-place(门禁 ②,详见
references/gate-protocol.md)
7. 硬约束
- ❌ 绝不自己 Write 业务
.md(VISION / ARCHITECTURE / ADR / PRODUCT-BACKLOG / Sprint)。 - ✅ 只做:检测状态 → 逐层询问"更新 or 继续"(不替用户决定走向)→ 路由 → 变更协调(引用矩阵,不直接改业务正文)。
- ✅ 渐进式:业务技能产出即停;下一步须用户再次调用本技能或下个业务技能。
- ✅ 路由到业务技能时提示其遵循
references/interview-protocol.md(选择题 + 推荐)、references/probing-protocol.md(追问/跳过)、references/gate-protocol.md(门禁)。