executing-plans

Overview of executing-plans skill

The executing-plans skill is for cases where the plan already exists and the main job is disciplined execution, not brainstorming. It tells the agent to load a written implementation plan, review it critically before starting, execute each step in order, run the plan’s stated checks, and stop to ask for help when the plan is blocked or unclear.

What executing-plans is best for

Use executing-plans when you have a concrete task list such as a feature plan, refactor checklist, migration sequence, or bugfix procedure that should be followed closely in a separate work session. It is especially useful for Project Management workflows where planning and execution are intentionally split.

Who should install the executing-plans skill

This skill fits teams and solo builders who:

• write implementation plans before coding
• want predictable step-by-step execution
• need checkpoint behavior instead of freeform autonomous changes
• care about surfacing plan flaws before work begins

It is less useful if you want the model to invent the plan from scratch.

What makes this skill different from a normal prompt

A generic prompt often jumps straight into coding. executing-plans adds a stricter loop:

1. read the plan
2. challenge unclear or risky parts
3. create a task list
4. execute tasks one by one
5. verify as specified
6. hand off to a finishing workflow when implementation is done

That review-before-action step is the main practical differentiator.

The most important adoption caveat

The upstream skill explicitly says quality is better with subagents and recommends using superpowers:subagent-driven-development instead when subagent support exists. So executing-plans is a good fallback for linear execution, but not the repo’s preferred path for more capable agent environments.

How to Use executing-plans skill

Install context for executing-plans install

If your agent environment supports remote GitHub skills, add executing-plans from the obra/superpowers repository, for example:

npx skills add https://github.com/obra/superpowers --skill executing-plans

If your platform uses a different skill-loading mechanism, install it the way that platform expects, then point the agent at the skills/executing-plans skill.

Read this file first

Start with:

• skills/executing-plans/SKILL.md

This skill has almost all of its useful behavior in that single file, so you do not need a long repository dig before deciding whether to use it.

What input the executing-plans skill needs

executing-plans works well only when you provide:

• a real plan file or pasted plan text
• the target repository or codebase context
• any required commands for validation
• constraints such as branch, environment, deadlines, or files to avoid editing

The plan should already be broken into small executable steps. If the plan is still strategic, vague, or missing verification instructions, output quality drops fast.

How to trigger executing-plans usage clearly

Do not just say “implement this.” Give the agent an explicit execution frame, such as:

• which plan to read
• whether it should raise concerns before making changes
• what counts as done
• what checks must pass
• when to stop and escalate

A strong invocation looks like:
“Use the executing-plans skill. Read docs/plan.md, review it critically before coding, flag any blockers first, then execute each task in order and run the listed tests after each section.”

Turn a rough goal into a good execution prompt

Weak input:

• “Use executing-plans for this feature.”

Strong input:

• “Use executing-plans on plans/search-pagination.md. Review the plan first and stop if any step depends on missing API fields. Work in order, update progress as tasks move, run npm test -- search and npm run lint where the plan asks for verification, and tell me before deviating from the plan.”

Why this is better:

• it identifies the plan source
• it defines stop conditions
• it limits improvisation
• it makes verification concrete

Suggested workflow in practice

A good executing-plans guide workflow is:

1. provide the plan
2. ask for critical review before edits
3. resolve any issues the agent raises
4. let it execute tasks sequentially
5. inspect progress against the original plan, not just final code
6. use the finishing workflow after implementation

This skill is strongest when humans own planning quality and the agent owns faithful execution.

Repository reading path for faster adoption

If you want to validate fit before installing:

1. read the Overview in SKILL.md
2. read “Step 1: Load and Review Plan”
3. read “Step 2: Execute Tasks”
4. read “When to Stop and Ask for Help”

That reading path tells you almost everything that affects real-world behavior.

Important boundary: it assumes the plan already exists

The executing-plans skill does not replace planning, task decomposition, or architecture design. If your team does not already produce actionable plans, you may feel underwhelmed because the skill’s value comes from structure and restraint, not ideation.

How executing-plans for Project Management fits best

For Project Management, executing-plans is most valuable when a manager, tech lead, or prior planning session has already defined:

• scope
• task order
• verification steps
• escalation conditions

That makes execution auditable. You can compare what was planned, what was executed, what blocked, and where the plan itself needs improvement.

The built-in handoff many users miss

After all tasks are completed and verified, the upstream skill requires a handoff to superpowers:finishing-a-development-branch. That means executing-plans usage is not truly finished at “code written.” It is designed to lead into final verification and branch-completion work.

executing-plans skill FAQ

Is executing-plans better than an ordinary implementation prompt?

Yes, if you already have a detailed plan and want less guesswork. No, if you need creative solution design. Its main advantage is disciplined execution with explicit review checkpoints.

Is the executing-plans skill beginner-friendly?

Yes, if a beginner already has a strong plan to follow. No, if the beginner expects the skill to create engineering judgment from thin air. The skill rewards good planning inputs more than prompting cleverness.

When should I not use executing-plans?

Skip executing-plans when:

• there is no written plan
• the plan is obviously incomplete
• the task is exploratory research
• your environment supports subagents and you can use the repo’s recommended subagent-driven-development workflow instead
• you need broad design options, not strict execution

Does executing-plans install anything inside my repo?

The skill itself is an instruction layer. It does not imply code dependencies in your project. Your repository changes come from the plan being executed, not from the skill package alone.

What blocks successful executing-plans usage most often?

The biggest blockers are:

• unclear plan steps
• missing dependencies
• failing tests before work starts
• instructions that depend on unstated files or environment setup
• humans asking for “follow the plan exactly” while also expecting the model to fill major gaps silently

Does this skill enforce stopping behavior?

Yes. The source explicitly says to stop and ask for help when blockers appear, when critical gaps prevent starting, or when instructions are unclear. That is one of the skill’s strongest safety behaviors.

How to Improve executing-plans skill

Give executing-plans a plan with executable granularity

The fastest way to improve results is to upgrade the plan, not the prompt. Strong plans for executing-plans have:

• small ordered tasks
• file-level or component-level targets
• verification commands
• decision points called out in advance
• clear completion criteria

A skill like this only performs as well as the plan it is handed.

Ask for a critical review before any code changes

Do not treat plan review as optional. The skill’s first meaningful step is to challenge the plan. Encourage that explicitly:

• ask for assumptions
• ask for missing prerequisites
• ask which steps seem risky or underspecified

That catches failures before the agent starts building on a bad sequence.

Make verification commands explicit

If you want reliable execution, provide exact commands such as:

• npm test
• pytest tests/auth
• cargo test
• pnpm lint

Without concrete checks, the agent may “verify” too loosely, and you lose much of the value of the executing-plans skill.

Define when the agent may and may not deviate

A common failure mode is hidden improvisation. Fix that by stating:

• whether the plan is authoritative
• when the agent may reorder steps
• whether it can patch minor gaps on its own
• which issues require approval first

This improves trust, especially in regulated or high-review repos.

Use stronger stop conditions

Good stop conditions improve both safety and speed. Tell the agent to pause if:

• a dependency is missing
• baseline tests already fail
• migration data is unavailable
• the plan references nonexistent files
• a step would require architectural changes outside scope

That matches the spirit of executing-plans and prevents low-quality “best effort” edits.

Improve the first run by attaching operational context

Useful context includes:

• branch name
• package manager
• test environment expectations
• restricted directories
• coding standards that must be preserved
• whether partial completion is acceptable

This matters more than adding extra motivational language.

Iterate after the first output with plan-level feedback

If the first pass is off, avoid vague feedback like “be smarter.” Instead say:

• “Step 3 was skipped.”
• “You executed before resolving the blocker raised in review.”
• “Use the exact verification command from the plan.”
• “Do not continue past task 4 until approval.”

That keeps iteration aligned with the skill’s execution model.

Pair executing-plans with a better finishing step

Because the skill is designed to hand off to finishing-a-development-branch, your overall workflow improves when you treat implementation and completion as separate phases. That gives you cleaner test confirmation, better review options, and less ambiguity about what “done” means.

If you have subagents, compare before standardizing

One practical improvement may be not using executing-plans at all for some teams. The source explicitly recommends a subagent-based alternative when supported. If your platform has strong subagent orchestration, compare both approaches before making executing-plans for Project Management your default execution path.