🤖 Wire development cycle into Spire skills and agents

Igor now has a Development Cycle section with six stages, review decision
tree, Athanor queuing rules, and separation principle. Athanor, implementation,
research, and research-tree skills all reference their cycle stage. Fixed
remaining Athanor metaphor inversions in the plugin design spec.

plugins/spire/agents/athanor.md

@@ -34,6 +34,9 @@ Project-specific knowledge is loaded by the `spire:project` skill at agent start
 - **Verify before claiming.** Implementation tasks are not done until the project's check/test commands have been run for the affected areas — delegate the run to a Haiku subagent if convenient — and the result is stated with evidence.
 - **Prefer working on main.** Markdown-only work (workpad files, docs, reports) happens directly on `main` — no worktree. Use a worktree branch only when the brief is a code implementation run that needs isolation (especially if another impl run is in flight) or the brief asks for one.
 - **Stay in your lane.** Work only within the brief's scope and the branch/worktree you were given or chose per the rule above. Never open pull requests; push code branches if instructed, never force-push.
+- **Igor holds the queue.** You process one plan at a time. If another plan is waiting, Igor dispatches it after you report back.
+- **Commit per plan step** on your branch. Each step's result is committed before the next begins.
+- **Output goes to a fresh reviewer.** Your deliverable (diff + plan reference) is reviewed by an independent agent in Stage 6 — never by you. Do not self-review.
 
 ## Deliverable
 

plugins/spire/skills/igor/SKILL.md

@@ -88,6 +88,27 @@ The `athanor` is the forge — your heavy lifter. An Opus-tier agent that may us
 
 **Model must be explicit.** Always pass `model` on `Agent` calls (`"opus"`, `"sonnet"`, `"haiku"`) — omitting it inherits the coordinator's model, which may be Fable. Subagents are Opus or lower; never dispatch a Fable-tier subagent unless the user explicitly asks.
 
+## Development Cycle
+
+Igor routes work through six stages. Not every task enters the cycle — one-off fixes, ad-hoc questions, and maintenance stay outside it. The line: if writing the plan would take longer than doing the work, it is not in the cycle.
+
+**Stages:** (1) Brainstorm — Igor with user or Pinky; skip when direction is clear. (2) Research — researcher/adept answers open questions. (3) Design — independent Opus agent produces one buildable approach. (4) Plan — independent Opus agent (never the designer) produces steps with completion criteria. (5) Implement — the Athanor receives the plan; code comes out. (6) Review — fresh Opus reviewer measures output against plan and design.
+
+**Separation rule:** Plans and designs are always written by independent agents. The author of a plan never implements it; the author of a design never plans from it. Separation keeps review honest.
+
+**Review decision tree:** Igor routes the outcome:
+1. None or low findings only — done. Lows stay in the report; never loop for lows.
+2. Any medium or high — collect findings into a new plan (stage 4). The normal short loop.
+3. Approach is wrong, not the code — back to design (stage 3). Append a dated amendment.
+4. Unresearched unknown surfaced — back to research (stage 2). Only for a genuinely new problem space.
+5. Goal is wrong — stop. User's call.
+
+Default to the shortest loop that fits; long loops need a stated reason.
+
+**Athanor queuing:** Plans enter sequentially; Igor holds the queue. A new plan arriving mid-run waits — the door is closed. If a new plan invalidates the one cooking, Igor stops the run (`TaskStop`), shelves partial output, and dispatches the replacement. Parallel Athanors only for disjoint code in separate worktrees; default is one.
+
+**Cycle and workpad:** Each stage writes to its folder; moving forward creates a new file, never mutates the previous one. The folder trail is the record.
+
 ## Adepts
 
 Adepts are domain-scoped knowledge agents that persist within a session. They accumulate knowledge in the workpad's `adepts/<domain-slug>/` folders — an index (`CLAUDE.md`), a rolling handoff (`handoff.md`), knowledge docs, and a `journal/` subfolder.

plugins/spire/skills/implementation/SKILL.md

@@ -7,6 +7,8 @@ description: Orchestrate non-trivial implementation work across one or more agen
 
 This skill is about **how to drive implementation work**, not about how to write code. It covers: when to delegate to subagents vs. work inline, how to sequence agents, how to handle test/compile failures, and how to approach bugs without thrashing.
 
+**Cycle context:** This skill governs what happens inside Stage 5 (Implement) of the development cycle. The Athanor receives a plan, not a conversation — no mid-run questions. Its output (diff + plan reference) goes to a fresh reviewer for Stage 6 (Review).
+
 ## Default to sequence, not parallel
 
 Implementation work is almost always **sequential** by nature — later changes depend on earlier ones, even when they look independent on paper. Two agents editing the same file in parallel is a merge conflict; two agents touching adjacent abstractions in parallel is a subtle integration bug.

plugins/spire/skills/research-tree/SKILL.md

@@ -5,6 +5,8 @@ description: Orchestrate multi-topic research as a dependency tree of parallel p
 
 # Research Tree
 
+**Cycle context:** Research-tree is the structured form of Stage 2; its output feeds Stage 3 (design).
+
 Most non-trivial research questions decompose into many sub-topics, and those sub-topics are *not* independent — later questions get sharper once earlier ones are answered. Running every sub-topic in parallel as peer agents wastes work and produces shallow, redundant findings. Running them strictly in series wastes wall-clock time. The right shape is a **tree of phases**: within a phase, agents run in parallel; between phases, later agents inherit the earlier reports.
 
 This skill describes how to plan and run that tree. It does not describe how to write the contents of an individual research report — that's up to the agent doing the writing, plus whatever conventions the project has.

plugins/spire/skills/research/SKILL.md

@@ -7,6 +7,8 @@ description: Governs how research is conducted — bounded agent spawning, no re
 
 This skill regulates **how** research agents behave. It does not replace research-tree (which governs the **structure** of multi-topic research) or workpad (which governs **where** output goes). It layers on top of both.
 
+**Cycle context:** Research may be invoked as Stage 2 of the development cycle, or as a loop-back from review (Stage 6) when an unresearched unknown surfaces. Its output feeds into design (Stage 3).
+
 ## The core problem this solves
 
 Without governance, a research agent can spawn sub-agents, which spawn more sub-agents, which each scrape entire websites. A simple "research X" request balloons into 10–20 agents crawling dozens of pages. That is not research — it is runaway resource consumption that produces shallow, redundant findings.