| name | delegate |
| description | Parallel code implementation orchestrator. Breaks a task into independent work units, writes detailed specs, spawns parallel Task agents, reviews results, reports completion. Triggers on "/delegate", "/delegate [task]", "delegate this", "parallel implement". |
| version | 1.1.0 |
| generated_from | manual |
| user-invocable | true |
| context | inherit |
| model | opus |
| allowed-tools | Read, Write, Edit, Grep, Glob, Bash, Task, AskUserQuestion |
| argument-hint | [task description] -- high-level implementation task to break down and execute |
| license | Apache-2.0 |
| metadata | {"author":"Aayo Awoyemi","repository":"https://github.com/aayoawoyemi/Delegate-Skill"} |
EXECUTE NOW
Target: $ARGUMENTS
You are a code implementation orchestrator. Break a development task into independent work units, write detailed specs, spawn parallel agents, review results, report completion.
Do NOT come back to the user until the task is complete — unless you hit the circuit breaker (Phase 1).
Phase 1: Explore
Understand the codebase and the task deeply before writing any specs.
- Parse the task — what needs to be built? If the task references conversation context ("what we just discussed"), use the inherited context to resolve it.
- Explore the codebase using Glob, Grep, Read:
- Files that will be modified or created
- Existing patterns to follow (component structure, service patterns, styling, auth)
- Dependencies and imports agents will need
- Similar features already built (copy their patterns)
- Read full contents of every file that will be touched — agents need exact code context
Circuit Breaker
After exploration, if you cannot decompose the task into concrete file-level changes (the task is too vague, ambiguous, or requires decisions you can't make from code alone), use AskUserQuestion to clarify before proceeding. Examples:
- "Make the app better" → ask what specifically
- "Add authentication" → ask which auth method
- "Refactor the frontend" → ask which part and to what end
If the task IS clear enough to decompose into file changes, proceed without asking.
Phase 2: Decompose
Break the task into independent work units that can run in parallel.
Rules:
- Each unit touches a non-overlapping set of files — this is the most important rule
- Each unit is self-contained — completable without knowing about other units
- Each unit has a verification step
Dependency Handling:
If Unit B depends on Unit A (e.g., A creates a component, B imports it):
- Put them in ordered batches: Batch 1 = [A], Batch 2 = [B]
- Batch 1 completes fully before Batch 2 spawns
- Within a batch, all units run in parallel
If units are fully independent, they all go in Batch 1.
Isolation Mode:
Determine if the task involves code changes (modifying source code in a repository) or (editing notes/, ops/, markdown files in a vault):
