reliquary/docs/workpad/research/2026-10-15-12-superpowers-plan-anatomy.md

# Superpowers plan anatomy: why the plans look the way they do, and what Spire should keep

**Date**: 2026-10-15
**Model**: claude-opus-5-5 (Opus 5.5)
**Method**: read-only. Used the existing clones in `/tmp/sp-research/` (obra/superpowers full history at `bb92a77` = v7.0.0; mattpocock/skills `49dd158`; pcvelz not re-read beyond the prior note). Ran `git log` / `git show` / `git diff` across tags v6.3.0, v6.4.1, v6.4.2 and v7.0.0, and read `RELEASE-NOTES.md` and upstream's own design specs under `docs/superpowers/specs/`. I made two WebFetch calls to Jesse Vincent's blog for the original rationale. Those quotes come through WebFetch's summarizer, so they are second-hand (see "Could not verify"). Nothing in the clones was executed.
**Builds on**: [superpowers-alternatives](2026-10-15-11-superpowers-alternatives.md), [spire-superpowers-coupling](2026-10-15-11-spire-superpowers-coupling.md), brainstorm [implementation_thoughts](../brainstorm/2026-11-15-implementation_thoughts.md).
**Paths**: `sp:` = `/tmp/sp-research/obra/`, `mp:` = `/tmp/sp-research/mattpocock/`. Line numbers are at v7.0.0 unless a tag is given.

## Summary

1. Superpowers' plan format started as a **human-relayed, two-session setup**. An "architect" session wrote a plan for an implementer assumed to have "zero context and questionable taste". The human pasted batches of 3–4 tasks across with "DO NOT DEVIATE FROM THE PLAN". The detail exists so that nobody has to supervise execution.
2. From 2026-01 the format was re-purposed for **SDD's thesis: "a fresh subagent per task with precisely curated context, gated per task"** (stated in upstream's own spec). Tasks became the review unit. Each task had to be self-contained because a script cuts out one task per implementer, so tasks repeated code ("Similar to Task N" is banned), and each task got Interfaces blocks and its own five-step TDD cycle.
3. v6.4.2 (2026-09-25) removed "zero context/questionable taste", the 2–5-minute steps, complete code and "No Placeholders". The stated trigger was Opus 5.5 trying "to implement the entire project while designing the plan". Plans got 4× faster and used about ⅓ of the tokens, with equal planted-defect results on Sonnet 5. v7.0.0 did **not** touch writing-plans. Per-task structure, the TDD cycle, Review Focus and the SDD/Native handoff all remain.
4. **Mechanism of the 11×** (my judgement, based on cited facts): spacecraft's plans predate v6.4.2. A complete-code plan *is* the program, and every concrete line becomes a requirement that the per-task reviewer enforces. Per-task self-containment duplicates content, Review Focus adds tests by design, and the plan's self-review only ever adds. Nothing in the loop subtracts.
5. **Altitude that avoids it** (judgement): the plan carries what the code cannot tell the builder: intent, decisions, contracts and invariants, consumers of changed semantics (with file:line *as evidence*), scope fence, and the proof per phase. It has no bodies and no prescriptive "modify x:123-145". Module and file placement lives in the user's architectural orientation. Code appears only where the form *is* the decision (schema, wire format, state machine), which matches Matt Pocock's prototype exception.
6. **Keep / adapt / drop**: keep Global Constraints, Spec pointer, "a plan is the decisions the builder can't make alone", and a short self-check. Adapt Interfaces (cross-owner only), file paths (evidence and areas), verification (gate per block, tests per phase) and right-sizing (moved to phases). Drop 2–5-minute steps, complete code, the per-task TDD cycle, No Placeholders, checkboxes, the commit step, Review Focus-as-tests, and the execution handoff.
7. §4 gives a **proposed** lean skeleton (for the user to judge), annotated with which fields the attack and the phase reviewer consume.

---

## 1. Why superpowers plans look the way they do

### 1.1 Timeline (facts)

