reliquary/docs/workpad/research/2026-10-15-11-spire-superpowers-coupling.md

Spire ↔ superpowers coupling, and what Spire must distill itself

Date: 2026-10-15 Author: Opus 5.5, model id claude-opus-5-5 (from my system prompt). General-purpose subagent dispatched by Igor; did the work myself, read-only except this file. Session journal: 2026-10-15-11-superpowers-opus55-era Superpowers source read: the locally installed copy, ~/.claude/plugins/cache/claude-plugins-official/superpowers/6.4.1/ (cited below as sp/…). The dirigent and spacecraft repos (/home/g4b/Projects/…) are not on this machine; their evidence is quoted second-hand from the two 2026-10-05 survey notes.

Summary

• Explicit coupling is small. There are 7 literal mentions in plugins/spire/: the implementation skill (3), athanor (1), workpad (2) and research-tree (1). All are "optional toolbox" or "steer its files into the workpad" lines. Nothing preloads superpowers any more (dropped in 0.2.0).
• Implicit coupling is the real one. (a) Spire never defines what a design or a plan contains. implementation/SKILL.md:85 and workpad/SKILL.md:131 both disclaim format, so whichever planning skill triggers fills the gap. With superpowers installed, that is writing-plans: bite-sized TDD steps with full code, a header that requires subagent-driven-development, and a user choice of execution method. (b) The superpowers SessionStart hook injects "if there is a 1% chance a skill applies, you MUST invoke it" into every main session, and its skill descriptions trigger on any bug, completion claim or "creative work". "Optional tools" therefore become auto-loaded ceremony in any session where the plugin is enabled.
• Spire already covers about 70% of handoff and journals, about 40% of plans and about 15% of designs. Handoff and journals: Igor journal template, run log with block handoff notes and trunk notes, adept handoff.md with a drift check. Plans: what the attack checks and what a build plan must set, but no plan document shape. Designs: "convergent, one buildable approach, **Assumed:** flags, dated amendments", and nothing about contents.
• Cost evidence: lean was about 35–40% faster with about 40% of the fix churn (dirigent). Spacecraft: about 1.8 verification seats per build seat, 11/13 re-reviews only confirmed the fix, 5.5 plans about 11× larger, and per-task time rose from 10 to 70 min, then halved under lean. Caveat: spacecraft attributes most of the weight to its own additions on top of the superpowers skeleton.
• Harness: Spire documents Agent/SendMessage/background/ListAgents/TaskStop/fork/model pins for Claude Code in detail. It does not use isolation: "worktree", plan mode, todos, Monitor, hooks or effort, and has nothing for Codex (its Codex manifest ships skills only, no agents). Most superpowers process helpers are superseded by harness features plus Spire's lean loop. The one exception is plan writing.

---

1. Coupling inventory

1.1 Explicit references in plugins/spire/

#	Location	What it does	Replacing / removing requires
E1	skills/implementation/SKILL.md:3 (description)	Ends with "Composes with workpad; superpowers skills are optional tools." It is part of the trigger text, so it tells the loader that superpowers belongs here.	Drop the clause. Replace it with "Design and plan formats: spire:design / spire:plan" (or wherever §5 puts them).
E2	skills/implementation/SKILL.md:32	"Plan-writing tools are swappable (superpowers writing-plans today; others later). The attack is the same whichever wrote the plan." Names writing-plans as the current default planner.	Point to the Spire plan guide as the default. Keep "the attack accepts a plan from any source", because foreign plans (grill-me, user-written) still arrive.
E3	skills/implementation/SKILL.md:84	Composition: superpowers is a toolbox (writing-plans, TDD, systematic-debugging, verification-before-completion, dispatching-parallel-agents). Lean rules win on conflict. SDD only when a plan asks for per-task review.	Replace with one line pointing to a legacy reference (references/superpowers-legacy.md: when and how to use superpowers with Opus 4.6-class models). The content the toolbox line stood for is already Spire-native: fail-first for bugs (:57-60), parallel only for disjoint work (:36), "tests pass is a claim" (athanor.md:34).
E4	skills/implementation/SKILL.md:85	"This skill does not govern code style, test frameworks, CI or plan formats." This is the explicit hole that superpowers fills.	Remove "plan formats" from the disclaimer and point to the plan guide.
E5	agents/athanor.md:58-60 ("Tools, not the loop")	Lists TDD, systematic-debugging, verification-before-completion and dispatching-parallel-agents as optional, says writing-plans belongs to the planner, and says lean rules win.	Delete the section, or replace it with one line: "Fail-first tests for bugs and diff-checking claimed fixes are in spire:implementation." Note the conflict: sp/test-driven-development/SKILL.md has an "Iron Law: NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST … Write code before the test? Delete it." Inviting it in for "a fail-first test inside a block" imports the full law. sp/verification-before-completion/SKILL.md:14 "NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE" pushes a test run per claim, which works against "gate cheap, tests once" (implementation/SKILL.md:39).
E6	skills/workpad/SKILL.md:3 (description)	Names a superpowers/ subdirectory as a trigger example, and ends "Can be used together with any superpowers."	Keep the steering (it is generic and still useful while foreign skills exist). Drop the last sentence. Optionally name the actual paths: docs/superpowers/specs/, docs/superpowers/plans/ (sp/brainstorming/SKILL.md:241, sp/writing-plans/SKILL.md:18).
E7	skills/workpad/SKILL.md:10	"If another skill suggests writing … to its own scratch directory (a superpowers/ folder …), prefer the workpad."	Harmless; keep it generic.
E8	skills/research-tree/SKILL.md:3 (description)	"…runs alongside superpowers and similar orchestration helpers."	Drop the clause.

