The plugin is one skill folder: Markdown, templates and a Python checker.

• The spine — SKILL.md, the file the agent reads every time the skill fires. It holds the phases, the gate lines, the two owner checkpoints and the hard rules. It ships at 13,500 bytes and 165 lines — exactly on its budget. The size is deliberate: an agent reads it in full on every run, so it has a byte budget. The first draft landed under that budget in one go, because a table had already decided which requirement goes in the spine and which goes in a reference file, before any text was written.
• Six reference files, each loaded only in the phase that needs it: review (the general prompt and the three lenses), verification, parallel work, owner communication, closing, and a short file for major multi-system work. That last one is labelled untested, and it is.
• Templates — the plan, a kickoff prompt for handing a stream to another session, an optional config file, and two ways to ask the owner questions: an HTML decisions page for tools that can publish one, and a plain Markdown decisions file for everything else.
• The checker — pm-check, a read-only Python script: one file, 1,362 lines, standard library only. It checks a plan’s shape: are the seven gate lines there, in order, with valid states; does every Definition of Done item say how it’s observed; does a “no open decisions” claim sit next to an unresolved flag; did a template placeholder get left behind; did the build start before the go; is a plan labelled “small” actually small. It carries its own embedded control, so if the checker itself is broken, it exits 2 (“could not check”) instead of reporting a clean plan. Plans written before this version get information notes only, never errors — the older format was never going to pass a grammar it predates. Its test suite runs 85 cases and fails if the count is off.
• The overlap guard — a pm-check overlap subcommand. Before a parallel stream is merged, it reads the real branch diffs and flags any file two streams both changed, or a stream that changed files outside the ones it owns. Planning who owns which files is the easy part. This checks what each stream actually changed.
• A config file, if you want one. Without it, the skill says which defaults it is using: where plans go, how ids are numbered, which steps are yours. With one, you can set your plans folder, your id scheme, the actions you’ve pre-approved, and your branch rule.

What’s deliberately not in the box: the rest of my own setup — my notes search, my save routine, my coordination scripts, my hooks. For each one, the skill states the plain fallback it uses instead (grep instead of a search index, the plan’s gate lines instead of a status file, and so on). You get the method without my scaffolding.

Before rebuilding, a research pass read back through the eight plans the old skill had produced, and counted.

What it found:

• 0 of 8 reached Gate (close): DONE. Five got as far as building.
• 0 of 8 had a re-measured value written into the plan. Several re-measure dates had passed with nothing re-measured.
• 7 of 8 had at least one gate or header line that disagreed with the body. The stale lines clustered in the latest gates and in the header — exactly where the next session looks first when it resumes.
• 7 of 8 were over the plan’s soft size budget of about 25 KB. The median was 38.8 KB, and the overage came mostly from sections the skill itself required.
• 8 of 8 declared the heavy review tier; 5 of 8 delivered it. Some ran past the three-pass cap with no escalation to the owner recorded.
• The owner set an appetite in only 3 of 8.
• Across the six plans that ran reviews: 342 findings.
• Authors kept inventing states the skill didn’t have: parked, a go for part of the scope, built but waiting on the owner. Each improvisation made the gate a little less machine-readable.

What consistently earned its cost:

• “Does it already exist?” as the first value question shrank the ask in 7 of 8.
• A fresh-context general review before the adversarial one found the premise errors an author can’t see.
• “Structural finding ⇒ rewrite, not banner” kept plans readable; the plans that stacked banners were the hardest to read.
• Definition-of-Done items that name how they’re observed — and are left unticked, with the reason, when they can’t be.
• The two owner checkpoints: the owner changed something in every plan that reached one.

What it changed in the new version: a gate grammar with the missing states built in; the gate lines as the only status source, so there’s no second header to drift; an absolute re-measure date with a fallback (“not measured — why”, and ask again); kill criteria with value triggers and pre-agreed actions, not just an effort line; pass counting with an owner decision past three; and a close test, because closing was the phase nobody reached.

The question was whether someone without my setup could install the skill and get a useful plan in one session. The obvious tester, a sub-agent, is a terrible stranger: it inherits my whole setup, including my live copy of the skill being tested.

The clean option was off the table. Claude Code’s bare mode would strip everything, but it needs credentials this setup doesn’t use. So the stranger had to be built from what a normal login allows.

The recipe: a headless Claude Code session that loads only project-level settings, no MCP servers, and the plugin from a local folder:

claude -p "<message>" --setting-sources project --strict-mcp-config \
  --plugin-dir <package> --output-format json

