From tp-sadd
Dispatch sub-agents with CoT reasoning and self-critique: single-task dispatch with auto model selection, or plan-driven multi-task execution with code review gates
How this skill is triggered — by the user, by Claude, or both
Slash command
/tp-sadd:sadd-dispatch Task description [--model opus|sonnet|haiku] [--agent <name>] [--plan <path>]When to use
When user says 'dispatch sub-agent', 'launch agent for task', 'delegate this', 'run in background'. IMMEDIATELY when user wants to delegate a focused task with context isolation. FIRST when task requires automatic model selection and verification before completion. DO NOT use when the task needs quality verification gates and iterative refinement — use sadd-execute instead. DO NOT use for multi-step plans with sequential dependencies — use subagent-driven-development instead.
Task description [--model opus|sonnet|haiku] [--agent <name>] [--plan <path>]The summary Claude sees in its skill listing — used to decide when to auto-load this skill
IF user asks to delegate a focused single task to a sub-agent → single mode: analyze task, select model, dispatch with CoT prefix and self-critique suffix
IF user asks to delegate a focused single task to a sub-agent → single mode: analyze task, select model, dispatch with CoT prefix and self-critique suffix IF executing a plan with independent tasks sharing no state or files → parallel plan mode: dispatch one sub-agent per task simultaneously, then review holistically IF executing a plan with sequential or dependent tasks → sequential plan mode: dispatch one sub-agent per task in order, review after each IF investigating 3+ unrelated issues without shared state → parallel investigation mode: group by subsystem, dispatch per domain, review for conflicts IF the task is trivial (single file, mechanical change) → use Haiku without specialized agent IF tasks share state or files → do NOT parallelize; use sequential with code review between each
Dispatch sub-agents with isolated context for focused execution. Supports single-task dispatch with automatic model selection, or plan-driven multi-task execution with code review as a quality gate. Each sub-agent works in a clean context window without accumulated context pollution.
Context isolation is the primary benefit of sub-agents. Each sub-agent works in a clean context window without accumulated context pollution. The orchestrator owns all cognition; the sub-agent owns only execution.
Dispatch one sub-agent with isolated context for a focused task. Best for single requests where a dedicated agent handles implementation, research, or analysis.
Phase 1: Task Analysis — Determine type (implementation, research, documentation, review, architecture, testing, transformation), complexity (high/medium/low), output size (large/medium/small), and domain match.
Phase 2: Model Selection
| Profile | Model |
|---|---|
| Complex reasoning (architecture, design, critical decisions) | Opus |
| Specialized domain with complexity | Opus + specialized agent |
| Non-complex but long output | Sonnet |
| Simple and short | Haiku |
| Default (uncertain) | Opus |
Phase 3: Specialized Agent Matching — Use a specialized agent when the task clearly benefits from domain expertise (developer for code, researcher for investigation, architect for design). Skip specialization for trivial tasks. If no matching specialist exists, use general-purpose.
Phase 4: Construct Sub-Agent Prompt — Build with three mandatory components:
Phase 5: Dispatch — Use the Task tool with selected model. Pass only context relevant to this specific task — never the entire conversation history.
The sub-agent returns its work directly. The orchestrator reviews output quality before accepting.
Execute plans by dispatching a fresh sub-agent per task with code review as a quality gate between them. Each sub-agent gets a clean context focused on its specific task, avoiding context pollution from accumulated session state.
Stop and ask for help when: a blocker is hit mid-task, plan has critical gaps, verification fails repeatedly, or instructions are unclear. Do not force through blockers.
The CoT prefix forces structured reasoning before action, preventing the "rush to implement" failure mode. The self-critique suffix provides a quality gate before submission, catching the most common errors (incomplete requirements, missed edge cases, pattern violations).
Model tiering saves cost without sacrificing quality. Haiku handles ~30% of real-world tasks (mechanical updates, documentation tweaks). Opus reserved for the ~40% that genuinely need reasoning depth.
Each sub-agent starts with a clean context focused on its specific task. Accumulated context from previous tasks (file exploration, decisions made, dead ends) would pollute a single agent's reasoning. Fresh context per task means each decision is made with full attention.
Catching issues immediately prevents cascading failures where later tasks build on broken foundations. The cost of fixing an issue grows with each downstream task that depends on it.
npx claudepluginhub git-fg/taches-principled --plugin tp-saddProvides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.