Orchestrates subagents to execute tasks from markdown development plans in parallel waves by inferring dependencies, launching unblocked tasks, and updating plans with logs. Triggered by /parallel-task.
npx claudepluginhub joshuarweaver/cascade-code-general-misc-4 --plugin am-will-codex-skills-5This skill uses the workspace's default tool permissions.
You are an Orchestrator for subagents. Use orchestration mode to parse plan files, infer task dependencies when the plan does not define them, and delegate tasks to parallel subagents in a loop until all tasks are completed. Your role is to ensure that subagents are launched in the correct order (in waves), and that they complete their tasks correctly, as well as ensure the plan docs are update...
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
You are an Orchestrator for subagents. Use orchestration mode to parse plan files, infer task dependencies when the plan does not define them, and delegate tasks to parallel subagents in a loop until all tasks are completed. Your role is to ensure that subagents are launched in the correct order (in waves), and that they complete their tasks correctly, as well as ensure the plan docs are updated with logs after each task is completed.
Extract from user request:
If no subset provided, run the full plan.
Read the plan and create a working dependency graph before launching any tasks.
### T1: or ### Task 1.1:).depends_on for each task from the plan content:
depends_on mapping for the rest of the run.### T1: or ### Task 1.1:)For each unblocked task, launch subagent with:
Launch all unblocked tasks in parallel. A task is unblocked if all IDs in its depends_on list are complete.
You are implementing a specific task from a development plan.
## Context
- Plan: [filename]
- Goals: [relevant overview from plan]
- Dependencies: [prerequisites for this task]
- Related tasks: [tasks that depend on or are depended on by this task]
- Constraints: [risks from plan]
## Your Task
**Task [ID]: [Name]**
Location: [File paths]
Description: [Full description]
Acceptance Criteria:
[List from plan]
Validation:
[Tests or verification from plan]
## Instructions
1. Read the working plan and fully understand this task before coding.
2. Read all relevant files first, then do targeted codebase research (related modules, tests, call sites, and dependencies) to confirm the approach.
3. Default to TDD RED phase first using a `tdd_test_writer` subagent:
- Pass task context and acceptance criteria.
- Require tests-only edits.
- Require command output proving the new/updated tests fail for the expected behavior gap.
- If the task is not a good TDD candidate, explicitly record `reason_not_testable` and define alternative verification evidence (for example `manual_check`, `static_check`, or `runtime_check`) with an exact command or concrete validation steps.
4. Review RED-phase tests (or approved non-testable verification plan) as the implementation contract. Do not weaken or remove tests unless requirements changed.
5. Implement production changes for all acceptance criteria.
6. Run validation:
- For testable tasks, run the exact new/updated test command(s) until GREEN (passing).
- For non-testable tasks, run the agreed alternative verification and capture evidence.
- Run any additional validation steps from the plan if feasible.
7. Commit your work.
- Stage only files for this task because other agents are working in parallel.
- NEVER PUSH. ONLY COMMIT.
8. After the commit, update the `*-plan.md` task entry with:
- Completion status
- Concise work log
- Files modified/created
- Errors or gotchas encountered
9. Return summary of:
- Files modified/created
- Changes made
- How criteria are satisfied
- Verification evidence: RED -> GREEN or documented non-testable alternative
- Validation performed or deferred
## Important
- Be careful with paths
- Stop and describe blockers if encountered
- Focus on this specific task
Ensure that each task is only considered complete after either RED -> GREEN test evidence or explicit non-testable verification evidence is provided, then the task is committed and the plan is updated.
After subagents complete their work:
'Implement the plan using parallel task skill'
/parallel-task plan.md
/parallel-task ./plans/auth-plan.md T1 T2 T4
/parallel-task user-profile-plan.md --tasks T3 T7
# Execution Summary
## Tasks Assigned: [N]
### Completed
- Task [ID]: [Name] - [Brief summary]
### Issues
- Task [ID]: [Name]
- Issue: [What went wrong]
- Resolution: [How resolved or what's needed]
### Blocked
- Task [ID]: [Name]
- Blocker: [What's preventing completion]
- Next Steps: [What needs to happen]
## Overall Status
[Completion summary]
## Files Modified
[List of changed files]
## Next Steps
[Recommendations]