# Goal: Lean implementation — `implementation` skill and Athanor for Opus 5.5

**Set**: 2026-10-05, Igor session [2026-10-05-21-athanor](../journals/2026-10-05-21-athanor.md)
**Evidence**: [dirigent survey](../research/2026-10-05-21-athanor-usage-dirigent.md), [spacecraft survey](../research/2026-10-05-21-athanor-usage-spacecraft.md), [redesign report](../reports/2026-10-05-21-implementation-skill-redesign.md) (input, not law — corrected by this goal where they differ). Primary source: dirigent `docs/workpad/reports/2026-10-01-lean-process-report.md` + 2026-10-05 addendum.

## Why

With Opus 5.5, the per-task ceremony we inherited (many pitstops, review after every task, tests between every agent) costs more than it catches and produces too much output. 5.5 plans are excellent but long; most defects trace back to the plan, not to the drafting model. What worked in dirigent and spacecraft: test the plan against the code before building, build in large chunks, review once per phase.

## Success criteria

### The skill is lean
- [ ] `implementation/SKILL.md` states intent and defaults with their reasons, and leaves decision room for the problem at hand. It does not encode single incidents as rules.
- [ ] It stays short: no longer than today's skill by more than a modest margin; detail lives in references.
- [ ] Mechanics of the harness (Claude Code) and traits of models live in reference files, not in the skill body. Project-specific choices (worktrees, staging explicit paths, gate/test commands, owner-model defaults) are read from `spire:project`, not fixed in the skill.

### Attacking the plan is the quality gate before the build
- [ ] The cycle has an explicit step after planning: a fresh agent (not the planner) **tests the plan adversarially against the code** (blockers, design errors, missed consumers of changed semantics) and **then reshapes it** into phases that end testable and blocks one owner can finish. One step, not two.
- [ ] The skill makes clear that this step is what pays for dropping per-task review — it moves quality control upstream.
- [ ] It is described by intent, not as a checklist of required output fields.
- [ ] The attack's risk list is not handed to the phase reviewer as its scope.
- [ ] The step happens outside the Athanor (Igor dispatches it), so the user sees the reshaped plan and pending decisions before the door closes.

### Lean build loop
- [ ] Between blocks: a cheap gate (compile/typecheck), not a review. At phase end: tests once, one adversarial phase review, one fix pass, re-check only for Critical/Important, then stop. Minors are fixed in the pass or logged.
- [ ] Phase review is dispatched by Igor, by a fresh reviewer, with its model id stamped. It answers every handoff flag and looks specifically for weakened checks and tests that cannot fail.
- [ ] Extra reviews (e.g. a mid-phase hotspot review) remain possible as a reasoned choice, not a default.

### Athanor is a build furnace
- [ ] One phase per Athanor turn: intake (read build plan + touched code = the trunk; write short trunk notes) → build blocks in the foreground → gate between blocks → tests once → run log with per-block handoff notes → hand back.
- [ ] Igor resumes the Athanor (safe from the root) for the fix pass and the next phase, or starts a fresh one from run log + trunk notes when its context looks spent.
- [ ] The plan sets defaults for block size and owner model; the Athanor may deviate with a logged reason.
- [ ] The Athanor does not plan, attack plans, or review its own output.
- [ ] Trunk and forks is described as an option, with verified vs. assumed harness behaviour marked: complex blocks in the trunk's area → fork of the Athanor; mechanical or distant blocks → fresh agent with trunk notes. Forks inherit the Athanor's model.

### Models
- [ ] Opus 5.5 (`claude-opus-5-5`) is the default for the Athanor, planning, attack, and review. The Athanor's frontmatter pins it.
- [ ] Igor's model rule accounts for alias-over-pin: passing `model: "opus"` gives the Athanor whatever Igor runs on (a 4.6 Igor → 4.6 Athanor; the dirigent "Pass" review was such a case). Igor omits `model` for pinned agents unless it deliberately overrides, and stamps the choice.
- [ ] Model notes are observations with date and source, not law: 5.5 catches more, decides boldly, can replace frequent small reviews (esp. Rust), but can take the user's word as holy or reverse 100%; 4.6 is fast, capable, sometimes better at interpreting intent (useful as a "understanding the human" interpreter; Fable is better still); Sonnet and Haiku observations kept neutral — the Sonnet experiment's defects were largely plan issues.
- [ ] Stale guidance removed: "prefer Opus 4.6 for implementation", "Opus 5 tends to hallucinate", "review between tasks".

### Context sizes are guesstimates
- [ ] Any context figures (e.g. 5.5 comfortable to ~600k) are labelled as guesstimates from Claude Code experience. The skill gives judgment guidance between the two failed extremes (many tiny fresh implementers; one implementer kept too long), not a rule for either.
- [ ] Noted as future work: orchestrator introspection of subagent token use / signals into running work (dirigent is working on this).

### Superpowers is a toolbox, not the default loop
- [ ] The Athanor no longer preloads `superpowers:subagent-driven-development` (its per-task review loop). Other superpowers skills remain available as tools; the skill states that lean rules take precedence where they conflict.
- [ ] Plan-writing skills are swappable (e.g. superpowers writing-plans today, grill-me or our own playbook later).

### Journals stay central
- [ ] Session journals and the run log remain the record of a run. Journals are named as the raw material for later mining (future work, not this change).

## Out of scope

- Building token introspection or signalling between sessions.
- Running the trunk-and-forks trial itself (separate follow-up; preflight + trial venue TBD).
- Changing the superpowers plugin.