🤖 Align Igor with the lean build cycle

Adds the attack-the-plan step and per-phase review to the development
cycle, the fix-pass stop rule, Athanor resume between phases, and the
alias-over-pin model rule. Drops the stale 4.6-for-implementation
guidance and per-task review convention. Harness notes now point to the
implementation skill's spawning reference.

plugins/spire/skills/igor/references/harness-notes.md

@@ -1,15 +1,12 @@
-# Task Notification Mechanics
+# Harness notes (moved)
 
-A `<task-notification>` with `status: completed` fires whenever a dispatched agent yields with no live background children *of its own*. An agent that sub-delegates to a background child and then yields will notify `completed` immediately — before any deliverable exists.
+The harness mechanics that lived here (task notifications, background grandchildren, `ListAgents`, `TaskStop`, `TaskOutput`, leaf briefs) moved on 2026-10-05 to the implementation skill's reference, together with resume, fork and model-pin behaviour:
 
-## Rules
+`plugins/spire/skills/implementation/references/spawning-claude-code.md`
 
-- Before concluding "the agent stopped/failed," **read the `<result>` text**. A result that announces a hand-off ("I've dispatched...", "running in the background") + a missing artifact = a background child is still working. **Wait for its notification; do not resume-and-redo.**
-- Background children flatten to the session root: each grandchild sends its *own* later notification with a *different* `task-id`. Expect N+1 notifications when sub-delegation happened.
-- The same `task-id` may notify more than once (each is one turn). Key your bookkeeping on the deliverable, not the notification count.
-- When unsure whether work is still in flight, call `ListAgents` before acting. Background grandchildren appear there as flat, top-level subagents of your session with status `running`. If a child is alive and writing your output path, **do not** `SendMessage`-resume the parent — that starts a second writer racing the first. `TaskStop` the child first only if you mean to abandon it.
-- `TaskList` is the todo-list tool, unrelated to agents. `TaskOutput` on an agent dumps its whole transcript into your context — never use it for agents. `ListAgents` is the only agent-liveness check.
+The short version for Igor:
 
-## Leaf tasks
-
-When you dispatch a single self-contained task (read these files, write this one report), the prompt MUST say "do this work yourself; do not dispatch further agents." A `general-purpose` agent has the Agent tool and will hand off if the prompt reads like an orchestration brief. Only `athanor` is *meant* to fan out — route multi-part jobs there instead of hoping a leaf agent stays a leaf.
+- A notification reports a turn ending, not a job finishing. Read the `<result>` text; check `ListAgents` before resuming.
+- Background grandchildren notify you, the root. If a child is still writing an output path, do not resume its parent.
+- Resuming via `SendMessage` is safe from you (the root), not from inside a subagent.
+- Leaf briefs say "do this yourself; do not dispatch further agents."

plugins/spire/skills/igor/references/model-tiers.md

@@ -9,7 +9,7 @@ Prefer a project-pinned agent from `.claude/agents/` when one matches the task;
 | Quick fact extraction, version/config lookup | Haiku lookup | `"scout"` | Fast, cheap, read-only; at most 2 web pages |
 | Code/file lookups, symbol tracing | Sonnet search | `"search"` | Read-only; targeted "where is X" lookups |
 | Planned implementation | implementer agent | project-pinned or omit (defaults to general-purpose) | Executes plans, verifies with the project's check/test commands |
-| Multi-part jobs needing their own subagent fan-out | `athanor` (Opus-tier, may use Agent/Task tool) | `"athanor"` | Decomposes a brief and runs its own subagents |
+| Building a reshaped plan; multi-part jobs needing their own subagent fan-out | `athanor` (pinned to Opus 5.5, may use Agent/Task tool) | `"athanor"`, omit `model` | Builds one phase per turn; also takes non-build fan-out briefs |
 | Complex summaries, git fixes, small code changes | Sonnet subagent | omit (defaults to general-purpose) | Capability/speed balance; needs write access |
 | Test runs, compiles, commits, linear-data summaries | Haiku subagent | omit (defaults to general-purpose) | Fast, cheap, mechanical; needs Bash and possibly write access |
 
@@ -31,7 +31,9 @@ Sub-delegation guard:
 
 Model selection rules:
 
-- **Never dispatch a Fable-tier subagent unless the user explicitly asks.** Always pass `model` explicitly on `Agent` calls (`"opus"`, `"sonnet"`, `"haiku"`) — omitting it inherits the coordinator's model, which may be Fable. Subagents are Opus or lower.
-- **Prefer Opus 4.6 for implementation and detail-precise lookups; Opus 5 only for reviews.** Pinned implementer/researcher agents should be Opus 4.6. `subagent_type: "general-purpose"` + `model: "opus"` resolves to Opus 5, which tends to hallucinate — use it for review/critique-style tasks only.
+- **Never dispatch a Fable-tier subagent unless the user explicitly asks.** Subagents are Opus or lower.
+- **Unpinned agents get an explicit `model`** (`"opus"`, `"sonnet"`, `"haiku"`) — omitting it inherits the coordinator's model, which may be Fable.
+- **Pinned agents get no `model`** unless you deliberately override the pin. The per-call alias overrides the frontmatter pin. Note the choice and have the agent stamp the model id it ran on.
+- **Model traits** (which model is good at what, context guesstimates) live in the implementation skill's `references/models.md`, as dated observations. Defaults as of 2026-10-05: Opus 5.5 for the Athanor, planning, attacking plans and review.
 
 This table can grow — add new agents and heuristics here as they prove out.