Delegate Skill
Parallel code implementation skill for Claude Code. Spawns up to 5 concurrent agents with git worktree isolation, auto-retry, and structured review. /delegate [task]
npx -y skills add aayoawoyemi/Delegate-SkillAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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".
The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
7.1 KB, as published. Nobody here has run it
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 knowledge work (editing notes/, ops/, markdown files in a vault):
- Code tasks → set
isolation: "worktree"on all spawned agents. Each agent gets its own git worktree — zero file conflict risk by construction, not convention. - Knowledge tasks → skip worktree isolation. Notes and ops files are append-mostly; the non-overlapping file rule is sufficient.
Output: Ordered list of batches, each containing independent work units, plus isolation mode (worktree or standard).
Phase 3: Write Specs
For each work unit, write a fully self-contained spec. An agent receiving this spec must be able to execute it cold with zero additional context.
Every spec MUST include:
A. Context Block
PROJECT: [path to project root]
STACK: [e.g., Next.js + React + Auth0 + lucide-react icons + CSS variables]
FILES TO READ FIRST: [exact paths]
B. Existing Code Snippets
Paste the actual code from explored files that the agent needs to follow. Not "follow existing patterns" — paste the pattern. Include:
- Import conventions
- Component structure
- Styling approach (CSS variables, inline styles, class names)
- Auth patterns
- Any shared utilities
C. Implementation Instructions
For each file:
- New files: Full content or detailed structure with actual code
- Edits: Exact old string → new string, or where to insert with surrounding context
- Import statements, function signatures, props — be explicit
D. Verification
How the agent should verify its work completed correctly.
E. Leaf-Node Constraint (include in EVERY spec)
IMPORTANT: You are a leaf-node Task agent.
- DO NOT invoke any skills (like /extract, /connect, etc.)
- DO NOT spawn any agents
- DO NOT ask questions — execute the spec
- If something is ambiguous, match the closest existing pattern in the codebase
Phase 4: Execute
Single Batch:
Spawn all Task agents in parallel in a single message:
Task(
prompt = {spec},
description = "{5 words max}",
subagent_type = "general-purpose",
isolation = "worktree" // only for code tasks — omit for knowledge work
)
Multiple Batches:
Execute batch by batch. Wait for Batch N to fully complete before spawning Batch N+1.
Max 5 concurrent agents per batch. If a batch has more than 5 units, split into sub-batches.
Phase 5: Review & Integrate
After ALL agents in ALL batches report back:
- Read every modified/created file to verify changes are correct
- Check integration points:
- Do imports across files align? (Agent A created it, Agent B imports it)
- Naming consistency?
- Styling consistency?
- Fix issues directly — small integration fixes are your job
- Run practical checks:
- For Python:
python -c "from app.module import thing"to verify imports - For Next.js/React: check that imports reference real files and exports
- If the project has a build command and changes are significant, run it
- For Python:
- Failure reactions:
- If an agent returned empty or error output: retry once — re-spawn a single agent with the same spec. Cap: 1 retry per unit.
- If the retry also fails, or the output is merely low quality: fix it yourself rather than re-spawning again.
- Track retry count for the report.
Phase 6: Report
--=={ delegate }==--
Task: {original task description}
Batches: {N} ({sequential if >1, parallel if 1})
Agents spawned: {total count}
Work Units:
1. {unit name} — {done/fixed/failed}
2. {unit name} — {done/fixed/failed}
Files Created:
- {path} — {purpose}
Files Modified:
- {path} — {what changed}
Integration Fixes: {count or "none needed"}
Retries: {count or "none"}
Ready to test: {specific instructions}
Critical Constraints
Never:
- Come back to the user mid-task unless circuit breaker fires
- Let agents touch overlapping files
- Skip the review phase
- Execute implementation yourself instead of spawning agents (orchestrate, don't do)
- Write specs without actual code snippets from the codebase
Always:
- Read all files BEFORE writing specs
- Include real code in specs
- Spawn agents in parallel within a batch
- Review all changes after agents complete
- Fix integration issues before reporting
- Report only when fully complete