Then --resume for each following turn, one message at a time.

Prove the isolation first. One question before the real test: list your skills, and quote any CLAUDE.md you can see. The run reported only Claude Code’s built-in skills plus the package — no user skills, no CLAUDE.md, no memory, no hooks, no MCP. (That’s the run’s own report, which is why it was the first thing checked.)

Then a driver. A sub-agent plays the engineer. It reads only the brief an engineer would get, builds a toy repo of its own with something half-finished hidden in it, and talks to the headless stranger turn by turn: the ask, the answers at the first checkpoint, then one more turn — “go ahead” — to see whether the stranger treats that as permission to build. Two runs: one with every tool, one with no sub-agents, standing in for agents that can’t spawn them.

Harness gotchas that cost time:

• The prompt has to come before variadic flags like --allowedTools and --disallowedTools, and stdin should come from /dev/null, or the flags eat the prompt.
• total_cost_usd is cumulative across --resume. Take the last turn’s number, don’t add them up.
• A headless run in a folder Claude Code doesn’t trust yet can be denied every write. The fix is in the command, not the package: --add-dir <repo> --allowedTools Read Write Edit Bash Glob Grep Skill.
• Disallowing the Agent tool alone still leaves the Workflow route open. Block both.

What this does not prove. The stranger is Claude playing a stranger, and the install was simulated with a local folder. Discovery — whether the skill fires when nobody names it — is tested separately, by the trigger cases in the evals. The real install path is tested without a model in a throwaway home directory, because a model run needs a login that a throwaway home doesn’t have. It passed: add, install and details each exited 0, first from a local copy and again from GitHub after the push. People are the next test.

The re-runs on the new version ran on a fresh clone of the exported repo, three rounds, each with a run A (every tool) and a run B (no sub-agents). No round needed a fix to the package mid-run. The final pair:

The old version held up — both strangers reached the first checkpoint on turn 1 with no fixes needed — but they tripped in eleven places. Each one became a requirement for the new version.

1. The decisions page had no home without claude.ai. Both wrote it outside the repo, where a CLI user can’t open it, and fell back to plain-text questions. Now: no page tool ⇒ a decisions file in the repo, plus the questions inline.
2. Missing companions weren’t announced. One stranger admitted it had skipped the capture and review skills only when asked. Now: the first line of every run names each missing companion and its fallback.
3. Template text leaked into the plan — a line about project checkers, in a project with no checker. Now: the plan template carries no instructions, and a left-behind placeholder gets flagged.
4. Defaults were only partly stated. Now: a fixed defaults block whenever there is no config.
5. The header and status drifted: a “draft” id, an invented status vocabulary, a stale phase line. Now: the gate lines are the only status; there is no phase line to go stale.
6. “Go ahead” was read as covering the build. One stranger held back only because review had changed the design. Now: the build needs its own explicit go.
7. Choices users would notice were decided as “recommendations” while the gate said “open decisions: none.” Now: those are flagged, and the flag clears only when an owner decision answers it.
8. Review independence varied. One stranger briefed its reviewer with its own leads; a third of the findings were those leads coming back. The other withheld its reasoning — the better pattern. Now: reviewers get the owner’s words, never the author’s leads.
9. Too long for a small task. One run reached 11 owner questions, a 22 KB plan plus a review log, and 21 minutes, for a small feature. Now: a “small” size class with a two-question limit and a 10 KB plan.
10. Work outside the repo and the network — a scratch clone, a package install, review files dropped in a temp folder. Now: write only inside the project; no installs, clones or network writes before the second checkpoint without asking.
11. Where the plan goes, with no CLAUDE.md. Both guessed a plans/ folder at the repo root. Harmless here; undefined in the old version. Now: a defined order — config, the project’s existing convention, plans/ at the git root.

Did the fixes hold on the re-runs? Mostly. By the second round on the new version, nine of the eleven were fixed in both runs. Number 6 — “go ahead” read as covering the build — took two rounds and two new rules: in the first round one stranger built on a bare “go ahead” with a question open; in the last, the same setup refused. Number 9, too long for a small task, is still the weak one: a “small” change drew three review passes and ten questions, and the checker only warns about it now.

Every pass went to reviewers who had not written what they were reviewing. Each got a frozen copy of my words — the original ask, my decisions, the constraints — and nothing from the author about where to look. Each finding was re-checked at the source before anyone acted on it (or marked as taken at the reviewer’s word), then routed: fix now, defer with a backlog line, or owner decides. A problem the plan itself caused is never deferred.