1.2 Implicit coupling: where Spire leans on superpowers without naming it

#	Location	What is assumed	Replacing requires
I1	skills/igor/SKILL.md:95, stages (3) Design and (4) Plan	Says who writes ("independent Opus agent produces one buildable approach"; "independent Opus 5.5 agent … produces steps with completion criteria") but not what. A dispatched designer or planner with superpowers enabled matches brainstorming ("You MUST use this before any creative work", sp/brainstorming/SKILL.md:3) or writing-plans ("Use when you have a spec or requirements for a multi-step task", sp/writing-plans/SKILL.md:3).	Stage 3 and stage 4 name the Spire design and plan guides, and the briefs say "use spire:design / spire:plan".
I2	The plan format itself (via E2/E4)	If writing-plans writes the plan, it carries: the header "REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development … or executing-plans" (sp/writing-plans/SKILL.md:61); "Task Right-Sizing: the smallest unit … worth a fresh reviewer's gate" (:38-43), which bakes per-task review into the plan's structure; 2–5-minute steps with complete code and a TDD five-step cycle per task (:45-52, :110-140); "No Placeholders … repeat the code" (:143-151); and an Execution Handoff that asks the user to pick subagent-driven or native (:167-192). The attack step (implementation/SKILL.md:26) then has to undo all of this: regroup tasks into phases and blocks, strip per-task review, cut scope. That is the "11× larger plan" mechanism (§3).	A Spire plan guide that writes directly in phase/block shape (what the build plan needs, implementation/SKILL.md:30). The attack then stays adversarial and trims scope instead of reformatting.
I3	designs/2026-09-22-development-cycle.md:28 and :38; igor/SKILL.md:95	The plan vocabulary is "steps, files, completion criteria", which is the superpowers task/step vocabulary. The build plan speaks phases/blocks/owner/gate. Two vocabularies, with no defined translation except the attack.	One vocabulary: phase (ends testable) → block (one owner) → completion criterion. "Steps" stays inside a block, at the owner's discretion.
I4	skills/igor/SKILL.md:95 stage (1) Brainstorm ("Igor with user or Pinky")	Pinky does not exist (journals/2026-09-21-14-agent-rails.md:33; designs/2026-09-14-plugin-design-spec.md:26). With superpowers enabled, using-superpowers says "Before entering plan mode: … invoke the brainstorming skill first" (sp/using-superpowers/SKILL.md:22). Brainstorming's HARD-GATE (sp/brainstorming/SKILL.md:38-56) requires user approval of the spec and of the written plan and its execution method. That collides with Igor's flow (independent designer, attack, then the user sees the build plan once).	Spire's design guide defines the brainstorm-to-design handoff and the single user checkpoint. Pinky stays future work.
I5	Superpowers' SessionStart hook (sp/../hooks/hooks.json: matcher startup|clear|compact; hooks/session-start injects using-superpowers wrapped in <EXTREMELY_IMPORTANT>)	Whenever the plugin is enabled (user scope here: cache exists; repo .codex/config.toml:9-10 enables it for Codex), every main session, Igor included, gets "If you think there is even a 1% chance a skill might apply … you ABSOLUTELY MUST invoke the skill" (sp/using-superpowers/SKILL.md:11). Subagents are told to ignore it (<SUBAGENT-STOP>, :6-8), but skill descriptions still auto-trigger in subagents with the Skill tool (Athanor has tools: "*", athanor.md:14).	Spire cannot switch this off from its docs. "Dropping superpowers as default" therefore also needs: (a) a line in spire:project / /spire:init saying "disable superpowers@claude-plugins-official in projects that run Spire, or accept its hook"; (b) the repo's own .codex/config.toml:9-13 (enables superpowers and g4b_ai, not spire) updated if Codex should run Spire.
I6	skills/igor/SKILL.md:81 / igor/references/model-tiers.md:11 ("Planned implementation → implementer agent")	The superpowers SDD shape: one implementer per planned task. Spire has no implementer agent; the 0.2.1 goal already flags the row (goals/lean-athanor-0.2.1.md:23).	The row should read: attacked plan → Athanor (multi-block) or one general-purpose builder (one block).
I7	skills/implementation/SKILL.md:51-55 / run-log.md	These are Spire-native replacements for SDD's ledger (sp/subagent-driven-development/SKILL.md:134-152, progress.md as "recovery map") and for its per-task review → 5-round fix loop (:75, :311 "Never skip the task review"). No coupling, but worth knowing the replacement exists so nothing gets re-imported.	None.

