blueprint-prp-execute

/blueprint:prp-execute

通过系统化实现、验证关卡、TDD 工作流和质量保证来执行 PRP（产品需求提示词）。

用法：/blueprint:prp-execute [prp-name]

前置条件：

• PRP 已存在于 docs/prps/[prp-name].md
• 置信度评分 >= 7（如果低于此值，建议使用 /blueprint:prp-create 进行完善）

详细的报告模板、延后事项工作流、功能跟踪器同步和错误处理模式，请参阅 REFERENCE.md。

何时使用此技能

在以下情况下使用此技能……	在以下情况下使用替代方案……
准备好根据 PRP 实现已规划的功能	PRP 尚未准备就绪（置信度 < 7）
希望通过完整的验证和 TDD 工作流执行	在没有文档的情况下临时实现功能
需要功能跟踪器和 GitHub 问题跟踪	处理独立的 Bug 修复
希望自动报告进度并跟踪延后事项	无需正式跟踪的快速原型开发

上下文

• PRP 文件路径：!find . -maxdepth 1 -name \'docs/prps/${1:-unknown}.md\'
• PRP 置信度评分：!find . -path '*/docs/prps/*' -maxdepth 3 -name "${1:-unknown}.md" -exec grep -m1 "^confidence:" {} +
• 已启用功能跟踪器：!find . -path '*/docs/blueprint/*' -maxdepth 3 -name 'feature-tracker.json' -type f
• 当前分支：!git rev-parse --abbrev-ref HEAD
• 未提交的更改：!git status --porcelain

参数

解析 $ARGUMENTS：

• prp-name（必需）：docs/prps/ 中 PRP 文件的名称（不含 .md 扩展名）
  • 示例：feature-auth-oauth2 → 加载 docs/prps/feature-auth-oauth2.md

执行

执行完整的 PRP 实现工作流：

步骤 1：加载并验证 PRP

1. 读取 PRP 文件：docs/prps/{prp-name}.md
2. 从 frontmatter 中提取置信度评分
3. 如果置信度 < 7 → 错误：“PRP 置信度过低。运行 /blueprint:prp-create {prp-name} 进行完善”
4. 如果置信度 >= 9 → 提供委派选项：“此 PRP 置信度较高。立即执行（当前会话），还是创建 work-order 以便委派？”
   • 如果选择 work-order → 运行 /blueprint:work-order --from-prp {prp-name} 并退出
   • 如果选择委派给多个子 Agent → 根据 Implementation Blueprint 为每个模块创建专门的 work-order 并退出
5. 如果立即执行，或置信度为 7-8，则继续步骤 2
6. 加载所有引用的精选规则条目（.claude/rules/）作为上下文
7. 解析 Implementation Blueprint，并按依赖关系排序创建 TodoWrite 条目

步骤 2：通过验证关卡建立基线

运行实现前验证关卡（参见 REFERENCE.md），以建立干净的起始状态：

1. Lint 检查关卡：[command from PRP] - 预期：通过
2. 现有测试关卡：[command from PRP] - 预期：通过

如果关卡未通过：

• 记录现有问题
• 决定：先修复，还是记录说明后继续
• 准备就绪后继续

步骤 3：执行 TDD 实现循环

针对 Implementation Blueprint 中的每项任务：

1. RED 阶段：编写符合 PRP TDD Requirements 的失败测试

   • 如有需要，创建测试文件
   • 运行测试 → 确认失败（测试确实有效）

2. GREEN 阶段：实现最少量代码，使测试通过

   • 遵循 PRP 中的 Codebase Intelligence 模式
   • 应用精选规则引用中的模式
   • 留意 Known Gotchas
   • 运行测试 → 确认成功

3. REFACTOR 阶段：在保持测试通过的同时改进代码

   • 提取通用模式
   • 改进命名，添加类型提示
   • 遵循项目约定
   • 运行测试 → 确认通过
   • 经常运行验证关卡（而非只在最后运行）

4. 标记进度：更新 TodoWrite：✅ Task N: [Description]

第 4 步：运行全面的最终验证

执行 PRP 中的所有验证门禁（参见 REFERENCE.md）：

• Lint 检查：[cmd] - 预期结果：PASS
• 类型检查：[cmd] - 预期结果：PASS
• 单元测试：[cmd] - 预期结果：PASS（所有测试）
• 集成测试：[cmd] - 预期结果：PASS（如适用）
• 覆盖率检查：[cmd] - 预期结果：达到阈值
• 安全扫描：[cmd] - 预期结果：无高危/严重问题（如适用）
• 性能测试：[cmd] - 预期结果：达到基准（如已定义）

验证 PRP 中的每项成功标准。

第 5 步：记录延期事项

确定并跟踪所有延期工作：

1. 查看 Implementation Blueprint，找出尚未完成的事项
2. 对每项延期事项进行分类：
   • Phase 2（必需）：必须创建 GitHub issue
   • 锦上添花：可选，无需创建 issue
   • 受阻：无法完成——记录阻碍原因并创建 issue
3. 为所有 Phase 2 和受阻事项创建 GitHub issue（参见 REFERENCE.md）
4. 在 PRP 中添加延期事项部分，并链接到 GitHub issue
5. 在创建所有必需的 issue 之前，不要继续执行第 6 步

第 6 步：同步功能跟踪器（如已启用）

如果存在功能跟踪器（docs/blueprint/feature-tracker.json）：

1. 确定 PRP 中已完成的功能代码（例如 FR2.1）
2. 更新每个代码对应的功能跟踪器：
   • 状态：complete（所有标准均已满足）、partial（部分标准已满足）或 in_progress
   • 文件：列出已修改/创建的文件
   • 测试：列出测试文件
   • 提交：提交哈希
   • 备注：实现说明
3. 重新计算统计数据：完成百分比、阶段状态
4. 更新 TODO.md：勾选已完成的功能
5. 报告功能跟踪器的变更

第 7 步：报告结果和后续步骤

生成全面的执行总结报告：

• 已完成任务：X/Y
• 新增测试：N
• 已修改文件：[列表]
• 验证结果：所有门禁的状态表（PASS/FAIL）
• 成功标准：均已验证
• 延期事项摘要：数量及 GitHub issue 编号
• 功能跟踪器更新：已更新的功能及百分比
• 新发现的注意事项：[记录以供日后参考]
• 建议：后续工作或精选规则更新

提示用户选择下一步操作：

• 提交变更（推荐）→ 运行 /git:commit
• 为后续工作创建 work-order → 运行 /blueprint:work-order
• 将模式整理为精选规则 → 运行 /blueprint:curate-docs
• 继续执行下一个 PRP → 运行 /blueprint:prp-execute [next]
• 暂时结束 → 退出

Agentic 优化

上下文	命令
检查 PRP 是否存在	test -f docs/prps/${1}.md && echo "EXISTS" || echo "MISSING"
提取置信度	head -50 docs/prps/${1}.md | grep -m1 "^confidence:" | sed 's/^[^:]*:[[:space:]]*//'
列出所有 PRP	ls docs/prps/*.md 2>/dev/null | xargs basename -s .md
检查功能跟踪器	test -f docs/blueprint/feature-tracker.json && echo "YES" || echo "NO"
快速验证	尽可能并行运行验证门禁

---

有关验证门禁定义、延期事项工作流、错误处理流程和 Agent 团队协调的详细信息，请参阅 REFERENCE.md。