Pass 1 — general, “improve it”: 25 findings, 14 structural. One fresh reviewer, the largest model. What it caught that the author couldn’t: the spec’s own checker rule would have flagged this plan as a violation; a decision said “build-time guard” and the spec had quietly delivered a plan-time one; the eval command couldn’t write files, so most graders could never pass; the article had no sanitize step of its own; and the forecast said three different things. Structural findings mean a rewrite, not a banner, so the next revision replaced the spec entirely.

Pass 2 — adversarial, three lenses: 29 findings, 5 structural. The general pass had improved the design; the lenses found that the mechanisms wouldn’t work: the export ran a tag check before the commit it needs, the lint step was pointed at a folder its pattern couldn’t see, the release scan missed file paths and commit messages, and the gate grammar contradicted itself. The correctness reviewer ran experiments in throwaway repos with an isolated home directory — four of its nine findings came from running things, not reading them. Afterwards, Claude confirmed nothing had leaked into the real config and removed the directory.

Pass 3 — the cap: 39 findings, 6 structural. Two of pass 2’s fixes were themselves wrong: a lint check requiring output the linter never prints on success, and a results folder the cutover’s move would have nested inside itself. The strict gate grammar, tried against older plans, didn’t fit how real gate lines are written, so plans written before the new version get warnings only. Three passes is the limit, and this one still had structural findings — so the next revision went to me unreviewed, with a question: spend a fourth pass? Claude didn’t decide that for me.

Pass 4 — the one the cap would have skipped: 43 findings, 35 distinct defects, 5 structural. Every structural one was a mechanism: after the cutover, git add through the old path fails because it has become a symlink; pass 3’s “older plans get warnings only” fix sat in the same paragraph as a rule that gave them errors; after the cutover, the export would have shipped my private design notes; and the spine had no plan for fitting 56 requirements into its byte budget.

The re-check after pass 4’s fixes (not counted as a pass): 10 findings. Four were a pass-4 fix applied in one place and missed in another, and one was Claude’s own count of pass 4, off by one.

The pattern, four times running: the general review changes the design; the adversarial lenses break the mechanisms; experiments find what reading can’t; and a fix needs checking as much as the thing it fixed.

A pre-publish scan of the working tree has a flaw that sounds obvious once you say it. Git doesn’t ship your working tree. It ships objects — every commit, every file path, every commit message, every author and committer identity, every tag message, all of history. A secret you deleted from the tree is still in there.

So the release scan for this plugin reads git itself, inside the export repo, and refuses to start unless it’s really in a repo with history:

• Content, across every commit: git grep -F -i -a -f "$PATTERNS" $(git rev-list --all). The -a reads files git considers binary as text. An earlier draft used -I, which skips them.
• File paths ever committed: git log --all --name-only --format= | sort -u | grep -F -i -f "$PATTERNS".
• Messages and identities: git log --all --format='%an%n%ae%n%cn%n%ce%n%B' | grep -F -i -f "$PATTERNS".
• Tags: tagger name, email and message, from git for-each-ref refs/tags.

The pattern file must be non-empty, with no Windows line endings and no byte-order mark — a BOM silently turns the first pattern into one nothing will ever match.

Reading the result: grep exits 1 for “no match”, which is the clean result. So every scan checks that each earlier stage of its pipe exited 0, and only then trusts the 1. Exit 0 is a hit. Anything else is could not check, which is never clean. An empty history doesn’t get scanned at all: with nothing to scan, the content search falls back to the working tree, which is the original bug again.

The canary goes first. Before any real scan counts, a throwaway clone gets a planted commit whose path, message and content each contain a planted marker, plus an annotated tag whose message contains one. All four scans have to hit. A scan that has never been seen to fail isn’t a scan.

Then two more gates: an install test in a throwaway home directory, so nothing touches the real config; and a full sanitize review of the exported tree (what that is), repeated until two passes in a row come back clean.

How it went: the canary hit in all four scans, and so did a control run against a repo known to contain a marker. Then all four scans over the export’s full history came back clean. The sanitize review took three passes to get two clean in a row.

One real use was a small feature for a private family site, run on the old version while the new one was being built. The notes worth keeping:

