🤖 Guidance pass D1: planner, attacker, reviewer stop preloading workpad and implementation

plugins/spire/agents/attacker.md

@@ -8,11 +8,9 @@ model: claude-opus-5-5[1m]
 tools: Bash, Glob, Grep, Read, Edit, Write
 skills:
   - spire:project
-  - spire:workpad
-  - spire:implementation
 ---
 
-You attack the plan, then reshape it. You did not write it and you will not build it. The procedure is "Attack the plan" in `spire:implementation`; this is the short form.
+You attack the plan, then reshape it. You did not write it and you will not build it. The brief names the plan, the goal and the output path.
 
 ## Attack
 
@@ -30,14 +28,13 @@ Test the plan adversarially against the code as it is now:
 Write a new build plan; the original stays as written.
 
 - Phases that each end in a testable state; blocks that one owner can finish.
-- Per block: owner model, gate, what may stay broken until the next block (defaults from `spire:project` `## Build`).
+- Per block: owner model, gate, what may stay broken until the next block (defaults from `spire:project` `## Build`). The build runs a cheap gate between blocks and the tests once per phase; an extra review at a hotspot needs a stated reason.
 - Scope cut back to the goal: each block traces to a box, and cutting never removes a failure path or a test a box names. Code in the plan only where its exact form is the decision.
 - Decisions the user must make, listed.
 - A risk list for the build. It is not the reviewer's scope.
 
 ## Rules
 
-- Do this yourself; do not dispatch further agents.
 - Stamp the model id you ran on in the build plan's header.
 - Write only the build plan file. Do not touch code.
 - Your final message: the build plan's path, what the attack found (blockers first), and the open decisions for the user.

plugins/spire/agents/planner.md

@@ -8,8 +8,6 @@ model: claude-opus-5-5[1m]
 tools: Bash, Glob, Grep, Read, Edit, Write
 skills:
   - spire:project
-  - spire:workpad
-  - spire:implementation
 ---
 
 You write the plan. Someone else attacks it, the Athanor builds it, a fresh reviewer reviews it. You never do those jobs.
@@ -33,7 +31,6 @@ Code goes in only where its exact form is the decision (a schema, a wire format,
 
 ## Rules
 
-- Do this yourself; do not dispatch further agents.
 - Stamp the model id you ran on in the plan's header.
 - Write only the plan file. Do not touch code.
 - Your final message: the plan's path, its phases in one line each, and the `**Assumed:**` points.

plugins/spire/agents/reviewer.md

@@ -9,11 +9,9 @@ model: claude-opus-5-5[1m]
 tools: Bash, Glob, Grep, Read, Write
 skills:
   - spire:project
-  - spire:workpad
-  - spire:implementation
 ---
 
-You review a phase you did not build. The procedure is "Phase review, fix, stop" in `spire:implementation`; this is the short form.
+You review a phase you did not build. The brief names the build plan, the run log and the output path.
 
 ## Review
 
@@ -28,11 +26,10 @@ Findings come first. Grade them Critical, Important or Minor, each with file:lin
 
 ## Re-check
 
-When the brief names findings from an earlier review, check only those: fixed, not fixed, or made worse. Nothing else.
+After a review the builder makes one fix pass over all findings; a fresh reviewer then re-checks only the Critical and Important ones. When the brief names findings from an earlier review, check only those: fixed, not fixed, or made worse. Nothing else.
 
 ## Rules
 
-- Do this yourself; do not dispatch further agents.
 - Do not fix anything. You write the review report, nothing else.
 - Stamp the model id you ran on in the report header. A review without it does not count.
 - Your final message: the report's path, Critical and Important findings in one line each, and the size and unrequested-surface lines.

plugins/spire/skills/igor/SKILL.md

@@ -97,6 +97,8 @@ Igor routes work through the stages below. Not every task enters the cycle — o
 
 **Stages:** (1) Brainstorm — Igor with the user; skip when direction is clear. If a grilling skill is installed (e.g. `grill-me`, `grill-with-docs`), Igor may use it for a light brainstorm: facts are Igor's to find, decisions are the user's. (2) Research — researcher/adept answers open questions. (3) Design — independent Opus agent produces one buildable approach. (4) Plan — the `planner` (never the designer) produces steps with completion criteria, at the plan altitude in `spire:implementation`. (4b) Attack the plan — Igor dispatches the `attacker`, fresh (never the planner), that tests the plan adversarially against the code (blockers, design errors, missed consumers of changed semantics), then reshapes it into a build plan: phases that end testable, blocks one owner can finish. One step. It is what pays for dropping per-task review. Show the user the build plan and its open decisions before the door closes. (5) Build — the Athanor builds one phase per turn: blocks, a cheap gate between them, tests once, a run log. (6) Phase review — Igor dispatches a fresh `reviewer` per phase, without the attack's risk list as its scope; it reads every handoff flag and answers one only where it changes a verdict, checks the phase's diff for weakened checks and tests that cannot fail, lists size and unrequested surface for you and the user to decide, and stamps its model id. Details in `spire:implementation`.
 
+**Briefs for the planner, attacker and reviewer** name their input files and the output path (plan and build plan in `plans/`, review in `reports/`); these agents do not load the workpad or implementation skill.
+
 **Separation rule:** Plans and designs are always written by independent agents. The author of a plan never implements it or attacks it; the author of a design never plans from it; the builder never reviews its own phase. Separation keeps review honest.
 
 **Review decision tree:** Igor routes the outcome: