home / Productivity / Executing Plans Skill by @obra

Executing Plans Skill by @obra

FREE

github stars★ 3,07,678updatedOct 2026repo@obra

activity (commits, last 6 months)

6mo ago1

this month2

$git clone https://github.com/obra/superpowers

The skill is the skills/executing-plans folder inside that repository. Copy it into the folder your agent loads skills from; check your agent's documentation for where that is.

about Executing Plans Skill by @obra

Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution.

our take

For carrying out a written implementation plan yourself in the current session, when no subagent tool is available or you have chosen inline execution. It works through a task loop, taking one task at a time.

when to use it

You have a plan and want the agent to work through it step by step
Subagents are unavailable in your setup
You want checkpoints after each task

before you install

Quality depends on the plan, so write or review it first
Its sibling, subagent-driven development, suits independent tasks better

what's inside

The original SKILL.md is organised into these sections:

When to Use
The Process
Setup
The Task Loop
1. Take the task
2. Work the steps
3. The completion contract
4. Complete the task
Final Review
Finish
Common Rationalizations

source and license

Written and maintained by @obra. It is published under the MIT license, which allows reuse with attribution. SkillDirectory does not claim authorship: this page adds our own review and links back to the original, and the skill's text belongs to its author.

View the full SKILL.md on GitHub ↗

Read the opening of the original SKILL.md

# Executing Plans

Execute the plan yourself, task by task, in this session: no implementer
subagent per task, no reviewer per task. One fresh-context review of the
whole branch at the end.

**Why inline:** Subagent-driven development pays for a fresh implementer
and a fresh reviewer on every task, each re-reading the codebase from zero.
Inline execution pays for one context (yours) plus one reviewer at the end.
What it gives up is a fresh context per task and a second pair of eyes per
task. This skill keeps what those two things bought, by other means: the
brief is the spec, the ledger is your memory, TDD is the per-task gate, and
the final reviewer is the second pair of eyes.

**Core principle:** The plan already did the thinking. Execute it exactly,
prove each step with a test you watched fail and then pass, and leave a
record that survives your own forgetting.

**Narration:** between tool calls, narrate at most one short line — the
ledger and the tool results carry the record.
…

Excerpt only, quoted from the author's repository. Open the repository for the complete file.

↓ download .zip