Is the Ship It playbook over-prescribed for the models we have in September 2026? Two independent reads, one answer.
Jarvis, written before reading the reviewer
Wrong shape, not wrong amount.
Confidence 80%. The method puts ten refusing stops before the first line of code, and 38 of its 62 shipped checks watch whether the ceremony was followed rather than whether the app works.
Independent reviewer, given facts only
Wrong shape, not wrong amount.
Confidence 80%. The prescription sits where it buys least, watches the method instead of the artefact, and lives in files too large to still be in memory when they are meant to govern.
Tomo's repository starts on 2 February 2026 and 666 of its roughly 708 model-attributed commits name Opus 4.6. Ship It's own first commit on 12 March is co-authored by Opus 4.6 and assumes a 200,000-token session. The model has been swapped three times since (4.7, 4.8 with a 1M window, Opus 5), and Fable 5.1 arrived yesterday. So the gap is one generation and seven months. A December version 1 may exist; its repository is not on this machine, so it could not be dated.
The matrix and the Bridge ran under 221 machine-wide hooks (119 of them before every single tool call), about 51,000 words of standing rules, the full Ship It command library sitting in both projects, and the most experienced Claude Code operator on the machine driving by hand. What they lacked was the method layer: the interview, the screen inventory, the packs and phases, the three-agent build, the eight-step review. They kept the safety layer. That distinction is most of the answer.
It was bootstrapped with Ship It on 25 May, produced an 83-kilobyte spec with a "61-agent meta-audit" by 1 June, and then had no product code for two months. On 7 August its own commit reads "declare this repo as gate-exempt until code lands". The product that exists is a prototype you reviewed six times by eye, committed on 31 August at 22:12, given a real backend at 23:01, and hardened for three days into 108 tests. Same person, same machine, same models: the full method yielded a document, the informal loop yielded an app.
Twenty-two mockup screens before any code, corrected twice against your notes. Interfaces written as contracts before agents were spawned. One Opus 5 agent per file, each in its own isolated checkout. An adversarial pass after shipping that found 33 defects and confirmed 11 by running them. A self-test that gates install and a race detector added after a crash passed twenty green runs. That is the playbook's spec, design, parallelism, review and test-strength ideas, executed ad hoc in seven days at 30,000 lines. What it dropped is the ceremony around them.
| Build | Method used | Effort | What exists | Users |
|---|---|---|---|---|
| Findy (your iPhone app) | Full playbook | 292 commits, 11 days | 12,123-word spec, 18 design files, 15 features listed, 0 feature specs, 0 lines of app code | 0 |
| 41 founder walks (AI actor as founder) | Full playbook | $761 | No pack completed. Best: 4 of 5 phases. Deepest chain: 934 lines, of which 129 are product code, 82 tests green | 0 |
| The matrix | Playbook for the spec, then abandoned | 2 months idle, then 3 days | 4,052-line page, D1 backend, access gate, 108 tests, one XSS-shaped bug found and fixed | 2 |
| The Bridge | None named, half reinvented | 85 commits, 7 days | 30,081 lines of Swift, 74 self-checks, race detector, keyboard harness | 1 |
| Tomo | The playbook's ancestor, on Opus 4.6 | 827 commits since February | Live app | 323 |
Two things sit under that table. The walk figure is softer than it looks: 24 of the 27 walks with a recorded ending were killed by an API error, a budget cap or a stage cap, not by the method finishing, so "zero completed packs" is partly a statement about the test rig. And the only app in this story that has ever had strangers in it, Tomo, was built with the method's ancestor. The informal loop is ahead on apps built, at two to nothing, and has never been tested on a product for the public.
About 150 rules, gates and anti-patterns across the guide and the five largest commands were each tagged with the failure they were written against.
30% encode a human decision or an external fact: what the app is, whose taste governs, what must never leak, what the store requires. Model-independent, must survive. 21% were written against the two Opus 4.6 weaknesses that have moved most: claiming done without testing, and losing the thread as a 200,000-token window filled. 49% compensate for other model behaviour observed at the time.
The navigator says that when a session compacts, only about the first 5,000 tokens of a command survive. The build command is about 30,000 tokens, so after any compaction roughly 83% of it is gone, including the pivot rule and the score ledger in its last third. This is why the question is shape rather than amount: trimming that command by half changes nothing, while moving the pivot rule into a check that fires on the ledger changes everything.
This is the finding both reads hold with the most confidence, and it is not about the model. The method's mass moved from building to describing. Your own findy build spent its 292 commits on state files, decision logs, open questions and the close routine; 36 commits are named "close". The repair loop fed itself: every walk defect became a rule, every rule a check, every check a hook; repairs were measured to inject new defects at 43%; the last 25 of the repo's 156 filed lessons describe a check that reported clean while wrong; 40% of the open defect rows are one repair programme's own tail. You named this on 17 August ("measuring became the project") and the machinery kept growing afterwards.
Why it happened is structural, not anybody's fault. The founder walk was an inspection instrument pointed at the library, so its output was library defects, so the library grew. The Bridge and the matrix were driven by a person touching a live app and saying what was wrong, so their output was app fixes and tests.
The path today, for an app with screens. First product code at stop eight.
Twelve stops, ten of them refuse if the one before is skipped. About 158,000 words of command text sit on this path.
The path both reads would build. Something to touch at stop three; four gates, each conditional.
The dashed step is advisory and generated on demand. Everything the assistant can decide, it decides and says so in one line; anything you cannot reverse, it asks.
Not a rewrite of the chapters. A different spine, with most of the current parts re-hung on it. The two reads reached this shape independently; the seven pieces below are the union, with the one place they differ marked.
Your instinct that the person needs a control is right and the North Star already demands it. Both reads say the same thing about the shape: one slider from "more human" to "more AI" would take the dial away in the act of offering it, because it lays one axis over three things a person with taste holds separately.
Look (colour, type, layout), feel (motion, sound, touch) and structure (screens, flow) each set to one of "I decide, you execute", "propose three, I pick" or "your call, tell me what you chose". Read by every design step. An architect wants "I decide" on look and "your call" on code; you wanted "your call" on both for the matrix and "I decide" on look for the Bridge, where you corrected 22 mockups.
Route by reversibility: anything you cannot undo (data model, sign-in, the stack, anything users get used to, anything that costs money) is asked at the moment it arises, with options priced; everything else is decided and logged. A standing "always ask me about" list in your own words: "colour, copy, anything on the home screen". And one genuine global that controls how much is explained, which fades. A single slider cannot say "you write all of it and I decide all of it", which is the commonest thing a person with taste wants.
Where the slider does belong, and both agree: as a preset offered once at the start that writes concrete values you can then see and change individually. "Take the wheel" writes an empty always-ask list; "walk me through it" writes a wide one. A preset that expands into visible settings is good. A slider that stays a slider is not, because you can never see what it did. My recommendation is the reviewer's shape, with my three rows as the vocabulary the always-ask list is written in.
One app, built four ways from the physiotherapy brief that already exists, so the elicitation is held constant. About $800 all in, two runs per arm, which is less than the halted release-gate programme cost and a fifth of the animation workstream.
| Arm | What it is | What it isolates |
|---|---|---|
| Full | Today's method, end to end | The baseline. Already run once; reached phase 2 of 8 |
| Thin | The seven-step spine above | Whether the redesign is at least as good |
| Bare | One agent, the brief plus acceptance criteria, no scaffold at all | Whether the method beats the model. Never run, and the whole point |
| Full minus judge | Today's method with the separate judge and its critique rounds removed | The one mechanism Anthropic names as obsolete |
Measures, all on the built app, judged blind to arm. Five core user tasks completed on the live app by a judge who did not build it. Eight planted hazards, one per security-floor row, written into the brief as ordinary requirements, so recall separates "the checks worked" from "the model was fine anyway". Test strength, by breaking the code on purpose. Rework, counted as lines written then deleted, which is what the North Star's "few tokens wasted" actually means. Six idiosyncratic founder decisions planted in the brief, counted as survivors, which is what "the dial belongs to them" actually means. Dollars and turns. And a blind ranking against the anti-slop catalogue, because craft has no instrument anywhere in the current library and this is the only way to get one.
The rule, written and committed before any arm runs. If Bare reaches 90% of Full's criteria at no worse hazard recall and 40% of the cost, the pre-code machinery is not earning its keep. If Thin reaches 95% of Full at equal recall and half the cost, Thin becomes the default and Full survives as an opt-in high-assurance mode for products at the "strangers" level. If Full-minus-judge equals Full, the critique rounds are deleted outright. Any arm that dies on an API error or a cap is re-run, not scored; that guard clause is what the 41 walks lacked. Blinding is an engineering step: fresh repository, squashed history, no command folder, or one directory listing tells the judge which arm it was.
Nobody knows. No control arm has ever been run in this repository, in $833 of measurement. That is the Bare arm above, and it costs about $40 to find out.
Its priority-one user is you, and your own builds route around it, twice, once under a deadline. A method its first user avoids has the wrong first user or the wrong shape. Today it is optimised for a synthetic founder that no real person resembles: an AI actor that can read every command file a founder cannot.
Today it is stop eight of twelve. In findy it is eleven days and counting. In the Bridge it was commit one. This is the single number that would have predicted every outcome in the table above, and nothing measures it.
After a compaction, about a sixth of the build command. The prescription is stored in a form that cannot be present when it matters. This is why a word-count cut would not help and a relocation would.
Yes. Six steps, a refusing check before the build plan, and in findy all six "ran ahead" of their place, because people design when the itch comes, not when the navigator says. The check should judge what shipped against your rules, not block planning.
The harness. The 24 work-watching hooks and the security batch are what make your machine safe; you said so yourself on 26 August, "safe because the guards refuse". The 38 method-watching hooks enforce a process whose value is unproven.
A search of every founder-facing command for a running cost total returns nothing. The founder is the person paying and the only person never told what it costs. Both hobby apps were built on a subscription where the bill is invisible; a third party on the API would not be.
The library ships 21 mobile-specific skills and has never built a phone app. Findy is the first attempt and has no code. The claim is untested in both directions.
Over-prescribe and you get findy: eleven days, no app. Under-prescribe and you get the matrix: an XSS shipped and fixed in a week, for two people who trust each other. The setting that governs that trade is blast radius, and it is missing from the current method and from the slider.