1.3 Historical mentions (no action)

• docs/workpad/plans/2026-09-17-spire-project-override-init.md:85-87 and research/2026-09-29-17-orbit/phase-1-review-fit.md:103-108 record the old Athanor preload (using-superpowers, subagent-driven-development, dispatching-parallel-agents).
• reports/2026-05-11-17-orchestrator-comparison.md:31: composition note.
• brainstorm/2026-11-15-implementation_thoughts.md:3 (untracked, written today; the date prefix is probably meant to be 10-15): "use even other skills: grill-with-docs, superpowers, etc." for the design phase. This is the user's own sketch of the cycle and is input for §5.

1.4 plugins/g4b_ai/ (legacy, brief)

• skills/implementation-orchestration/SKILL.md:73: "superpowers and project-specific skills … layer on top of this." This is the ancestor of Spire's implementation skill. Its body still carries the pre-lean rules Spire removed: "Run tests between agents", "verify the fix yourself", "Plan first … confirm with the user".
• skills/workpad/SKILL.md:3,10 and skills/research-tree/SKILL.md:3: same text as E6–E8.
• Action: none needed if g4b_ai is frozen. It is still the plugin the repo's .codex/config.toml:12 enables for Codex.

1.5 This repo's own plans are not superpowers-format

The four files in docs/workpad/plans/ use free Spire-ish shapes: phases plus "what blocks what" (2026-09-14-spire-mvp.md), commit/task groups (2026-09-17-spire-project-override-init.md:8-150), and decisions, phases, commit strategy, fact-check and risks (2026-09-18-adept-discovery-plan.md:8-217). None has the writing-plans header, checkboxes or TDD steps. The format coupling bites in dirigent and spacecraft, where writing-plans and SDD were in use (§3). Those repos were not inspected directly.

---

2. What Spire already specifies, and the gaps

2.1 Design

Specified

• Design vs brainstorm: "A design is convergent: one approach, fleshed out enough to build from" (workpad/SKILL.md:103). The lifecycle runs brainstorm → goal → design → plan (:109). A new file per stage; don't mutate the previous one (:113).
• Who writes it: an independent Opus agent, never the planner or the Athanor (designs/2026-09-22-development-cycle.md:27, :80; igor/SKILL.md:95, :97).
• How to handle unknowns: "Igor resolves open questions by picking the most likely answer and flagging it inline (**Assumed:** ...). A question becomes a blocker only when a wrong pick would waste the implementation" (development-cycle.md:36).
• How it changes: "approach is wrong → back to design; append a dated amendment, do not rewrite" (development-cycle.md:48, :65; igor/SKILL.md:102).
• The goal anchors it and does not change during a cycle (development-cycle.md:19).

Gaps: Spire defines no content for a design. Today these come from superpowers brainstorming or from the model's defaults:

• Sections. Superpowers: "Cover: architecture, components, data flow, error handling, testing" (sp/brainstorming/SKILL.md:221), units with clear interfaces (:224-229), "Propose 2-3 approaches" (:211), YAGNI (:214).
• A self-check (placeholders, consistency, scope, ambiguity; sp/brainstorming/SKILL.md:249-252).
• Size and altitude: how much code belongs in a design. The user's brainstorm says "only high level code examples, like structures or relationships" (brainstorm/2026-11-15-implementation_thoughts.md:18).
• The architectural orientation layer the user sketches as a separate step 2 (…implementation_thoughts.md:5-18): modules, files, types/traits, pre-plan vs post-plan structure ("database models, module skeletons, interface shapes" are good pre-plan jobs; trait polishing and abstraction refactors often come later), and a test design ("minimal tests required, breaking points"). Spire has nothing for this.
• Consumers of changed semantics. Spire only asks the attack to find them (implementation/SKILL.md:26). The redesign report wanted the plan to list them (reports/2026-10-05-21-implementation-skill-redesign.md:54, :117).
• Scope fence and non-goals. Scope creep is the user's top complaint (journals/2026-10-15-11-superpowers-opus55-era.md:12) and the spacecraft multiplier (§3). No design-level rule exists.
• When to skip the design. There is a rule for the cycle ("if writing the plan would take longer than doing the work", igor/SKILL.md:93), but none for the design stage. In practice it was skipped when "the goal is the spec" (journals/2026-10-05-21-athanor.md:23) or for prototypes (journals/2026-09-29-17-orbit.md:40).