• The first checkpoint was already answered. I’d given the go, the priority and the key decisions in conversation before the skill loaded. Claude recorded my words as the decisions instead of asking again. The new version says so: answers given in the owner’s own words count, recorded with the quote, never as the build go.
• The value check found the biggest fact fastest: half of what I asked for couldn’t work yet.
• The general review earned its keep: 8 structural findings, including a wrong premise Claude had written from memory.
• The adversarial pass found 29 more, on the rewritten plan. Two lenses that couldn’t see each other’s work hit the same hole. When blind reviewers converge, believe them.
• “Fixes introduce drift” was literal. The rewrite after the first pass produced 11 consistency defects — old names, a stale goal, a wrong file name. A consistency-only pass caught them.
• The safety layer held. One fix needed a production write. Claude Code’s permission check refused it even with my go. Claude didn’t look for a way around; I ran the one-liner myself.
• The plan outgrew its budget: 37 KB against a soft 25 KB. Moving the review log to its own file brought it to about 31 KB. The new version does that by default.
• The second checkpoint came back as one pasted line from the decisions page. I overrode two of seven picks. One answer had gone stale while it waited. The new version re-checks each open question against what changed before applying the answers.

Three review passes, 54 findings, none left open, and no code written before the go.

How a with-versus-without test works. Claude Code’s plugin eval runs each test case twice in a sandbox — a fresh workspace and a fresh home directory — once with the plugin and once without. A judge model grades each run against written checks. The difference between the two arms is the skill’s effect, if the test has room to show one.

Why the first baseline said “barely helps.” Before rebuilding anything, I ran three tests on the old version, on Sonnet only, one run each. With the skill: 1.00. Without: 0.93. A difference of 0.07. Read flat, it looks like the skill barely helps. Read per test:

• Two tests had no headroom. Sonnet without the skill already listed every ask, kept the constraint and asked before building. Those tests measured habits a strong model already has.
• In one test the skill never fired. “Plan it and get it moving” didn’t match the description, so its “with” arm was a second baseline. Only an unscored “was the skill called?” indicator showed it.
• One test separated the arms: riskiest assumption, cheapest test, appetite, kill criteria. All three judge votes passed with the skill, none without.

So the new tests check only what the skill does. Nine cases, each with its own small fixture repo: the gate lines written in order · the value check left pending with a recommendation, not a verdict · a real re-measure date and kill triggers · the build waiting for its own go after an earlier “go ahead” · resuming at the right gate from a plan with a stale header · review with no sub-agents available · closing a plan without ticking what can’t yet be observed · a bare “go ahead” with one question still open (added after a stranger built on exactly that) · and one case that must not fire: “fix the typo in README.md line 3.” Two more test the opt-in line for plain feature requests.

The bar, set before any results came in: the outcome cases score higher with the skill wherever there is headroom; the safety checks pass (no owner call taken, no build before the go); the “plan it” case fires in at least 2 of 3 runs and the typo case in 0 of 3; Haiku’s scores are reported but don’t block. A case where the no-skill arm scores 1.00 every run is reported as “no headroom”, not counted as a win. The cap was $25 per model. Every case runs 3 times on each of Haiku, Sonnet and Opus; the review-without-sub-agents case gets its own invocation with the sub-agent tools switched off.

What the grader probe found first. A probe on two cases, for $0.74, showed that a grader told to look at “files” sees only the files’ names, and that a pattern hunting for gate lines in the transcript would pass on the skill’s own instructions, which are in the transcript too. So each structural check is anchored on the agent’s own write of the plan file, and that anchoring was checked against the real with-and-without transcripts before any case relied on it.

The trigger, tested properly. Over five runs instead of one, “can you plan two things” loaded the old description once. Rewritten around plain planning words, it went 3 of 3, “plan it and get it moving” 3 of 3, the typo fix 0 of 3.

The results:

Three runs per case and arm; scores are the mean; Δ = with minus without; “fired” = with-skill runs that loaded the skill (Sonnet / Opus / Haiku).

The bar: Sonnet PASS, Opus PASS, Haiku FAIL (reported, not blocking). Haiku’s miss is the last row: on a bare “go ahead” about an existing plan it never loaded the skill. Weak spots worth knowing: Opus never found the half-built code in the gate-lines case (0 of 3, hence its 0.67), and Sonnet wrote the re-measure date as an absolute date in only 1 of 3 runs.

Which text the runs used: Opus and Haiku ran every case on the released skill; Sonnet ran the two checkpoint cases on the released text and the rest on the text just before two late checkpoint edits. Two small changes came after every run and were not re-run. Spend on these final runs: about $9 on Sonnet, $31 on Opus, $1.40 on Haiku. The article’s “about $100” also counts the earlier eval rounds, the stranger tests and the probes.

One more thing the eval tool does by default: it publishes its HTML report to claude.ai unless you pass --no-publish. Reading --help before the first paid run is what caught it. If your results shouldn’t be public, pass it every time.