name: feature-dev description: "[内部] 全流程需求开发工作流核心逻辑。不直接调用，由 /dev 命令路由触发。" disable-model-invocation: true allowed-tools: Agent Bash(git *) Bash(devflow-status)

Feature Dev - 全流程需求开发

当前工作流状态

!devflow-status 2>/dev/null || echo "无活跃工作流"

⛔ 三条铁律（每一步都必须遵守）

铁律 1: Gate = 停止。 遇到 🚦 时，必须用 AskUserQuestion 向用户提问并等待回复。不可跳过。

铁律 2: Subagent = Agent 工具。 遇到 >>> 时，必须用 Agent 工具派发。禁止主 agent 自己做。

铁律 3: 主 agent 是编排者，不是执行者。 - ✅ 能做: 派发 subagent、验证产物、展示 Gate、调 MCP、git 操作、写 progress.json/SUMMARY.md - ❌ 禁止: 写业务代码、跑测试、分析逻辑、设计方案、审查代码、修 bug - 未完成时: 重新派发 subagent（最多 2 次），绝不自己动手

流程

Phase 1: 信息收集

并行派发: - Agent({ subagent_type: "dev-researcher", prompt: "需求 TAPD-{ID}，从 TAPD/Knot MCP 收集信息，输出 docs/dev-workflow/{ID}/requirement-summary.md" }) - Agent({ subagent_type: "dev-analyzer", prompt: "需求: {简述}。扫描代码库分析影响范围，输出 docs/dev-workflow/{ID}/impact-analysis.md" })

验证两个文件已生成。

Phase 2: 需求澄清

调用 superpowers:brainstorming skill，基于 Phase 1 内容与用户讨论。不可跳过。

🚦 Gate 1

用 AskUserQuestion 展示需求摘要 + 影响范围。选项: [确认继续] [补充信息] [终止]。

Phase 3: 方案设计

Agent({ subagent_type: "dev-planner", prompt: "基于 requirement-summary.md 和 impact-analysis.md 设计方案，输出 docs/dev-workflow/{ID}/PLAN.md" })

验证 PLAN.md 已生成。

🚦 Gate 2

用 AskUserQuestion 展示计划摘要 + 文件清单。选项: [确认继续] [调整方案] [换方案]。 确认后创建分支: git checkout -b feature/{简短英文描述}

Phase 4: 实现

判断 PLAN.md：涉及业务逻辑/新接口/数据模型/多文件 → 路径 A (TDD)；纯配置/文案/文档 → 路径 B (直接实现)。

路径 A (TDD):

Step 1 - RED: Agent({ subagent_type: "dev-tester", prompt: "基于 PLAN.md 写测试（RED），运行确认失败" })

验证测试文件已生成且用例 ≥ 1。未生成则重试。

Step 2 - GREEN: Agent({ subagent_type: "dev-implementer", prompt: "实现代码使测试通过（GREEN），运行所有测试确认通过，检查覆盖率，输出 docs/dev-workflow/{ID}/test-report.md。未通过则继续修复，不要提前返回。" })

未通过则重新派发 implementer（最多 2 次）。

路径 B (直接实现):

Agent({ subagent_type: "dev-implementer", prompt: "按 PLAN.md 实现，无需测试" })

🚦 Gate 3

路径 A: 测试全绿 + 覆盖率 100% + lint 通过 → 自动过；否则 AskUserQuestion。 路径 B: lint 通过 → 自动过；否则 AskUserQuestion。

Phase 5: 代码审查

Agent({ subagent_type: "dev-reviewer", prompt: "审查 git diff master...HEAD + requirement-summary.md，输出 docs/dev-workflow/{ID}/REVIEW.md" })

验证 REVIEW.md 已生成。

🚦 Gate 4

0 CRITICAL + 0 HIGH → 自动过；否则 AskUserQuestion 展示问题，选项: [通过] [修复后继续] [终止]。 修复: 派发 implementer → 重新派发 reviewer（覆盖 REVIEW.md）。最多 2 轮。

Phase 6: 交付

Agent({ subagent_type: "dev-deployer", prompt: "推送分支，通过 gongfeng MCP 创建 MR（目标 master），通过 tapd MCP 更新状态为'已开发'，监控 CI。输出 MR 链接 + CI 状态。" })

🚦 Gate 5

用 AskUserQuestion 展示 MR + CI + token 统计。选项: [确认提交] [修改 MR] [暂不提交]。 确认后立即进入 Phase 7。

Phase 7: 收尾（⛔ 不可跳过，Gate 5 通过不等于结束）

1. 生成 docs/dev-workflow/{ID}/SUMMARY.md（格式见 references/summary-template.md）
2. 向用户展示自我进化分析（有无值得追加到 CLAUDE.md 的经验），询问是否追加
3. 更新 progress.json 为 completed
4. 输出完成总结: "✅ 工作流完成！需求/MR/耗时/产物目录"

参考文档

• references/gate-protocol.md — Gate 详细规则
• references/resume-protocol.md — 中断恢复
• references/framework-routing.md — 框架路由
• references/summary-template.md — SUMMARY.md 格式

这是一个设计思路不错的工作流 Skill，流程完整、有明确的人工确认节点，能帮助规范开发过程。但整体更像是流程规范文档，实际使用体验和功能完整性还需验证，目前能了解到的信息有限。质量中等偏上，有亮点也有明显短板。