2.2 Plan

Specified

• Plan vs goal vs spec (workpad/SKILL.md:97-99).
• Plan contents, minimally: "steps, files, completion criteria; may be several" (development-cycle.md:28). "A plan must run in the Athanor without conversation" (:38). "steps with completion criteria" (igor/SKILL.md:95).
• "The plan is the main lever. Most defects trace back to the plan" (implementation/SKILL.md:10).
• The attack (implementation/SKILL.md:26-32) tests for blockers, design errors, wrong root causes and missed consumers, then reshapes. Phases end testable, blocks have one owner, scope is cut back, user decisions are listed. The attack writes a new build-plan file.
• The build plan sets block size, owner model per block, gate per block, what may stay broken, optional extra reviews with a reason, and a risk list that is not the reviewer's scope (implementation/SKILL.md:30). The redesign report adds a fuller field list (reports/2026-10-05-21-implementation-skill-redesign.md:55).
• Closed door: "Decisions belong before the run" (implementation/SKILL.md:40).
• Model notes: 5.5 plans are thorough and long, about 11×, and drove scope; "The attack step trims scope" (implementation/references/models.md:17).

Gaps

• No plan document shape. No header (goal and design links, branch, gate/test commands), no phase/block skeleton, no completion-criteria form, and "plan formats" is explicitly disclaimed (implementation/SKILL.md:85). This is the slot writing-plans fills (I2).
• Granularity and altitude. How much code goes in a plan. Spacecraft's lesson was "plan coarser (contracts/invariants per phase, not signatures per task)" plus a size budget (research/2026-10-05-21-athanor-usage-spacecraft.md:45). That lesson was deliberately not encoded as numbers (redesign report:141), so nothing counteracts writing-plans' "complete code in every step".
• What the planner must verify in code before writing (root cause traced, consumers enumerated). This is left entirely to the attack.
• A test strategy per phase: which tests prove the phase, and where fail-first applies.
• Non-goals and scope fence at plan level.
• A planner self-check. Superpowers has one (sp/writing-plans/SKILL.md:153-165); Spire has none, and relies on the attack.
• Plan → build plan duplication. The attack rewrites everything into a new file even when the plan already has the right shape. If the planner writes in build-plan shape, the attack could amend in place as a dated section (the workpad rule allows amendments for designs, development-cycle.md:65), or write a short delta.

2.3 Handoffs, run logs, journals

Specified (well covered)

• Igor session journal: template (igor/references/journal-template.md:3-34) with Log (append-only, "record the tangents and dead ends"), Adepts, Artifacts, Open threads and Graduation candidates. Rules: keep it current, append-only (igor/SKILL.md:170), fill it during the "no is a lull" moment (:171), wrap-up with adept handoffs, accretion and graduation candidates (:183), and a self-review (:184). Philosophy: igor/references/mindset.md:5-15.
• Run log (implementation/references/run-log.md): header, per-phase table, a handoff note per block (model, start/end from date, done, deviations, flagged for review, left for later, expected broken, commits; :32-45), phase close (:47-57), post-review append (:59), and trunk notes (:61-63). Rules: times from date, durations from git, stamp the model id, totals provisional (:5-10). Echoed in implementation/SKILL.md:68-75.
• Adept handoff: handoff.md is rolling, ≤40 lines and written early, with frontmatter updated/session/branch/verified-at and a drift check by git log <verified-at>..HEAD -- <covers> (agents/adept.md:59-70; template docs/workpad/adepts/_template/handoff.md). Knowledge tiers: solid docs vs journal vs handoff vs index (adept.md:85-94). Journal conventions and dead ends (:104-110). End of life (:133-137). Init scaffolds all of this (init/SKILL.md:168-268).
• Report vs journal distinction (workpad/SKILL.md:101).

Gaps

