v1.0.9 — one comparison, three columns

v1.0.8 gave Superpowers its own section. That left two tables sharing half their rows, and a reader doing the join by hand — "what the plan must contain" got answered twice, in two places, against two different baselines.

One table now

Plan mode · Superpowers · /planfirst + /proceed, sixteen rows across:

what it is · span · how it starts · how edits are stopped · what opens the gate · what the plan must contain · are the sources current · the riskiest assumption · can each step be undone · who performs each step · what breaks between steps · how you know it worked · reality disagrees mid-run · where plans live · opinions about how you build · where it runs

The rows you are actually choosing between line up in one glance.

Honest in both directions

Merging forces the answer on rows where this package has nothing to show:

• Plan mode stops edits at the tool layer. This is a skill; the model is instructed not to edit. That is weaker, and the row says so.
• Superpowers ships TDD, worktrees, subagent execution, a review loop between tasks, plans persisted to disk, and roughly fifteen harnesses. Those rows are its.

A note under the table says what Not addressed means: a description of scope, not a criticism. A permission mode has no business dictating plan contents, and a methodology solving a different problem is not failing at this one.

The section is 23 lines shorter than the two it replaces, because half of what was there was the same sentence twice. No skill files changed.

v1.0.8 — compared against Superpowers

The README compared this package to Claude Code's plan mode and nothing else. That shows what it adds to a permission mode, and says nothing about the project people actually weigh it against.

The new section

Superpowers (MIT, by obra) is a full development methodology in fifteen skills — brainstorming a spec, git worktrees, plans written to disk, enforced RED-GREEN-REFACTOR TDD, subagent-driven execution, code review between tasks, branch finishing — across roughly fifteen harnesses. This package is two skills and one gate.

Comparing them feature-by-feature would flatter neither, so the section compares how much each one decides for you, and states plainly what Superpowers has that this does not. That is the longer of the two lists.

What this has that it does not

Checked rather than assumed: the words reversible, rollback, undo, one-way, assumption, stale and probe appear nowhere in the 192 lines of its writing-plans skill.

• A gate only one literal command opens. Superpowers proceeds when you sign off in conversation — "once you say go". Here, yes, ok, looks good and 👍 do not authorise execution.
• Source dating and a probe before planning. §0 asks whether each source is the record or a copy of one, then runs one read-only command to settle the riskiest assumption.
• Reversibility and ownership per step. One-way doors and interactive logins are visible before the step, not after.
• Landing order (§17). What lands first, and what is broken in between.

Running both

They overlap at exactly one point — the plan — and nowhere else. If you use Superpowers, writing-plans already owns that moment; adding /planfirst on top means two skills competing for it. The rest of Superpowers has no counterpart here and nothing to collide with.

Verified against the repository on 19 September 2026. No skill files changed in this release.

v1.0.7 — colour the plan

Plans were monochrome, and said the same thing twice.

What was wrong

