🤖 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.