claude-code lastVerified: 2026-05-09

Superpower Core — Read-Plan-Run-Report Discipline

Anthropic's Superpower discipline distilled: read before edit, plan before write, run before claim done, report failures instead of papering over them.

On this page
  1. What this skill teaches
  2. The skill body
  3. Why this matters
  4. Where it fits in the loop

What this skill teaches

Superpower is the discipline Anthropic ships with Claude Code by default, distilled into four binding verbs: read, plan, run, report. Each verb names a step the agent is tempted to skip and therefore must not. The skill spells out what each step looks like in practice so the agent cannot collapse them into a single optimistic write that lands somewhere between hopeful and wrong. Treat the four verbs as a contract the agent owes you on every task, not as a checklist the agent ticks when the mood takes it.

The skill body

superpower-core.md
# Superpower core — agent baseline

Four binding verbs that gate every coding task: read, plan, run, report.
Each verb has an explicit shape. Skipping any verb is a failure, even
when the diff happens to compile.

## 1. Read before edit

Before any file is modified, the relevant call sites and adjacent
modules must be opened and shown. The agent narrates what it found and
what surprised it. Reading is not optional reconnaissance, it is the
gate that prevents the agent from inventing an interface that already
exists with a different name.

What read looks like:

- The target file, end to end, not just the function being changed.
- Every direct caller of the function being changed.
- Any `*.test.ts` files that exercise the function.
- The relevant types or schemas if the change touches a contract.

What read does not count as:

- Listing filenames without opening them.
- Grepping for one symbol and stopping at the first hit.
- Reading the readme instead of the source.

## 2. Plan before write

The agent states the change in three or four bullets before the first
edit. The plan names the files it will touch, the new behaviour it
intends, and the test or run it will use to confirm. A plan is not a
narrative essay, it is a map. If you cannot draw the map you do not
yet know what you are doing.

The plan must be visible in chat. A plan held only in the agent's head
cannot be inspected, contested, or remembered three turns later.

## 3. Run before claim done

Compilation is not running. Type-checking is not running. `pnpm build`
is the closest thing to running that the build system can provide, and
even that is not enough on its own. For backend code, the run is a unit
test that exercises the new path with realistic data. For frontend
code, the run is the dev server with the affected screen on screen.
For scripts, the run is the script itself with a real argument.

If running is not possible right now (CI is down, the seed data is
missing, the credentials are not on this machine), the agent says so.
"I have not run this" is an honest report. "It should work" is not.

## 4. Report failures, do not paper over them

When something fails — a test, a type-check, a manual reproduction —
the agent reports the failure verbatim. It does not silently retry
with a different approach, it does not mark the task done and add a
TODO. It surfaces the failure, names what it learned, and asks for
direction.

Patterns that count as papering over:

- Catching an exception to make a test pass.
- Mocking the call that was failing instead of fixing it.
- Lowering an assertion's specificity until it passes.
- Marking a test `.skip` because it was flaky.

Each is a way of converting a real failure into a fake success. The
contract here is that fake successes are worse than reported failures,
because the failure at least tells the user where to look.

## Sequencing

Read precedes plan. Plan precedes write. Write precedes run. Run
precedes report. None of the gates may be revisited in a different
order during a single task. Cross-task the order resets.

Why this matters

The most expensive failure mode in agent-driven coding is the looks-done outcome: the agent reports success, the diff compiles, the user moves on, and the bug surfaces three days later in production. Superpower’s four gates eliminate the looks-done outcome by construction. Reading produces a record of what was checked. Planning produces a record of what was intended. Running produces a record of what actually executed. Reporting produces a record of what failed. Each record is something a reviewer can audit; together they remove the ambiguity that hides bugs. The pairing with Karpathy coding is direct — Karpathy supplies the posture, Superpower supplies the structural enforcement.

Where it fits in the loop

Reach for Superpower core whenever a single coding task is on the table — a bug fix, a new endpoint, a refactor that lives in one or two files. This is the inner loop: read, plan, run, report. The outer loop, where work spans phases or sessions, is owned by GSD core. Wire both into a single agent-rules file via the generator linked at the bottom of this page so the agent encounters the full ladder on every turn.