| When | Commit / release | What changed in the plan format | Stated reason |
|---|---|---|---|
| ≤2025-10-09 | `dd013f6` (initial plugin; skill already "version: 2.0.0") | Overview "zero context … questionable taste", 2–5-min steps, TDD five-step task template, exact paths, `Remember: Complete code in plan` | Blog (2025-10-05, via WebFetch): the plan is detailed so "at execution time, I usually don't need to provide tight step by step oversight". Two actors (architect and implementer sessions), with the human relaying batches: "Please execute the first 3-4 tasks … DO NOT DEVIATE FROM THE PLAN." |
| 2025-10-16 | `9c9547c` | Handoff offered "Subagent-Driven (this session) … review between tasks" or "Parallel Session … batch execution with checkpoints" (`git show 9c9547c:skills/writing-plans/SKILL.md:97-116`) | — |
| 2026-01-22 | `5e51c3e` | "Subagent-driven-development is now mandatory when harness supports it"; header names both executors | commit message |
| 2026-03-06 | `7b99c39`, `f3083e5`, `daa3fb2` | Checkbox steps "for tracking progress", "For agentic workers" header, File Structure / architecture sizing | commit messages |
| 2026-03-20/24 | `e6221a4` / `3f80f1c` | Plan reviewer subagent loop replaced by an inline Self-Review, and the **"No Placeholders"** section added | The review loop "doubled execution time (~25 min overhead) without measurably improving plan quality" across 5 versions × 5 trials |
| 2026-06-10 | `8e1262a` (+ spec `sp:docs/superpowers/specs/2026-06-10-strict-cost-sdd-design.md`) | **Task Right-Sizing**, **Global Constraints**, per-task **Interfaces** blocks | Fidelity and variance, "not dollars": constraints 0/5→5/5, Interfaces 0→100% of tasks, 9.4→8.4 tasks, 1 fix wave vs 2–4 |
| 2026-06-10 | `4298eac` | SDD `task-brief` script: cuts **one task** out of the plan for the implementer | (file handoffs, eval-tuned) |
| 2026-07-05 | `1e14b23` | "Remember" recap dropped as redundant | commit message |
| 2026-08-12 | v6.3.0 | `Spec:` pointer in header; SDD batches small same-shape tasks | RELEASE-NOTES.md:142-144 |
| 2026-09-18 | v6.4.1 | **Review Focus** section plus self-review item 4. Handoff becomes Subagent-driven vs **Native**, with a recommendation. The user must review the saved plan. | RELEASE-NOTES.md:82, 86-87 |
| 2026-09-25 | v6.4.2 (`8ca22db`, PR #2333) | "zero context" → "capable engineer"; 2–5 min → "one action with a checkable result"; Step 3 is now a signature plus one line, not a body; "No Placeholders" → **"What a Step Contains"**; **Proportion** check; plan reviewer prompt deleted | RELEASE-NOTES.md:53-61 (quoted in §1.3) |
| 2026-10-09 | v7.0.0 | **No writing-plans change** (`git diff v6.4.2 v7.0.0 -- skills/writing-plans/` is empty). Brainstorming rebuilt: the design now covers intent/goals/non-goals/constraints/"what's left to the builder" and hands to writing-plans "and no other skill" | RELEASE-NOTES.md:11-14; `sp:skills/brainstorming/SKILL.md:145-154, 179-193` |

### 1.2 Element by element: the assumption each one encodes (facts, with the assumption phrased by me)

| Element | v6.3 (`git show v6.3.0:…`) | v6.4.2 / v7.0 (current) | Assumption it encodes | Where the rationale is stated |
|---|---|---|---|---|
| **Overview / reader model** | "zero context for our codebase and questionable taste … don't know good test design" (:10-12) | "has not seen this codebase or this spec … writes idiomatic code once they know the exact interface and the exact test" (:10) | v6.3: the executor is a weak, untrusted outsider (originally a second human-relayed session). v6.4.2: the executor is capable but **sees only the plan**, not the conversation or the design discussion. | Blog 2025-10-05 (via WebFetch); RELEASE-NOTES.md:59 |
| **Header** (Goal / Architecture / Tech Stack / Spec, REQUIRED SUB-SKILL line) | :58-80 | :54-89 | The executor is a *different agent* that must be routed into SDD/executing-plans, and needs a 3-line orientation because it never saw the design. `Spec:` exists so "conflicts get resolved against the design instead of guessed at". | RELEASE-NOTES.md:144 (#2086); `5e51c3e` |
| **Global Constraints** | :72-77 | :70-75 | Constraints get lost when a controller pastes per-task briefs. A fixed heading makes them "mechanically extractable" into every brief. | strict-cost spec:97-103 ("a `go 1.26.1` floor violation shipped because none did"); `8e1262a` |
| **Review Focus** | — | :77-87, self-review :173 | The spec is a "vision document"; "its silence on an input is not permission for that input to break the program"; implementers ship the same crash on implied inputs. Encodes: **the plan should widen test coverage beyond the spec**. | RELEASE-NOTES.md:87 ("every implementer shipped the same crash on an input the spec implied but never named", #2319) |
| **File Structure** | :25-34 | :23-32 | Decomposition gets locked in at plan time. "You reason best about code you can hold in context at once" (smaller files help agents). | `daa3fb2` |
| **Task right-sizing** | :36-43 | :34-41 | **"A task is the smallest unit that … is worth a fresh reviewer's gate"; split only "where a reviewer could meaningfully reject one task while approving its neighbor."** The task *is* the per-task review unit. | strict-cost spec:54-62 (the thesis guardrail: "a fresh subagent per task … gated per task"; batching is "counter-thesis"), :89-95 (each micro-task costs "~$0.60-1.00 fixed overhead") |
| **2–5 min steps** | :45-52 | :43-50 renamed "one action with a checkable result" | The executor needs micro-checkpoints, i.e. supervision by plan text instead of by a human. | Original 2025 text; dropped in RELEASE-NOTES.md:59 |
| **Complete code in steps** | Step 3 has a code block (:111-116); "code blocks required for code steps" (:139); `Remember: Complete code in plan` (9c9547c:92) | Step 3 = signature in heading plus one line of approach; a body "only for an algorithm they do not determine" (:121-125, :146-155) | The executor cannot be trusted to choose an implementation, so the planner writes it. With SDD, complete code also meant **transcription work for the cheapest tier**: "When the task's plan text contains the complete code … use the cheapest tier for that implementer" (`sp:skills/subagent-driven-development/SKILL.md:212-214`). | RELEASE-NOTES.md:53, 57 (why it was dropped) |
| **TDD five-step cycle** | :98-128 | :108-137 | Every task carries its own red/green proof, so a per-task reviewer has evidence. The executor "doesn't know good test design", so the planner writes the test. | Overview :12 (v6.3); TDD skill iron law |
| **No Placeholders** | :131-139, including "'Similar to Task N' (repeat the code — the engineer may be reading tasks out of order)" | replaced by "What a Step Contains" (:140-161) | The executor sees **one task at a time** (later literalized by `task-brief`, `sp:skills/subagent-driven-development/scripts/task-brief:1-4, 30-36`; "A task's implementer sees only their own task", writing-plans :105-106). It also assumes weaker models write placeholders. | `e6221a4`. Note upstream's own test: "Current-generation opus does not produce plan placeholders even under deliberate pressure, with or without the banned-patterns list" (0/60 plans; `sp:docs/superpowers/specs/2026-06-10-positive-instruction-redesign-design.md:146-156`). The section was kept only because "it costs little". |
| **Exact file paths** (`Modify: exact/path:123-145`) | :87-90 | :97-100 | The executor doesn't know the codebase, and the controller should not have to re-derive locations per dispatch. | 2025 text ("which files to touch for each task") |
| **Interfaces (Consumes/Produces)** | :92-96 | :102-106 | Tasks are built by different, isolated agents, and the controller "re-derives cross-task interfaces per dispatch" while "implementers spend ~13 tool calls re-discovering context". | strict-cost spec:104-108; `8e1262a` |
| **Verification commands + expected output** | :106-121 | :116-130, :152-153 | Claims are not trusted; each step has a mechanical pass criterion, which the reviewer and the `task-done` ledger check. | executing-plans `task-done` (v6.4.1, RELEASE-NOTES.md:81) |
| **Commit step / checkboxes** | :123-128; "- [ ]" | same | One commit per task gives SDD a `BASE..HEAD` range per task review. Checkboxes are for tracking. | `7b99c39` |
| **Self-review** | 3 checks (:141-151) | 5 checks, adding Review Focus and Proportion (:163-177) | Replaces a subagent plan-review loop that cost ~25 min for no measurable gain. Note "If you find a spec requirement with no task, add the task": the review only adds, except for Proportion. | `e6221a4`; RELEASE-NOTES.md:58 |
| **Execution handoff** | "Subagent-Driven (recommended)" vs "Inline" (:153-171) | user reviews plan, then picks Subagent-driven or Native with a recommendation (:179-204) | The plan is a contract between two different execution modes, and a human must approve the *written* plan ("Approving an idea or a scope no longer counts as approving a plan you haven't seen"). | RELEASE-NOTES.md:82, 86 |

### 1.3 The v6.4.2 turn in upstream's own words (fact)

> "Some frontier models, including Opus 5.5, could get overzealous during plan writing and, with certain prompting, would sometimes try to implement the entire project while designing the plan. … When we reproduced the original report, the scratch builds went away, and plans took a quarter of the time and about a third of the tokens." (RELEASE-NOTES.md:53)
> "Every plan written by the new skill executed 9/9 against planted-defect probes on Sonnet 5, the same result as full-code plans." (:60)
> "A plan is the set of decisions the implementer cannot make alone. A plan longer than the code it describes has written the code instead." (`sp:skills/writing-plans/SKILL.md:157-158`)

Upstream also measured earlier that **complete-code plans were cheaper to execute** under SDD than hand-written prose plans (strict-cost spec:73-77: "The cost win belongs to opus-written complete-code plans; the hand-written prose fixture plans … ~2× costlier to execute"). The economics flipped once the *planner* (Opus 5.5) became the expensive part.

### 1.4 The brainstorming → plan → execution handoff (facts)

- v6.3: brainstorming classified the work as spike/bounded/architectural. The architectural path produced a spec covering "architecture, components, data flow, error handling, testing", followed by writing-plans (`git show v6.3.0:skills/brainstorming/SKILL.md:186` for the coverage list, `:103, 230` for the handoff).
- v7.0: the design is deliberately **intent-level**: "intent and the why; goals, non-goals, anti-goals; constraints; the parts of the how they decided; what's left to the builder" (`sp:skills/brainstorming/SKILL.md:145-154`). A non-goal of the rebuild is "Designing architecture the human didn't ask to decide … the rest belongs to the builder" (`sp:docs/superpowers/specs/2026-10-05-brainstorming-rebuild-design.md:116-119`). The HARD-GATE then forces writing-plans (:191-192).
- Consequence (judgement): in v7 the **plan is where architecture gets decided** (Header "Architecture", File Structure, Interfaces), and it is decided at signature granularity, for an executor who "cannot know what you decided". Upstream has no layer between intent and signatures. That missing layer is the user's "architectural orientation" step.

---

## 2. What is really useful for an Opus 5.5 builder in large blocks with one review per phase

Context (facts): Spire builds in blocks of roughly 11–36 min of agent work (186k–344k tokens; `plugins/spire/skills/implementation/references/models.md:48`), with a cheap gate between blocks, tests once per phase and one fresh adversarial review per phase (`plugins/spire/skills/implementation/SKILL.md:34-55`). The attack happens before the build (`:24-30`). The evidence that the per-task model was costly: 1.8 verification seats per build seat (`reports/2026-10-05-21-implementation-skill-redesign.md:22`); 11/13 re-reviews only confirmed the fix; active time per task went from ~10 to ~70 min, then halved under lean (`docs/workpad/research/2026-10-05-21-athanor-usage-spacecraft.md:32-33, 42, 50`). Lean was 35–40% faster with +1,417 vs +3,439 fix lines (`…-dirigent.md:84-86`). "About 4 of the 6 [Important findings] were plan gaps" (`models.md:37`).

**Judgement**, one line each:

| Element | Verdict | Reason (evidence) |
|---|---|---|
| "A plan is the set of decisions the implementer cannot make alone" | **Keep** (as the principle) | It is the right test for a capable builder. Apply it honestly: with the code available, many signatures are the *builder's* decision, not the plan's. |
| Header: Goal / Spec pointer | **Keep, as links** (goal, design, orientation, research) | The attack and reviewer must argue from the same sources (upstream #2086 had the same reason). |
| Header: Architecture / Tech Stack | **Drop** | The code and orientation doc say this. Restating it goes stale. |
| REQUIRED SUB-SKILL line, checkboxes | **Drop** | Spire routes execution itself, and the run log is the tracker (`run-log.md`). |
| Global Constraints | **Keep** | Cheap, measured (0/5→5/5, and one version-floor catch). The attack and reviewer check exact values. |
| Review Focus (5 failure modes → added tests) | **Adapt**: list "inputs/edges the design implies", and let the attack rule in or out (out goes to the scope fence). Not automatic tests. | The motivating eval finding is real (RELEASE-NOTES.md:87), but auto-adding tests is a scope vector by design, and Spire says the risk list is not the reviewer's scope (`implementation/SKILL.md:30`). |
| File Structure | **Move** to the architectural orientation; the plan references it | It is orientation, not sequencing. Duplicating it bloats the plan. |
| Task right-sizing ("worth a fresh reviewer's gate") | **Adapt to phases**: a phase boundary is where a reviewer could reject this phase while approving the previous one | The criterion is sound; Spire's review unit is the phase, not the task. |
| 2–5 min / one-action steps | **Drop** | Upstream dropped them too. Steps inside a block are the owner's business (coupling note I3). |
| Complete code in steps | **Drop** | 11× scope (spacecraft); upstream's 9/9 probes passed without bodies even on Sonnet 5; Opus 5.5 builds from contracts. |
| TDD five-step cycle per task | **Drop as structure; keep the intent** as "Proves:" per phase plus fail-first for bugs | Per-task red/green exists to give a per-task reviewer evidence. Spire runs the suite once per phase, and v6.4.1's "the project's suite defines green" makes per-task cycles expensive in Rust. |
| No Placeholders | **Drop the section; keep one line** ("every line decides something") | Upstream measured 0/60 placeholder plans from current Opus even under pressure (positive-instruction spec:146-156). |
| Exact file paths with line ranges as instructions | **Adapt**: paths only as *evidence pointers* (file:line backing a claim about a root cause or consumer) and as *areas* (modules a block owns) | The attack needs pointers it can check against the code. Prescriptive line ranges go stale within the run and pre-decide the builder's job. |
| Interfaces (Consumes/Produces) | **Adapt**: only where two owners or two phases meet, at contract level (type shape, invariant, error semantics) | Measured value comes from isolated per-task agents (the 13 re-discovery tool calls). Inside one owner's block it is noise. |
| Verification commands + expected output | **Adapt**: gate command per block and test command per phase, from `spire:project`; no expected-output transcripts | Cheap, and the reviewer runs the gates (`implementation/SKILL.md:52`). |
| Commit step per task | **Drop** (blocks commit) | `implementation/SKILL.md:38`. |
| Self-review | **Keep, short, and add a subtractive item** ("what can be cut against the goal?") | Upstream's checks are additive except Proportion. Spire's scope problem needs a cutting question. |
| Execution handoff (user picks SDD/Native) | **Drop** | Spire's cycle fixes the route: plan → attack → user sees the build plan once. The v6.4.1 lesson ("approve the written plan, not the idea") survives as that single checkpoint. |
| Per-task model tier (upstream L1 item 4, pcvelz `modelTier`) | **Keep as owner model per block** | Already in Spire's build plan (`implementation/SKILL.md:30`). |

**What only makes sense under per-task fresh subagent + per-task review** (judgement, from §1.2): task right-sizing as "a reviewer's gate", per-task self-containment (repeat code, Interfaces on every task), the per-task TDD cycle and commit, checkboxes, complete code as cheap-tier transcription, and the SDD/Native handoff. All of these exist so an isolated agent can execute and an isolated reviewer can judge **one task without the rest of the plan**. Spire's builder holds a whole phase, and its reviewer reviews a whole phase.

---

## 3. Plan size → code size

### 3.1 The mechanism (judgement, built from cited facts)

1. **The plan is written in the code's own medium.** With complete code (spacecraft's R1 plans were written 2026-09-24 and earlier, before v6.4.2 shipped on 09-25), plan length and code length are the same quantity. Upstream says so: "A plan longer than the code it describes has written the code instead" (`writing-plans/SKILL.md:158`), and Opus 5.5 "would sometimes try to implement the entire project while designing the plan" (RELEASE-NOTES.md:53).
2. **Every concrete line becomes an obligation.** The original contract was "DO NOT DEVIATE FROM THE PLAN" (blog). Under SDD the per-task reviewer checks spec compliance against the task text (`SDD/SKILL.md:8, 311`). The reviewer prompt adds "a spec's silence is not permission" (`requesting-code-review/code-reviewer.md:39`). Whatever the planner enumerated gets built *and enforced*. A thorough planner therefore produces a large program.
3. **Forbidding vagueness forces enumeration.** "No Placeholders" bans "handle edge cases" and "add validation" (v6.3 :133-139). The only allowed alternative is to write each case out as code and tests. A 5.5 planner, which "catches more, decides boldly" (`models.md:15`), writes every case it can think of.
4. **Self-containment duplicates.** Each task must stand alone because the implementer sees only its task ("repeat the code — the engineer may be reading tasks out of order"). Shared logic therefore appears N times in the plan, and tends to be built N times. This is the "functions that almost do the same" failure the user's orientation note warns about (`brainstorm/…implementation_thoughts.md:15`).
5. **Structural growth by design.** Every task has its own test cycle. Review Focus adds up to 5 extra tests. Self-review says "if you find a spec requirement with no task, add the task". No step removes anything except the late Proportion check, which compares against the *spec* and not the *goal*.
6. **Early freezing of the derived structure.** Exact signatures for every task fix abstractions before the code reveals the true data shape. This is the user's "some abstractions are derivative" point (`implementation_thoughts.md:14-15`). Later refactors then add code instead of replacing it.
7. **The review loop amplifies.** Per-task findings on behaviour the spec didn't cover go into the fix loop, and the fixer seat "often cost more than the draft" (spacecraft retrospective, `…-spacecraft.md:42`).

Attribution caveat (fact): spacecraft says "Superpowers supplies only the skeleton … Most of the weight is ours" (`…-spacecraft.md:31`). So the 11× is plan format × Opus 5.5 thoroughness × spacecraft's own additions. It is not the plan format alone.

### 3.2 Altitude that avoids it while keeping the attack effective (judgement)

The attack exists to find **blockers, design errors, wrong root causes, missed consumers** (`implementation/SKILL.md:26`). The user adds the "button that does nothing", the onboarding with no offboarding, error handling, security, and missed early abstraction (`implementation_thoughts.md:23`). None of these hide in function bodies. They hide in **contracts, lifecycles and consumers**. Code-level plans actually *hurt* the attack: the blunders sit under thousands of lines of transcription, and the attacker spends its budget reading bodies.

The altitude that serves the attack:

| Put in the plan | Keep out of the plan |
|---|---|
| Intent per phase as an **observable end state** ("Done when") | Function bodies; test bodies |
| **Contracts and invariants**: type *shapes* at owner boundaries, state transitions, error semantics, persistence/wire formats (code only where the form *is* the decision) | Every signature inside a block |
| **Consumers of changed semantics**, each with a **file:line evidence pointer** | Prescriptive "Modify x.rs:123-145" |
| **Areas** (modules/crates) each block owns, for ownership and collision only | Per-step file lists |
| **Proof**: named seams/tests and what each asserts, in a phrase; fail-first for bugs | The red/green/commit choreography |
| Decisions made, open user decisions, and `**Assumed:**` picks | Rationale essays (they belong in the design) |
| Scope fence: in / out / not now; deferred refactors | "While we're here" items |
| Lifecycle pairs and failure paths the design implies (create↔delete, onboard↔offboard, error/security) as **one line each** | Their implementation |

**Relation to Matt Pocock's `to-tickets` (fact, then judgement).** `to-tickets` says: "avoid specific file paths or code snippets: they go stale fast", with an exception for prototype snippets that encode a decision "more precisely than prose can (state machine, reducer, schema, type shape)" (`mp:skills/engineering/to-tickets/SKILL.md:105`). Tickets describe end-to-end behaviour, not "a layer-by-layer implementation list" (:73). `to-spec`'s "Implementation Decisions" lists modules, interfaces, schema and API contracts without paths or code (`mp:skills/engineering/to-spec/SKILL.md:43-57`), and agrees test seams up front, where "the ideal number is one" (:15). *Judgement*: Spire should take the altitude and the decision exception verbatim. It should diverge on file paths in one specific way. Matt's tickets live on a tracker for weeks, while a Spire plan is transitional and consumed within hours by an attacker *reading the code*. So file:line is fine **as evidence** for a claim (the attack checks it, and it is allowed to go stale after landing, consistent with "code is truth"). It is not fine **as an instruction**.

**Relation to the user's "architectural orientation" (judgement).** Orientation is the layer upstream v7 lacks (§1.4). It places the solution in the code (modules, files, structs/traits, approach) and separates pre-plan scaffolding (models, module skeletons, interface shapes) from post-plan refactors (trait polish, derived abstractions). If orientation carries the *where* and the *shape*, the plan only has to carry **order, contracts at boundaries, proof and fence**. That is what keeps it small. Two consequences:
- The plan should *reference* orientation, not repeat it. "Post-plan" items from orientation go into the plan's **Deferred** list, so neither the builder nor the reviewer treats them as missing.
- The attack checks the plan against **code and orientation** together: a block that freezes something orientation marked "derive later" is a finding.

Size guard (judgement; deliberately no number, consistent with the redesign report's "not encoded as numbers" ruling, `reports/2026-10-05-21-implementation-skill-redesign.md:141`): if the plan contains function bodies outside the decision exception, it is at the wrong altitude. If a phase can't be stated as one observable end state, it is too big or too vague. Proportion is judged against the **goal**, not the design.

---

## 4. Lean skeleton: **PROPOSAL for the user to judge, not a decision**

One line per heading. Consumers: **A** = attack, **R** = phase reviewer, **B** = builder/Athanor. Fields marked A are what the attack verifies against code. Fields marked R are what the reviewer answers or checks. Per `implementation/SKILL.md:30`, the risk list is deliberately *not* R.

```markdown
# <Feature> plan
Stamp: model id, date. Links: goal · design · orientation · research.        [A R B]

## Intent
Two or three lines: what changes for the user and why; the goal's bar.        [A: scope baseline · R: what "done" means]

## Decisions
Made (one line each, with `**Assumed:**` where picked) · Open for the user.   [A: verifies against code · user sees once]

## Constraints
Global values verbatim (versions, formats, naming, platform).                  [A · R: exact check · B]

## Scope fence
In · Out · Not now (incl. edges the design implies that we chose not to cover). [A: cuts · R: flags creep and omissions]

## Evidence
Current behaviour / root cause, each claim with file:line.                     [A: re-traces each]

## Consumers of changed semantics
Every reader (callers, stats, migrations, other crates), each with file:line.  [A: completes the list · R: checks each]

## Contracts and invariants
Shapes at owner/phase boundaries, state transitions, error semantics, formats.
Code only where the form is the decision.                                       [A · R · B]

## Phases
### Phase N: <observable end state>
- Proves: named seams/tests and what each asserts (fail-first if a bug).       [R: runs and judges · B]
- Blocks: N.a <intent> · area · produces/consumes (cross-owner only) ·
  owner model (suggested) · gate · may stay broken.                             [A: reshapes · B]
- Done when: observable criteria.                                               [R]

## Deferred
Post-plan refactors from orientation; follow-ups.                              [R: not "missing" · A: checks nothing frozen early]

## Risks and hotspots
Where it can go wrong; whether one earns an extra review, and why.             [A: review placement, owner models · not R]

## Self-check
Goal coverage · cross-block contract consistency · lines that decide nothing ·
what can be cut · bodies outside the decision exception.                       [planner only]
```

Notes on the proposal (judgement):
- It is already in **build-plan shape** (phases → blocks), so the attack can *amend* (a dated section or a short delta) instead of rewriting. That addresses the duplication gap in the coupling note §2.2.
- The fields the attack consumes most are Decisions, Evidence, Consumers, Contracts, Scope fence and Risks. The reviewer consumes Done when, Proves, Contracts, Constraints, Scope fence and Deferred, plus the run log's handoff flags.
- Deliberately absent: steps, function bodies, per-block test code, checkboxes, commit steps, execution-mode choice, and a "Review Focus" that adds tests.
- Open question for the user: should Contracts and Areas live in the orientation doc (and the plan only references them), or should orientation fold into the plan as a section for small work? The brainstorm treats orientation as its own step; for small changes, a separate doc may cost more than it saves.

---

## Could not verify

- **Blog quotes** (blog.fsck.com 2025-10-05 "How I'm using coding agents in September 2025", and 2025-10-09 "Superpowers") came through WebFetch's summarizing model. They are presented as verbatim but I did not see the raw page.
- **The pre-repo origin** of "zero context / 2–5 min / complete code" lives in obra/superpowers-skills or earlier; the skill was already "version: 2.0.0" at `dd013f6`. Not inspected.
- **PR #2333 and #2319 discussions**, Harper Reed's session bundle and the `superpowers-evals` experiment log cited by `8e1262a` were not read (outside the clone; `gh` not tried). All eval numbers are upstream's self-reports.
- **Which superpowers version spacecraft ran** when its R1 plans were written is not verified. I infer it was pre-v6.4.2 from dates only (plans ≤2026-09-24, v6.4.2 released 2026-09-25). The 11× metric (bytes? lines?) and the 77k-line figure are second-hand via the 2026-10-05 survey. Spacecraft and dirigent are not on this machine.
- **v7.0.0 brainstorming's effect on plan size** is untested: no runs were made.
- **The skeleton in §4 is untested.** No plan was written or attacked with it.