Menü
当你有一份书面实现计划需要在单独的会话中执行，并设有审查检查点时使用
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | executing-plans |
| description | 当你有一份书面实现计划需要在单独的会话中执行，并设有审查检查点时使用 |
| version | 1.0.0 |
| license | MIT |
| metadata | {"hermes":{"tags":["execution","planning"]}} |
加载计划，批判性审查，执行所有任务，完成后报告。
开始时宣布： "我正在使用 executing-plans 技能来实现此计划。"
注意： 告诉你的人类伙伴，Superpowers 在有子代理支持时效果好得多。如果在支持子代理的平台上运行（如 Claude Code 或 Codex），其工作质量会显著提高。如果子代理可用，请使用 superpowers:subagent-driven-development 而非此技能。
审查时重点检查：
npm test 全部通过"才算）审查示例：
计划文件：docs/plan.md
任务清单：5 个任务
审查发现：
- 任务 3（添加数据库迁移）应在任务 2（编写数据模型）之后，顺序正确 ✓
- 任务 4 的验证条件写的是"确认功能正常"→ 需澄清：具体跑什么测试？
- 计划未提及 Python 版本要求 → 需确认
向伙伴提出：
"计划整体可执行。有两个问题：(1) 任务 4 的验证条件不够具体，建议改为
'运行 pytest tests/test_api.py 全部通过'；(2) 需要确认 Python 版本要求。"
对于每个任务：
每个任务的节奏：
--- 任务 2/5：添加用户验证 ---
[标记进行中]
目标：为 /api/users 添加输入验证
完成标准：所有验证测试通过，无效输入返回 400
[实现]
- 添加 validateUser() 中间件
- 编写 3 个验证规则（email 格式、密码强度、用户名长度）
[验证]
$ npm test -- --grep "validation"
✓ 拒绝无效 email (12ms)
✓ 拒绝弱密码 (8ms)
✓ 拒绝过长用户名 (5ms)
3 passing
[提交]
$ git add src/middleware/validate.js tests/validation.test.js
$ git commit -m "feat: 添加用户输入验证（任务 2/5）"
[标记完成]
--- 任务 2/5 完成 ---
持续自查：
测试失败：
依赖缺失：
任务 3 需要 Redis 连接，但计划中没有提及 Redis 配置。
→ 停止执行
→ 向伙伴报告："任务 3 需要 Redis，计划中未包含配置步骤。
建议：在任务 3 前插入 '配置 Redis 连接' 步骤。"
指令不清：
所有任务完成并验证后：
完成报告模板：
## 执行报告
**计划：** docs/plan.md
**分支：** feature/user-validation
**任务：** 5/5 已完成
### 完成的任务
1. ✅ 初始化项目结构
2. ✅ 添加用户验证
3. ✅ 添加数据库迁移
4. ✅ 实现 API 端点
5. ✅ 添加集成测试
### 验证结果
- 单元测试：23/23 通过
- 集成测试：8/8 通过
- lint 检查：0 个警告
### 偏离计划的地方
- 任务 3：Redis 配置从 env 改为 config.yaml（经伙伴同意）
### 下一步
按 finishing-a-development-branch 技能处理合并/PR
在以下情况立即停止执行：
不确定时就问，不要猜测。
回到审查（步骤 1）当：
不要硬闯阻塞 — 停下来问。
必需的工作流技能：
在开始任何对话时使用——确立如何查找和使用技能，要求在任何响应（包括澄清性问题）之前调用 Skill 工具
在任何创造性工作之前必须使用此技能——创建功能、构建组件、添加功能或修改行为。在实现之前先探索用户意图、需求和设计。
当实现完成、所有测试通过、需要决定如何集成工作时使用——通过提供合并、PR 或清理等结构化选项来引导开发工作的收尾
当需要开始与当前工作区隔离的功能开发，或在执行实现计划之前使用——通过原生工具或 git worktree 回退机制确保隔离工作区存在
中文 review 沟通参考——话术模板、分级标注（必须修复/建议修改/仅供参考）、国内团队常见反模式应对。仅在用户显式 /chinese-code-review 时调用，不要根据上下文自动触发。
中文 commit 与 changelog 配置参考——Conventional Commits 中文适配、commitlint/husky/commitizen 中文模板、conventional-changelog 中文配置。仅在用户显式 /chinese-commit-conventions 时调用，不要根据上下文自动触发。