fix: cut the added prose back to the bare instruction

The first pass replaced Claude Code's tool names with an explanation of what the harness should supply. "Your harness's subagent mechanism" is a wordy restatement of "subagent", and the note about which agent type to pick is a no-op — the agent picks a capable one by default. Say only what changes behaviour: "spawn 3+ sub-agents in parallel". In code-review the sentence goes entirely, because its heading already carries the instruction. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
fix: make subagent dispatch harness-neutral
2026-09-12 18:38:06 +07:00 · 2026-08-06 14:12:30 +01:00 · 2026-08-06 13:58:35 +01:00
4 changed files with 7 additions and 4 deletions
@@ -0,0 +1,5 @@
+---
+"mattpocock-skills": patch
+---
+
+Drop Claude Code's tool and agent-type names from the subagent-dispatch instructions in `code-review`, `codebase-design`, and `improve-codebase-architecture`, so the step is followable on Codex and other harnesses.
@@ -57,8 +57,6 @@ Each smell reads *what it is* → *how to fix*; match it against the diff:

 ### 4. Spawn both sub-agents in parallel

-Send a single message with two `Agent` tool calls. Use the `general-purpose` subagent for both.
-
 **Standards sub-agent prompt** — include:

 - The full diff command and commit list.
@@ -18,7 +18,7 @@ Show this to the user, then immediately proceed to Step 2. The user reads and th

 ### 2. Spawn sub-agents

-Spawn 3+ sub-agents in parallel using the Agent tool. Each must produce a **radically different** interface for the deepened module.
+Spawn 3+ sub-agents in parallel. Each must produce a **radically different** interface for the deepened module.

 Prompt each sub-agent with a separate technical brief (file paths, coupling details, dependency category from [DEEPENING.md](DEEPENING.md), what sits behind the seam). The brief is independent of the user-facing problem-space explanation in Step 1. Give each agent a different design constraint:

@@ -24,7 +24,7 @@ This command is _informed_ by the project's domain model and built on a shared d

 Read the project's domain glossary (`CONTEXT.md`) and any ADRs in the area you're touching first.

-Then use the Agent tool with `subagent_type=Explore` to walk the codebase. Don't follow rigid heuristics — explore organically and note where you experience friction:
+Then spawn a sub-agent to walk the codebase. Don't follow rigid heuristics — explore organically and note where you experience friction:

 - Where does understanding one concept require bouncing between many small modules?
 - Where are modules **shallow** — interface nearly as complex as the implementation?