executing-plans
Use when you have a written implementation plan to execute in a separate session with review checkpoints
- License 许可
- MIT
- 最近更新
- 2026-04-30
- Stars
- ★ 1
- Forks
- 2
01 前言 Front Matter
- name
- executing-plans
- license
- MIT
- metadata
- { "harness-author": "human", "harness-source": "https://github.com/obra/superpowers/blob/6efe32c9e2dd002d0c394e861e0529675d1ab32e/skills/executing-plans/SKILL.md", "harness-status": "active", "harness-license": "MIT", "harness-vendored-at": "2026-04-28", "harness-source-commit": "6efe32c9e2dd002d0c394e861e0529675d1ab32e", "harness-license-source": "https://github.com/obra/superpowers/blob/6efe32c9e2dd002d0c394e861e0529675d1ab32e/LICENSE" }
- description
- Use when you have a written implementation plan to execute in a separate session with review checkpoints
02 资源文件 1
- 参考文档evals/triggers.json3.2 KB
03 SKILL.md 正文
Executing Plans
Overview
Load plan, review critically, execute all tasks, report when complete.
Announce at start: "I'm using the executing-plans skill to implement this plan."
Note: Tell your human partner that this skill works much better with access to subagents. The quality of work will be significantly higher if run on a platform with subagent support (such as Claude Code or Codex). If subagents are available, use superpowers:subagent-driven-development instead of this skill.
The Process
Step 1: Load and Review Plan
- Read plan file
- Review critically - identify any questions or concerns about the plan
- If concerns: Raise them with your human partner before starting
- If no concerns: Create a task list and proceed
Step 2: Execute Tasks
For each task:
- Mark as in_progress
- Follow each step exactly (plan has bite-sized steps)
- Run verifications as specified
- Mark as completed
Step 3: Complete Development
After all tasks complete and verified:
- Announce: "I'm using the finishing-a-development-branch skill to complete this work."
- REQUIRED SUB-SKILL: Use superpowers:finishing-a-development-branch
- Follow that skill to verify tests, present options, execute choice
When to Stop and Ask for Help
STOP executing immediately when:
- Hit a blocker (missing dependency, test fails, instruction unclear)
- Plan has critical gaps preventing starting
- You don't understand an instruction
- Verification fails repeatedly
Ask for clarification rather than guessing.
When to Revisit Earlier Steps
Return to Review (Step 1) when:
- Partner updates the plan based on your feedback
- Fundamental approach needs rethinking
Don't force through blockers - stop and ask.
Remember
- Review plan critically first
- Follow plan steps exactly
- Don't skip verifications
- Reference skills when plan says to
- Stop when blocked, don't guess
- Never start implementation on main/master branch without explicit user consent
Integration
Required workflow skills:
- superpowers:using-git-worktrees - REQUIRED: Set up isolated workspace before starting
- superpowers:writing-plans - Creates the plan this skill executes
- superpowers:finishing-a-development-branch - Complete development after all tasks
04 同仓库更多 Skills
research
Conduct research.
{{NAME=null}=null}
Briefly describe what this skill does AND when to use it. Use imperative phrasing ("Use this skill when..."). Aim for 80-500 chars. Include keywords the model can pattern-match against the user's prompt.
working-in-a-git-repo
Operating manual for dev work: worktree discipline, build/test/lint commands, file ownership zones, commit style, and a verification checklist before reporting done. Use when starting any feature/fix work in this repo.
test-runner
Runs the project's test suite (or a targeted subset), parses the output, and reports pass/fail with failing-test details. Use when you need to know test status; call with the test command to run, or leave blank for the project default.
reviewer
Reviews a diff or change set for bugs, security issues, test gaps, and style. Use when evaluating a code change, reviewing a pull request, or running a structured review pass before merge.
fix-failing-tests
Seven-step flow for diagnosing and fixing failing tests. Use when the user asks to fix failing tests, green the suite, or says 'tests are red' — works through reproduce → read → root-cause → propose → apply → verify → commit.