A step was one bare ``` fence. A renderer had no language to colour by, so a diff and a shell command looked identical to a paragraph. And the edit appeared twice — once as - before - / `- after -`, once again inside the `git apply` heredoc. Two copies of one thing, free to drift apart.

What a step looks like now

The fields stay in a plain block:

STEP 2
What:            Apply the limiter to the checkout route
Where:           api/routes/checkout.ts:14-19
Expected Result: 21 requests in a minute returns 429 on the last one
Reversible:      yes — git apply -R with the same patch
Who:             me

Change — api/routes/checkout.ts:14-19

@@ -14,6 +14,7 @@ router.post(
   '/checkout',
   requireAuth,
+  rateLimit({ window: '1m', max: 20, by: 'userId' }),
   handleCheckout,
 );

Run

npm run lint -- api/routes/checkout.ts
git apply <<'PATCH'   # the diff above, verbatim
PATCH

Diffs render red and green in the terminal, on GitHub and on npm. Commands get shell highlighting. Each block has its own copy button — which serves the paste-it-yourself goal from v1.0.6 better than one undifferentiated block did.

The duplication is gone

If a step applies the diff above it, Run applies that block rather than restating it. One source of truth per edit.

The new failure mode, and the guard for it

A diff can fail in a way a before/after block never could: a wrong @@ offset breaks on paste. So the plan checks its own patches before you see them —

git apply --check   # changes nothing, so /planfirst may run it

— and the rule says to do exactly that.

Steps with no code keep the old shape

A decision, a login, a dashboard toggle: Change: n/a — <why> and Run: by hand — <what to click, where> stay as fields inside the single step block. Opening a diff fence for a step with no diff would be theatre.

/proceed, the eighteen sections and the stop lines are unchanged.

v1.0.6 — plans you can paste

A plan should be followable by a person, not only executable by Claude.

What was missing

Since v1.0.5 a plan shows the code it will change. It never showed what you type — the executing agent already knew, so the field was never needed. That quietly made every plan a dependency on the agent: it could not be handed to a colleague, pasted into a runbook, or followed six months later by the person who asked for it.

The field

STEP N
What:            exactly what will be done
Where:           file, service, table, resource or configuration —
                 with line numbers where they are known
Why:             why this step is necessary
How:             the intended approach
Change:          the edit itself — before and after
Run:             the commands to do it, exactly as typed
Expected Result: what is true once it is done
Reversible:      yes — how it is undone
Who:             me, or the user

Section 6 now states the working directory once, at the top, and every command is written relative to it — so the blocks paste in order and work as given.

The rules that travel with it

• Commands must work as pasted, in the order given, from that stated directory.
• Run and Change must agree. If pasting the commands would not produce the before/after shown above them, one of the two is wrong.
• A step no command can perform says Run: by hand — <what to click, where>. An interactive login, a console toggle, a one-time password — never dressed up as a shell line.
• Placeholders are <like-this>, with a line saying what fills them.
• A destructive command is marked and carries its undo on the next line: Reversible: says whether it can be undone, Run: says how.
• Not yet verified. where the command cannot be known until an earlier step runs.

The probe behind the design

The open question was whether file edits — the awkward case, and most of what these plans do — have a pasteable form at all. They do:

$ git show <commit> -- README.md | git apply --check -R -
$ echo $?
0

A unified diff lifted out of a repository applies through git apply, which is both reviewable and runnable. Shell commands were never in doubt; the edits were.

/proceed, the eighteen sections and the stop lines are unchanged.

v1.0.5 — show the code

Plans described the change. Now they show it.

The gap

Every field in §6's execution-step template asked about a property of the step — its reason, its reversibility, its owner — and none asked what the step actually does to the file. A reviewer got Update the header component and no way to tell whether the right file had even been opened. The one thing worth checking was the one thing the template never requested.

The field

STEP N
What:            exactly what will be done
Where:           file, service, table, resource or configuration —
                 with line numbers where they are known
Why:             why this step is necessary
How:             the intended approach
Change:          the edit itself — before and after
Expected Result: what is true once it is done
Reversible:      yes — how it is undone
Who:             me, or the user

and a Change: block looks like this:

Change:   web/components/Header.tsx:18-24

          - before -
          <nav className="flex gap-6">
            {LINKS.map((l) => <NavLink key={l.href} {...l} />)}
          </nav>

          - after -
          <a href={DOWNLOAD_URL} aria-label="Download the app">
            <DownloadIcon className="h-5 w-5" />
          </a>

The rules that travel with it

• Copy the before block out of the file — do not retype it from memory. It is the evidence that the file was read at the line the step claims, and a remembered one proves nothing.
• Excerpt what changes plus enough context to place it. Never paste a whole file.
• For a new file, show its content, or its skeleton if long — and say which.
• For one edit repeated across many files, show it once and list the rest with line numbers.
• Not yet verified. where the text cannot be known until an earlier step runs. An invented before block is worse than an absent one.
• Change: n/a — <why> for steps that change no code, which is most decision, login and release steps.

Where the code lives

In §6, and only in §6 — next to the reasoning that justifies it, so reviewing a step means reading one place. §14 keeps listing paths with reasons; §5 keeps describing responsibilities. /proceed is unchanged.

v1.0.4 — bound the re-investigate loop

A fix to the instruction added in v1.0.3.

The problem

1.0.3 said: if the probe contradicts your understanding, go back to INVESTIGATE. It said nothing about what happens when the second probe contradicts the second understanding. Read literally, that is a loop with no exit — and the failure mode is the one thing /planfirst must never do: burn the session and produce no plan.

There was a second reason the exit was needed. The Stopping section requires every run to end with the same two lines, and those lines presuppose a plan exists. A run that looped until it gave up had nothing to end with.

The fix

Go back once. If a second probe also contradicts what you found, stop probing and write the plan you can actually write:

• section 0 reports both probes verbatim
• every section that depends on the unresolved contradiction says Not yet verified.
• step 1 is whatever would settle it

Two failed probes mean the system is not understood yet, and the plan says so plainly. A third guess dressed as a plan is worth less than an honest account of what the system refused to confirm.

Nothing else changed: /proceed, the eighteen sections, the stop lines and the README are untouched.

v1.0.3 — VALIDATE, named

/planfirst   THINK → INVESTIGATE → UNDERSTAND → VALIDATE → PLAN → STOP

What changed

The /planfirst banner is the line people remember, and it left out the stage that makes this skill different from Claude Code's plan mode.

Section 0 has always required running the one read-only command that settles the riskiest assumption before planning further. But a reader met that only after committing to the whole 18-section document, so the pipeline they memorised was the one without it. It is now named in the banner and defined in its own section, ## Validate before planning.

One new instruction, and it is the point

When the probe contradicts your understanding, go back to INVESTIGATE. The skill previously said to run the probe and report what it returned, and said nothing about the case the probe exists for. Planning around a contradicted premise — or filing it as a risk and carrying on — is exactly the failure §0 was written to prevent.

The section also covers the honest-absence case: when nothing about a task can be probed, write Nothing to probe: <why> rather than inventing a command to look thorough.

Unchanged

/proceed, including its own "Validate as you go" (which means something different — checking work already performed). The eighteen plan sections remain eighteen: VALIDATE is a stage, not a nineteenth section. The stop lines and the list of words that do not open the gate are byte-identical.

Install

npx claude-planner

or, on any Claude Code surface:

/plugin marketplace add raketbizdev/claude-planner
/plugin install claude-planner

Already installed? npx claude-planner again, then start a new session — the skill list is read at startup.

v1.0.2 — the surfaces table, corrected against the documentation

No change to the skills or the installer. cli.mjs and both SKILL.md files are still byte-identical to v1.0.0. This is the README again — specifically the table that tells you where these skills can run, which had two wrong rows and a thin sources column.

claude.ai chat was marked as running no skills. It runs them.

Upload a skill under Customize → Skills with code execution turned on and it is available in chat. What chat does not give these two is anything to work on — no repository to read, no read-only probe to run, no files to change. That is a different statement, and it is the one the table should have been making. Both are in there now.

Claude Design now says "not documented"

Its help pages do not mention Agent Skills at all. That is a sourceable claim; "it runs none" was not.

Rows and sources that were missing

• Desktop scheduled tasks run on your machine, so they do load ~/.claude/skills/ — the one exception to the personal-skills warning this whole section is built around.
• The sources column never mentioned nested .claude/skills/, --add-dir, or enterprise managed settings.
• Syncing a skill through claude.ai is now described: it lands in ~/.claude/skills/synced/, re-checks about every ten minutes, answers to /anthropic-skills:<name> as well as the short name, and — outside Cowork and cloud sessions — has its ! lines, @ references and ${CLAUDE_PROJECT_DIR} passed through as literal text. Neither skill here uses any of that, so nothing is lost by syncing them.

Checked against code.claude.com/docs/en/skills and the claude.ai skills help centre article on 19 September 2026.

What 1.0.1 was

1.0.1 went to npm at 03:19:55Z on 19 September 2026 and fixed the install route: v1.0.0 pointed people at the community catalog, which does not list this plugin, so those lines failed for everybody who tried them. It shipped before this table was corrected, which is why 1.0.2 exists twenty minutes later.

Install

npx claude-planner

or, on any Claude Code surface:

/plugin marketplace add raketbizdev/claude-planner
/plugin install claude-planner