技能介绍

要解决什么问题

在 Cursor / Claude 里接 TAPD 需求时，常见做法是主 Agent 一口气写代码、跑测试、开 MR——上下文一挤就漏步骤，审查与交付也容易和实现混在一起。这个技能把主 Agent 固定为编排者：写业务代码、跑测试、做方案与审查都交给命名 Subagent，主流程只负责派发、校验产物、在 Gate 处停住等用户确认。

工作流如何运转

流程按 Phase 1～7 推进，并在关键节点设 🚦 Gate（必须用 AskUserQuestion，不可跳过）：

Phase 1 信息收集：并行派发 dev-researcher（TAPD/Knot MCP → requirement-summary.md）与 dev-analyzer（影响范围 → impact-analysis.md）。
Phase 2 需求澄清：调用 superpowers:brainstorming，Gate 1 展示摘要与影响面。
Phase 3 方案设计：dev-planner 输出 PLAN.md，Gate 2 确认后 git checkout -b feature/...。
Phase 4 实现：按 PLAN.md 选路径——业务逻辑/接口/模型等多为 路径 A（TDD）：dev-tester RED → dev-implementer GREEN + test-report.md；纯配置/文案等为 路径 B（直接实现）。Gate 3 对测试、覆盖率、lint 做自动或人工放行。
Phase 5 代码审查：dev-reviewer 产出 REVIEW.md，Gate 4 对 CRITICAL/HIGH 问题决定是否修复。
Phase 6 交付：dev-deployer 推分支、gongfeng MCP 建 MR、tapd MCP 更新状态；Gate 5 确认 MR/CI 后进入收尾。
Phase 7 收尾（不可跳过）：生成 SUMMARY.md、可选更新 CLAUDE.md、写 progress.json 为 completed。

三条铁律贯穿全程：Gate = 停止；>>> = 必须用 Agent 工具派发；主 Agent 禁止自己写业务代码或审查，implementer/reviewer 失败时最多重派 2 次。

适用边界

依赖 TAPD/Knot、gongfeng、tapd 等 MCP 与约定目录 docs/dev-workflow/{ID}/；Subagent 类型（dev-researcher、dev-planner 等）需在环境中已配置。纯本地小改动、无需求单 ID 或未接 MCP 的场景，完整七阶段可能过重；中断恢复与 Gate 细则见技能内 references/ 文档。

截图预览

使用场景

接到 TAPD 需求单后，先并行拉取需求摘要与代码影响分析，在 Gate 1 确认范围再进入方案设计
PLAN 涉及接口或数据模型时走路径 A：先 RED 写失败测试，再 GREEN 实现并产出 test-report，Gate 3 核对覆盖率与 lint
方案与分支确认后，由 deployer 推 feature 分支、经 gongfeng 建 MR、tapd 更新为已开发，Gate 5 核对 CI 再写 SUMMARY
需求信息不全或方案有歧义时，在 Phase 2 用 brainstorming 与用户对齐，避免 planner 基于错误前提出 PLAN

适合人员

接公司 TAPD 单、用 Cursor 开发且希望审查/MR/状态更新不被主 Agent 一笔带过的后端工程师
团队要求 TDD + 代码审查门禁，需要把调研、实现、review 拆给 Subagent 而非单会话写到底的 Tech Lead
已接入 Knot/TAPD/gongfeng MCP，要把 docs/dev-workflow/{ID}/ 产物与 progress.json 做成可审计流水线的平台或效能同学
长需求容易在中途丢步骤，需要 Gate 强制 AskUserQuestion、主 Agent 只编排不写业务代码的 Feature Owner