• No general (non-Igor, non-adept) handoff. A plain session, or the Athanor's dispatcher, has no "where things stand / next step / how to resume" document. The Igor journal's Open threads and the run log cover it only under Igor or the Athanor.
• Times-from-date is a run-log rule but not a journal rule. The journal template uses HH:MM with no source. Dirigent's journal clock drifted about 2.5× and produced a false "5× faster" claim (research/2026-10-05-21-athanor-usage-dirigent.md:86-87). Today's journal starts at "11:05" for every entry (journals/2026-10-15-11-superpowers-opus55-era.md:11-15).
• Crash/resume semantics. SDD's ledger is explicitly a "recovery map" (sp/subagent-driven-development/SKILL.md:150-152). Spire's run log can serve the same purpose, but nothing says "write the handoff note when the block commits, not at phase end". The dirigent rate-limit kill left reviewed-but-uncommitted work and unclosed ledgers (research/…-dirigent.md:152-170).
• Harness-specific persistence is undefined. Claude Code: agent memory: project is enabled on igor/adept/zathras (agents/igor.md:10, agents/adept.md:12, agents/zathras.md:10), but what goes into memory vs journal vs handoff is never stated. Nothing covers compaction (superpowers re-injects on compact; Spire's adept rule "if compressed, you have lived too long", adept.md:137, is the only compaction guidance), the CLAUDE.md auto-load cost (only for adept indexes, adept.md:98), or plan-mode plan files. Codex: nothing (AGENTS.md as the entry point is mentioned only in knowledge/SKILL.md:18-36).
• Journal mining format: named as future work (implementation/SKILL.md:73; goals/lean-athanor-0.2.1.md:26); nothing makes journals mineable (e.g. tagged entries).
• Journal template location: it lives in igor/references/, so the Athanor, adepts and plain sessions each reinvent the format.

2.4 Net: what Spire leans on superpowers for today

1. The plan document format and granularity (I2): the largest and costliest dependency.
2. Design contents and approach exploration (brainstorming): the second largest. Spire has the process (convergent, **Assumed:**, amendments) but no content.
3. Smaller items, already distilled natively: TDD → implementation/SKILL.md:59; debugging → :60; verification → athanor.md:34 plus the phase reviewer; parallel dispatch → :36 plus research-tree; SDD → the lean loop; the ledger → the run log.
4. Nothing in handoffs or journals depends on superpowers. Superpowers has no journal concept; its only persistence is the SDD ledger.

---

3. Evidence on the cost problem

3.1 Overhead (quotes)

• Per-task review loop as the default. "The current skill and athanor load superpowers' subagent-driven development, which requires a review after every task ('Never skip the task review', up to 5 fix rounds). With Opus 5.5 this ceremony costs more than it catches." (reports/2026-10-05-21-implementation-skill-redesign.md:12; cf. sp/subagent-driven-development/SKILL.md:75, :311)
• Verification seats outnumber build seats. "Spacecraft: 1.8 verification seats per build seat. 11 of 13 re-reviews only confirmed the fix." (redesign report:22). "Re-reviews and deferred minors did not pay off: 11/13 re-reviews only confirmed fixes; of 16 deferred minors none were ultimately must-fix" (research/2026-10-05-21-athanor-usage-spacecraft.md:33).
• Fixer cost is at or above draft cost. "active time per task rose from ~10 min (plans A/B) to ~40 min (D2/E1) to ~70 min (E2), driven by 'a mandatory fresh Opus 5.5 fixer on every task' whose fixer seat 'often cost more than the draft'" (…-spacecraft.md:42). This matches the user's "review+fix ≈ 2/3 of work" (journals/2026-10-15-11-superpowers-opus55-era.md:12).
• Scope. "Opus 5.5 plans were ~11× larger than any earlier plan, driving 77k lines of Rust instead of a plausible 10–20k for a '4.6 just build it' MVP" (…-spacecraft.md:42; models.md:17). Combined with writing-plans' "complete code in every step" (I2), plan size becomes code size.
• Fix churn. Dirigent lean vs baseline: "3h11m vs ~5–5.7h … +1,417 fix lines in 1 commit vs +3,439 in 10 commits" (…-dirigent.md:84-86).
• Token/context. "One implementer carried across tasks reached about 960k tokens and drifted" (models.md:47); "Sonnet implementers reached 500k–750k" (redesign report:28); lean blocks of 11–36 min used 186k–344k (models.md:48).
• Gates that block. "one blocking AskUserQuestion waited 5.9h overnight" (…-spacecraft.md:42); dirigent memory: "Why do I yet again need to check so much stuff manually?" (redesign report:25).
• Scope creep at dispatch, outside superpowers. Orbit phase 2 ran about 96 min after the user flagged "a forever task": "scope has to be sized at dispatch, not trimmed mid-run" (journals/2026-09-29-17-orbit.md:33-34, :83).
• Even the lean loop on a small markdown change spent about 28 of 40 min on review + fix + re-check: implement 22:00→22:12, review →22:20, fix →22:35, re-check →22:40 (journals/2026-10-05-21-athanor.md:23-29; Igor-written times, not from date). The review found 3 Important issues, so it earned its cost. Still, review depth "by phase risk" (redesign report:59) has no concrete trigger in the skill.

3.2 Attribution caveat (important for the decision)

• "Superpowers supplies only the skeleton (per-task review loop, ledger, 5-round fix cap, ruling format). 'Most of the weight is ours': Opus 5.5 on every review/re-review/fix round, a fresh fixer every fix round, mutation checks …, minors carried forward, a final review per slice …, three prose records per slice, oracle/golden ceremony, and a third coordination layer" (…-spacecraft.md:31).
• On 2026-10-05 the user's position was "superpowers not abandoned — rules changed" (journals/2026-10-05-21-athanor.md:21). On 2026-10-15 the decision moved to "drops superpowers as a default" (journals/2026-10-15-11-superpowers-opus55-era.md:14). The evidence supports dropping the per-task loop and the plan format. It does not show that TDD or debugging discipline themselves cost much.

3.3 What worked

• Attack the plan: "plan comparison (adversarial, against the code, ~6 min) → amendment (… cut into 6 blocks, ~4 min)", "cheapest quality gate of the day" (journals/2026-10-05-21-athanor.md:20, :60).
• First reviews do pay: "12/15 found Important or Critical issues"; mutation checks were "the most productive single check in the pipeline" (…-spacecraft.md:32).
• An independent 5.5 phase review: 6 Important in about 20 min where the in-furnace review passed; one fix pass cleared them in 33 min (models.md:18; …-dirigent.md:89-99).
• Lean halves time: "halved the time per task (about 75 min → about 40 min) and kept review quality" (…-spacecraft.md:50); lean was 35–40% faster (dirigent).
• Foreground dispatch: "B4 ran with zero stalls once foreground dispatch was enforced" (…-spacecraft.md:52).
• Tight, timeboxed briefs: the orbit prototype was built in about 8.5 min with no design or plan stage (journals/2026-09-29-17-orbit.md:40-41, :85).
• Real failure modes to keep guarding (they replace the generic verification ceremony): weakened checks (3×), tests that cannot fail, design text lagging code, and performance drift (…-spacecraft.md:52).
• The plan mattered as much as the model: "About 4 of the 6 were plan gaps that any implementer following the plan would have carried out" (models.md:37).

---

4. Harness-specific helpers

4.1 Claude Code: what Spire exploits or documents

Feature	Spire status	Where
Agent dispatch, background by default, run_in_background: false	documented, verified from the schema	spawning-claude-code.md:16, :28
Background grandchildren notify the root; parent stalls	documented, observed	:29-32; igor/references/harness-notes.md
SendMessage resume (root only)	documented and used (Athanor between phases, adepts)	spawning:17, :40-41; igor/SKILL.md:108, :163
ListAgents, TaskStop, TaskOutput (not for agents)	documented	spawning:22, :32-33; igor/SKILL.md:108, :176
Per-call model alias overrides frontmatter pin; full-id pins	documented, verified	spawning:18-19, :47-54; igor/SKILL.md:89
fork	documented; availability unverified ("not in the list of agent types offered"). Re-observed 2026-10-15: my Agent schema mentions fork, but it is not among the offered types (claude, Explore, general-purpose, Plan, …).	spawning:58-64; preflight pending (goals/lean-athanor-0.2.1.md:12)
Agent frontmatter skills: preload, tools, memory: project, effort	used (effort: medium on researcher only)	agents/*.md frontmatter
Skill ! shell injection at load	used (roster, project config)	adepts/SKILL.md:12; project/SKILL.md
Workflow scripts (agentType)	mentioned for research only	research/SKILL.md:34-41
Todos (TaskCreate/TaskList)	only "TaskList is the todo list, unrelated to agents"	spawning:33
Worktrees	policy only ("prefer main"; project setting)	igor/SKILL.md:175, :181; implementation/SKILL.md:79
Not used or documented	Agent isolation: "worktree" (and "remote"); EnterWorktree/ExitWorktree; plan mode (EnterPlanMode/ExitPlanMode); Monitor (spacecraft's rule was "no file watchers/Monitor tasks", …-spacecraft.md:51); hooks (Spire ships none); the per-call effort parameter; built-in /code-review, /security-review, /simplify and skill-creator (present in this session's skill list, 2026-10-15)	—

4.2 Codex

• Spire ships .codex-plugin/plugin.json with "skills": "./skills/" and claims "capabilities": ["Skills", "Agents"], but there are no agent definitions for Codex. Igor, the Athanor, adepts, researcher, scout and search are Claude Code agents only.
• spawning-claude-code.md:3: "Other harnesses get their own spawning-<harness>.md when needed." None exists.
• The 0.2.1 goal expects "Codex's report on how it performs" (goals/lean-athanor-0.2.1.md:4, :9). No such report is in the workpad yet.
• The repo's own .codex/config.toml:9-16 enables superpowers, g4b_ai and gitea, not spire.
• Superpowers already maintains a Codex note that is a good starting source, to be verified independently before Spire adopts any of it: sp/using-superpowers/references/codex-tools.md. It covers the [features] multi_agent = true switch; spawn_agent with fork_turns: "none" vs the default "all" (full-transcript fork, which is relevant to trunk and forks); followup_task to resume children (V2); no close_agent on V2; model allowlists; and wait_agent as an event subscription ("two-thirds of all wait calls were short polls"). Spire would need the Codex equivalents of its Claude Code claims: notification routing, resume, fork model and context, pins.

4.3 Superpowers helpers effectively superseded

Superpowers skill	Superseded by	Residual Spire must keep
subagent-driven-development (per-task implement → review → ≤5 fix rounds → ledger → final review)	Athanor plus the lean loop (implementation/SKILL.md:14-55); run log as ledger	none
executing-plans (inline)	the plain session or one builder; todos for tracking	none
dispatching-parallel-agents	Agent background default; research-tree; "sequence by default" (implementation/SKILL.md:36)	none
using-git-worktrees	Agent isolation: "worktree", EnterWorktree, plus the spire:project worktree setting	document the isolation parameter in spawning-claude-code.md (unverified in Spire)
requesting-code-review / receiving-code-review	Spire phase review (fresh, stamped, answers flags, hunts weakened checks); built-in /code-review (effort levels) as a tool	reviewer brief template (Spire has the rules but no template)
finishing-a-development-branch	project conventions (push, never PR) and the commit-conventions spec	none
verification-before-completion	Opus 5.5 behaviour; "tests pass is a claim — read the diff" (athanor.md:34); phase reviewer	none
test-driven-development	fail-first for bugs (implementation/SKILL.md:59); test strategy in design and plan	a one-line test strategy field in the plan
systematic-debugging	"explore before you focus" (implementation/SKILL.md:60); journal hard bugs (:74)	none
writing-skills	skill-creator (built-in, and .claude/skill-creator/ in the repo)	none
brainstorming	Igor conversation, plus Pinky (not built); plan mode for read-only exploration	design contents: not superseded, Spire must supply them
writing-plans	nothing in the harness (plan-mode plans are free-form)	plan format: not superseded, Spire must supply it
using-superpowers + SessionStart hook	— (this is the ceremony source)	an instruction to disable it in Spire projects (I5)

---

5. Minimum distillation (proposed outlines)

Placement recommendation. Make two small new skills, so they trigger on "write a design" / "write a plan" in place of brainstorming and writing-plans, and Igor's briefs can name them: spire:design and spire:plan. Make one new cross-cutting skill for records: spire:handoff. Each skill gets a short SKILL.md (≤80 lines) plus one template in references/. Harness-specific material goes in references, never in SKILL bodies. Add implementation/references/superpowers-legacy.md (the Opus 4.6 doc the user allowed) and implementation/references/spawning-codex.md. Alternative with fewer skills: one spire:blueprint skill with references/design.md, references/plan.md, and handoff in implementation/references/. Cheaper on skill count, but weaker triggering against superpowers' descriptions.

5.1 spire:design → plugins/spire/skills/design/SKILL.md + references/design-template.md

• When a design earns its place. Skip it when the goal is precise enough to plan from, or for prototypes (cite the cycle line).
• Inputs. A goal (read-only), research, a brainstorm. State which ones were used.
• Convergent. One approach. Rejected alternatives get a line each, with the reason.
• Problem and success. Restate the goal's acceptance criteria. No new goals.
• Scope fence. Explicit non-goals, plus "what we will not build now".
• Shape of the solution. Components and responsibilities, data and state shapes, interfaces between units. Code only as signatures, structs and relationships.
• Architectural orientation (from the user's step 2). Modules and files touched, where new code lives, pre-plan scaffolding (models, module skeletons, interface shapes) vs post-plan refactors (trait polish, abstractions that emerge).
• Invariants and consumers. Each changed semantic and every reader of it (callers, stats, migrations, other crates).
• Failure and edges. Error handling, security, lifecycle pairs (onboarding needs offboarding), "a button that does nothing".
• Test design. The minimal proving tests, breaking points, where fail-first applies.
• Risks and hotspots. These feed owner-model choice later.
• Assumptions. **Assumed:** inline. Blockers are only those a wrong pick would waste. Open user decisions are listed.
• Size budget. Pages, not chapters. If it grows, split into sub-designs.
• Amendments. Dated sections, never a rewrite.
• Self-check before handing over. Contradictions, ambiguity, scope vs goal. One pass, no loop.
• Stamp. Model id and date.

5.2 spire:plan → plugins/spire/skills/plan/SKILL.md + references/plan-template.md

• Purpose. A plan runs without conversation. It is the main quality lever; write it so the attack can test it against code.
• Header. Goal, design and research links; branch; gate and test commands (from spire:project); model id.
• Verify before writing. Trace root causes and consumers in the code. Cite file:line, not guesses.
• Shape: phases → blocks. Each phase ends testable. Each block has one owner and one coherent change, with an owner-model suggestion, its gate, and what may stay broken. This is the build-plan shape from the start, so the attack trims rather than reformats.
• Per block. Intent, files and areas, interfaces it produces or consumes, completion criteria. Steps are optional and left to the owner.
• Altitude. Contracts and invariants, not full code. Code only where the exact form is the decision (formats, schemas, signatures).
• Tests per phase. What proves it, which bug gets a fail-first test, and the one suite run at phase end.
• Consumers and migration. Every reader of changed semantics, and backward-compat notes.
• Decisions. Made in the plan; the remaining user decisions are listed up front (closed door).
• Scope fence. What is out, referencing the design's non-goals. No "while we're here".
• Risks and review placement. Hotspots, and whether any earns an extra review (with the reason). This is not the reviewer's scope.
• Size budget. As a judgment, not a number. Flag when the plan outgrows the goal.
• Hand-off to the attack. The attacker amends (a dated section or a short build-plan delta). The original stays.
• Foreign plans (user, grill-me, superpowers). Accepted; the attack reshapes them into this shape.

5.3 spire:handoff → plugins/spire/skills/handoff/SKILL.md + references/journal-template.md (moved from igor/) + references/claude-code.md + references/codex.md

• Kinds of record. Session journal (append-only path), handoff (rolling state, overwritten), run log (build record, per block), report (snapshot). One line each on when to use which; link to the workpad.
• Write early, refresh on state change. Sessions end abruptly, so a handoff written "at the end" never gets written. Handoff notes are written at block commit.
• Times and durations. Times from date, durations from git, model id stamped. Applies to journals too, not only run logs.
• Journal entries. What was dispatched or decided, what came back, dead ends ("tried X, not the cause because Y"), course corrections. Link artifacts.
• Handoff contents (≤40 lines). State, in flight (branch-only, not solid), open threads, read-first list, drift check (verified-at + git log).
• Resume protocol. A successor reads the handoff, the run log's last phase close, then git log since the stamp. It trusts git over prose.
• Wrap-up. Close open threads, list graduation candidates, accrete corrections (dated). Pointer to Igor and adepts for their specifics.
• Mineability. Consistent entry prefixes or tags so journals can be mined later (future work hook).
• references/claude-code.md. Agent memory: project vs journal vs handoff (what goes where). Compaction: refresh the handoff before it happens; a compressed agent should hand off. CLAUDE.md auto-load cost. Plan-mode plan files are scratch and get copied into the workpad. Todos are not a record. Notification ≠ completion (link to spawning).
• references/codex.md. AGENTS.md as the entry point. No Spire agents in Codex, so the roles run as briefs. Thread and child lifecycle (followup_task, wait_agent) and what survives eviction. All to be verified, sourced first from sp/using-superpowers/references/codex-tools.md.

5.4 Supporting edits (not new guides)

• implementation/references/superpowers-legacy.md: when superpowers still helps (Opus 4.6-class or weaker drafters, unfamiliar codebases, mutation-heavy hotspots), which skills to use, the known costs (§3), and how to switch off its hook (I5).
• implementation/references/spawning-codex.md: the Codex counterpart to the Claude Code claims table.
• spawning-claude-code.md: add isolation: "worktree", plan mode, Monitor, effort and built-in /code-review, each with a status and a date.
• Edits E1–E8 and I1, I3, I5, I6 as listed in §1.