Subagent Dispatch Protocol

This skill governs when and how to dispatch subagents in this project. Its purpose is to help the main agent make effective delegation decisions and write high-quality, self-contained prompts for each specialist.

---

When to Dispatch (vs Do It Yourself)

Dispatch a subagent when any of these apply:

Signal	Why dispatch?
Context isolation needed	Command output, logs, or search results are verbose and would pollute the main conversation
Specialist expertise	The task maps cleanly to an existing agent's domain (see registry below)
Parallelizable work	Two or more independent tasks can run concurrently in separate agents
Review/validation gate	A second opinion or compliance check is needed before accepting work

Do it yourself when the task is trivial, already in-context, or requires tight back-and-forth with the user that a stateless subagent cannot provide.

---

Agent Registry

Custom agents live at agents/<agent-name>.agent.md.

Agent	Role	Key trait	Invocable
Bash Search Worker	Shell-based repository search and filtering	Context isolation; read-only execute only	Subagent only
Code Simplifier	Simplify and refine code for clarity	Preserves functionality; applies project standards	User + subagent
Compliance Reviewer	Compare implementation against plan/spec	Deviation analysis; requirement verification	Subagent only
Codebase Analyzer	Analyze implementation details of existing code	Precise file:line references; no speculation	User + subagent
Generalist	General-purpose coding, research, debugging	Broad skill set; retrieval-led reasoning	Subagent only
Green (TDD)	Write minimal code to pass a failing test	Never modifies tests; minimal production code	Subagent only
Orchestrator	Delegate and coordinate multi-agent workflows	Never implements; dispatches and consolidates	User only
Quality Reviewer	In-depth code review and analysis	Security, patterns, maintainability	Subagent only
Red (TDD)	Write one failing test for one behaviour	Never touches production code	Subagent only
Reviewer Group	Orchestrate multi-perspective code review	Spawns multiple Quality Reviewers	User only
UI Composer	Build visually polished, performant UI components	Styling, animation, layout expertise	User + subagent

If an agent is not listed (newly added), read its .agent.md file and extract the description and model fields from the YAML frontmatter.

---

Model Fallback Reference

Always use the model specified in the frontmatter. Use this table only when the agent's preferred model is temporarily unavailable:

Preferred model	Fallback
Gemini 3.1 Pro (Preview)	Claude Opus 4.6
Gemini 3 Pro (Preview)	Claude Opus 4.6
Claude Opus 4.6	GPT-5.4
Claude Sonnet 4.6	GPT-5.4
GPT-5.4 mini	Claude Haiku 4.5

For built-in agent types (explore, code-review, etc.) that have no .agent.md, skip model resolution — use platform defaults.

---

Core Dispatch Principles

1. One agent per problem domain. Each dispatch targets exactly one specialist.
2. Subagents are stateless. They have zero memory of the current conversation. The prompt must be entirely self-contained.
3. Parallel when independent. Dispatch agents concurrently when their tasks have no data dependency (e.g., Quality Reviewer + Compliance Reviewer on the same diff).
4. Review before accepting. Evaluate subagent output critically. Request revisions or re-dispatch when quality or relevance falls short.

---

Parallel Dispatch

When two or more tasks are independent, dispatch them in the same turn:

• Do: Quality Reviewer + Compliance Reviewer on the same changeset.
• Do: Bash Search Worker for file discovery while Generalist researches docs.
• Don't: Green (TDD) before Red (TDD) — Green depends on Red's failing test.

Rule of thumb: if task B does not need task A's output, they can run in parallel.

---

Prompting Checklist

Every subagent prompt must answer all four of these:

• Context: What is the project? What stack, conventions, and files are relevant?
• Task: What exactly needs to be done? What are the constraints?
• Direction: Where should the agent look first? Which references or docs to consult?
• Success criteria: What does "done" look like? What is the expected output format?

Thin prompts produce thin results. If a subagent fails or produces something off-target, the root cause is almost always an underspecified prompt — not the agent's capability.