# Opinion: dropping superpowers, and what Spire should build instead **Date**: 2026-10-15 **Model**: Fable 5.1, model id `claude-fable-5-1` (from my system prompt) **Method**: read-only. Read the session journal, the three research notes, the brainstorm and the draft goal in the order given; checked claims against `plugins/spire/skills/implementation/SKILL.md`, `igor/SKILL.md`, `agents/athanor.md`, `designs/2026-09-22-development-cycle.md`, `references/models.md`, `references/run-log.md`, the 10-05 journal, the redesign report, the spacecraft/dirigent surveys, and this machine's plugin settings. No agents dispatched. Nothing else written. These are opinions for the user to weigh. Each section ends with how sure I am. --- ## 1. The direction is right, but smaller than it sounds Drop superpowers as the default: yes. The evidence supports it. But be precise about what is being dropped, because most of it already went in 0.2.0. What superpowers cost you (per-task review, five fix rounds, fixer seats pricier than drafts, the ledger) was removed from Spire ten days ago. The Athanor no longer preloads `subagent-driven-development`; the lean loop is in place. The spacecraft numbers everyone keeps citing (review+fix ≈ 2/3, 11× plans, 10→70 min per task) come from spacecraft's own `dispatching-orchestrator` running pre-v6.4.2 superpowers *plus spacecraft's own additions*, and spacecraft's report says so: "most of the weight is ours." None of it was measured on Spire 0.2.0. What is actually still coupled, after reading the files: seven "optional toolbox" lines, the `writing-plans` format leaking in whenever a dispatched planner has the plugin enabled, and the SessionStart hook. That last one is narrower than the researchers imply. On this machine superpowers is *not* enabled (not in `~/.claude/settings.json` enabledPlugins, not in this repo's `.claude/settings.json`; only a 6.4.1 cache exists). It bites where dirigent and spacecraft enable it at project scope, and in this repo's `.codex/config.toml`. So 0.2.2 is a documentation and configuration change. That is good news: it is cheap and low risk. It is not where the win is. On 10-05 the user said "superpowers not abandoned, rules changed." On 10-15 it is "drop as default." Both are defensible; the shift is driven by Rust pain on 5.5 and it is the user's call. I only note that the pain being described (scope beyond the plan, review+fix dominating) is the *pre-0.2.0* pain, and nobody has yet checked whether 0.2.0 fixed it. See §6. Confidence: high on what is and is not coupled. High that 0.2.2 is cheap. ## 2. The 0.2.2 / 0.3.0 split and the vacuum between The split is sensible. One thing I would move earlier. The goal leaves "between 0.2.2 and 0.3.0, what shapes plans?" open. Do not leave a vacuum. `implementation/SKILL.md:85` disclaims plan formats, and that disclaimer is the hole `writing-plans` fills. Replace it in 0.2.2 with one paragraph: a plan carries intent per phase, the decisions the builder cannot make alone, consumers of changed semantics with evidence, a scope fence, and what proves each phase; no function bodies. That is ten lines, it is a prep, and it immediately lets the attack trim instead of reformat. Reliquary's own plans are already free-form Spire-ish shapes and worked fine, which tells you the attack does not need a rigid format. It needs the planner to stop writing code. On inside-Spire vs own plugin: inside Spire, and start as references, not skills. The content is Spire-shaped (phases, blocks, the attack, the build plan). A standalone plugin would either have to know Spire's vocabulary or would be a lighter `writing-plans` with no attack behind it, which the user's own evidence says is the weak half. The three-skill argument (`spire:design` / `spire:plan` / `spire:handoff` to win trigger wars against `brainstorming` and `writing-plans`) only matters if superpowers stays enabled in the same project, and the goal already says: disable it. If 0.2.1 lands pinned planner/reviewer role agents, `skills:` preload in their frontmatter is the clean delivery path, and then one `spire:plan` skill (design and orientation as reference files inside it) is enough. Extract to a plugin never, unless someone without Spire asks. Confidence: medium-high on inside-Spire. Medium on "one skill, not three"; it depends on whether 0.2.1's role agents happen. ## 3. The user's insights ### Drift is the cost, not up-front writing Mostly right, with one correction that makes it more useful. Up-front writing *was* measured as the cost once: upstream's own v6.4.2 notes report plans at a quarter of the time and a third of the tokens after removing complete code, and spacecraft's 11× plans turned into 77k lines of Rust. So the insight is true conditional on altitude. A plan with bodies drifts on every line; a plan with contracts drifts only when a contract changes. Altitude is the drift control. That links the user's insight to the researchers' keep/drop list: they are the same lever. The two-way drift point (reviewer's abstraction cuts 30%) is the most important thing said in the session and the proposals under-use it. Spire has a channel for *negative* drift (back to design, dated amendment; re-plan as a new file) and none for positive drift flowing forward into plans not yet executed. The user is right that "when to write plan N+1" cannot be a fixed rule. But there is a default that knows about drift: **plan the whole thing coarse, detail one phase ahead.** The attack needs the whole plan to find ordering errors and missed consumers, so phases as observable end states plus boundary contracts must exist up front. Block-level detail for phase N+1 gets written after phase N's review closes, with the run log and review in the planner's brief. This is what the Athanor's "one phase per turn" already does on the build side; mirror it on the plan side. Then positive drift from phase N is simply input, not a rewrite. Confidence: high on altitude = drift control. Medium-high on plan-coarse / detail-one-ahead; it is untested but it is cheap and structural. ### Audience per artifact Agree, and I would sharpen the design's human audience. The user says they usually read nothing before seeing the result. Then the design's human reader is *post hoc*: when the result is wrong, the human opens the design to see where the thinking went off ("trace back / align", the user's own words). That is a precise constraint: a design must be skimmable as an account of *why*, after the fact. Not a PRD, not a spec, not a set of user stories. Matt's `to-spec` has the right sections for this (Implementation Decisions, Testing Decisions with seams, Out of Scope) and the wrong name and a wrong section (User Stories do not fit Rust internals). Borrow the sections, keep Spire's word. One consequence of "plan → agents only" that nobody drew: Spire's single human checkpoint (`igor/SKILL.md:95`, "show the user the build plan and open decisions before the door closes") is effectively vestigial for this user. Keep it, but make the decisions list short and high-stakes only; anything else gets the closed-door conservative default anyway. Confidence: high. ### Rubber-duck effect vs condensing for agents Both are right and they do not conflict if you put the explanation in the right place. The plain-language explanation should be the plan's *Intent* and the design's *why*, which are the sections the post-hoc human reads anyway, not an extra artifact. Make the planner's self-check: "state each phase's purpose in two sentences a non-engineer could follow; if you cannot, the phase is wrong." That is the rubber duck, it costs a paragraph, and it doubles as the human-readable layer. Igor's "dense body plus plain explanation" is the same idea; I would just forbid the explanation from being a separate section that restates the body. Whether self-explanation improves an LLM's plan the way it improves a human's is plausible (it is close to what chain-of-thought does) but untested here. Speculation. ### Grill-me as brainstorm, not design Agree. `grilling` produces shared understanding, decisions and a frontier of zero; it does not produce a document. That is brainstorm output, and its natural artifact is a *goal* plus a short list of decided points for the designer. Igor doing light grilling himself is consistent with Igor's own rule that conversation is Igor's job. On Pinky: the user asked whether the distinction between "what are we building today" and "orienting, drifting toward design" is real or emotional. It is real but it is a distinction in *phase*, not in *agent*; both are conversation. The actual arguments for a separate Pinky are different ones: model choice (4.6 for reading the human) and, stronger, **context isolation**: a long grilling session fills Igor with design detail that Igor then carries for the rest of the session and relays into every brief. If grilling runs long, that is the reason to hand it to a Pinky. Speculation, but it reframes the decision usefully. ### Design ≠ spec Agree with the user's firm position, and the 12:05 wobble resolves cleanly: Matt's "spec" is Spire's "design" under another name; neither is an ISO spec. The only disagreement is vocabulary. Spire's `specs/` folder (invariants that must not drift: event shapes, error codes) is not spec-over-code either; it is a frozen contract that code must honour, which is code-is-truth with a memory. The naming collision will keep tripping agents. One line in the design guidance ("a design is not a spec; promote only invariants to `specs/`") covers it; `implementation/SKILL.md:75` already says the second half. The user's link between "a spec's silence is not permission" and scope creep is correct and, I think, the sharpest single diagnosis in the session. See §6a for what Spire is missing as a result. ## 4. Architectural orientation: adopt the content, not the step The brainstorm's step 2 is the best-observed gap in the whole set: upstream v7 has intent-level designs and signature-level plans and nothing between. The content list is right (modules, files, types, traits; pre-plan scaffolding vs post-plan refactors; test design; derivative abstractions you must anticipate). The plan-anatomy researcher is right that if orientation carries the *where* and the *shape*, the plan shrinks to order, contracts, proof and fence. I disagree with making it a separate document by default, on the user's own grounds. Orientation (files, structs, traits) is the most drift-prone content there is because it sits closest to the code. A third interdependent artifact in the 1→2→3 chain is exactly the drift the user named. The agents who most need it (attacker, builder) read the code anyway. And the researcher's own open question stands: for small work, a separate doc costs more than it saves. So: orientation is a **section of the design** by default ("where this lives in the code; what to scaffold first; what to derive later"), and a separate file only when one design feeds several plans and the structure must be shared across them. The pre-plan/post-plan split is the real nugget and should become plan fields: "Scaffold first" and "Deferred" (the skeleton already has Deferred). Test design splits the same way: "how we prove it" in the design, "Proves:" per phase in the plan. One caution: "academic approach (functional, DDD, clean arch…)" per feature invites agents to impose architecture. That is a project-level setting (`spire:project` or the project's CLAUDE.md), not a per-design question. The user's remark that a good human could implement from design + orientation alone, solving the rest on the fly, is an argument that for Opus 5.5 the *plan* is the artifact that should shrink most. That matches the skeleton's direction. Confidence: medium-high. ## 5. The researchers' keep/adapt/drop and skeleton The keep/adapt/drop table is sound. I agree with every "drop" (complete code, 2–5-min steps, per-task TDD choreography, No Placeholders, checkboxes, commit step, Review Focus as auto-tests, execution handoff) and with keeping "a plan is the decisions the builder cannot make alone", Global Constraints, and a subtractive self-check. The plan-size→code-size mechanism (every planned line becomes a reviewer-enforced obligation; nothing in the loop subtracts) is well argued and I believe it. Where I would push back on the skeleton: - **Eleven sections is too many for an artifact the user calls agent-only and transitional.** Opus 5.5's "thorough" trait means every heading gets filled whether or not there is content. Cut to six: Intent · Decisions (made, assumed, open) · Scope fence · Evidence and consumers (merged) · Contracts · Phases (end state, proves, blocks as intent, deferred). Say explicitly: omit empty sections. Confident. - **Do not put owner model, gate and "may stay broken" in the plan.** Those are the attack's outputs (`implementation/SKILL.md:30`). The researcher wants them in the plan so the attack can amend instead of rewrite; but then planner and attacker decide the same things and the attack degrades into a diff review. The plan and the build plan are not a drift pair: the build plan is produced minutes later and the plan is dead thereafter. Two files is fine. Medium confidence. - **"Evidence with file:line for every claim" is right for the attack and is also the fastest-staling content and the thing that tempts a 5.5 planner to read everything.** Keep it, scoped to root-cause and consumer claims only. - **The attack-does-double-duty claim is a hypothesis.** The one measured attack (dirigent, ~10 min) ran on a superpowers-format plan and was "the cheapest quality gate of the day." Fine as motivation; do not oversell it as the reason for 0.3.0. `spire:handoff` is the most over-engineered proposal in the set. The coupling note's own count says handoff/journal is ~70% covered, and the real gaps are one-liners: times from `date` in the journal template (today's journal has "11:05" on five entries, which proves the point), and "write the handoff note at block commit" (the run-log template already says the block owner writes it). A new skill plus `claude-code.md` and `codex.md` references on memory-vs-journal and compaction is speculation about harness behaviour nobody has verified. Fold the two lines into the existing templates; build nothing else until a concrete failure asks for it. Confident. Codex: both researchers correctly flag that Spire ships no Codex agents and this repo's `.codex/config.toml` enables superpowers and g4b_ai, not spire. Fix the config in 0.2.2 (two lines). The Codex spawning reference is a separate workstream; letting it into 0.3.0 would be scope creep in a project about scope creep. Vocabulary mapping across superpowers/Matt/Spire (a 0.2.2 prep item): I would not do it. Define Spire's four words in one paragraph where three of them already live (`workpad/SKILL.md:97-103`) and stop. A mapping table is documentation that drifts. ## 6. What everyone may be missing **(a) The cheapest scope control is in the reviewer, and Spire does not have it.** The user traced superpowers' scope creep to the *reviewer* rules ("silence is not permission", "YAGNI never downgrades a finding"). Spire's phase reviewer hunts weakened checks, tests that cannot fail and unanswered flags; all of those are additive findings. Nothing in Spire's review asks "what was built that the plan did not ask for?" Matt's Spec reviewer does exactly that. One line in the phase-review brief ("behaviour not in the plan is a finding, not a bonus; report it") plus "cut back to the goal" already in the attack closes the loop from both ends. This belongs in 0.2.2, not 0.3.0, and it may matter more than the plan format. Confident it is a gap; its effect is untested. **(b) Nothing proposed is Rust-specific, although "worst in Rust" is the complaint.** Two things are. Rust compile times are *why* per-task test loops hurt and per-phase runs are right; say so in `models.md` or `spire:project` so the rule has its reason attached. And Rust's trait system is precisely the "derivative abstraction" of the brainstorm: premature trait extraction is what 5.5 scope creep looks like in Rust. That is a project standing constraint ("no new trait unless two impls exist in this plan", or similar) for dirigent and spacecraft, not Spire doctrine. Speculation on the rule; confident on where it belongs. **(c) 0.3.0 is about to be designed against evidence from a process that no longer exists.** The 11× plans, the 2/3 review share, the 70-minute tasks are from spacecraft under superpowers' orchestrator, pre-v6.4.2. Upstream fixed the plan half in v6.4.2; Spire removed the loop half in 0.2.0; the attack trims scope. The 0.2.1 goal's first box ("read run logs from the first 0.2.0 dirigent/spacecraft passes") is unchecked. Before writing a design/plan skill, run one real Rust plan through 0.2.0 (or 0.2.2) and read what the attack actually had to change. If the attack mostly reformats, the plan format is the problem. If it mostly cuts scope, the planner brief and reviewer rule are the problem and the format barely matters. Right now nobody knows which. Confident this is the main sequencing risk. **(d) The user's own projects' plans were never superpowers-shaped and the attack handled them.** This suggests the honest minimum for 0.3.0 is a 15-line reference and a planner self-check, and the skill-shaped version should earn its place by a failure of the reference. **(e) Igor's premature verdicts** (11:11–11:30) have a structural cause the user already spotted: researchers write "Verdict: reject" and Igor relays. The fix is in the research brief, not in Igor: ask for findings and options, never verdicts. Both research notes from this session still end with "Reading the table for Spire's decision" and "Keep / adapt / drop." Good content, wrong register. One-line accretion to the researcher brief. **(f) Trivial:** the brainstorm filename is dated 2026-11-15; rename to 10-15 before it links from a goal. ## 7. Confidence summary Confident: - 0.2.2 is a doc/config change; the costly coupling went in 0.2.0. Superpowers is not enabled on this machine; the hook bites in project-scope installs and the Codex config. - Altitude is the drift control; the user's drift insight and the researchers' drop list are one lever. - The skeleton is too long; owner/gate belong to the attack; `spire:handoff` is unnecessary. - Spire's reviewer has no scope rule; that is the cheapest missing control. - 0.3.0 is being planned before 0.2.0 was measured. Medium: - Inside Spire as references first, one skill later if needed. - Plan coarse, detail one phase ahead, as the drift-aware default. - Orientation as a design section, separate file only for multi-plan designs. Speculation: - Rubber-duck self-explanation improves LLM plans the way it improves human ones. - Pinky's justification is context isolation rather than conversational mode. - Rust trait-extraction rules as the project-level scope fence.