
Parallel Task Spark
- 1.1k installs
- 1k repo stars
- Updated July 14, 2026
- am-will/codex-skills
Parallel Task Executor is an orchestration skill that parses markdown development plans, builds task dependency graphs, launches Sparky subagents in parallel waves, enforces test-first validation, and coordinates atomic
About
Parallel Task Executor (Sparky) orchestrates distributed task execution by parsing plan files, building dependency graphs, and launching Sparky subagents in parallel waves. It manages task blocking/unblocking based on dependencies, enforces RED-phase testing before implementation, validates work through test evidence or documented alternatives, commits changes atomically per task, and updates plan logs. Designed for coordinated multi-agent development workflows where tasks have complex interdependencies.
- Dependency-aware task scheduling - launches unblocked tasks in parallel waves, blocking on dependency completion
- RED-phase test enforcement - mandates test-first verification (RED > GREEN) or explicit non-testable alternatives with e
- Atomic per-task commits - stages only task-specific files to prevent conflicts across parallel agents
- Orchestrate parallel task execution across subagents with dependency management and validation
- Orchestrate parallel task execution across subagents with dependency management and validation
Parallel Task Spark by the numbers
- 1,149 all-time installs (skills.sh)
- Ranked #939 of 16,556 AI & Agent Building skills by installs in the Skillselion catalog
- Security screen: LOW risk (skills.sh audit)
- Data as of Aug 3, 2026 (Skillselion catalog sync)
parallel-task-spark capabilities & compatibility
- Capabilities
- task parsing · dependency graph building · parallel scheduling · test validation · atomic commits · plan logging · error recovery
- Works with
- github · gitlab · bitbucket
- Use cases
- planning · ci cd · code review · testing
- Runs
- Runs locally
What parallel-task-spark says it does
Use orchestration mode to parse plan files and delegate tasks to parallel Sparky subagents using task dependencies, in a loop, until all tasks are completed.
Every launch must set `agent_type: sparky`. Any other role is invalid for this skill.
A task is unblocked if all IDs in its depends_on list are complete.
npx skills add https://github.com/am-will/codex-skills --skill parallel-task-sparkAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1.1k |
|---|---|
| repo stars | ★ 1k |
| Security audit | 2 / 3 scanners passed |
| Last updated | July 14, 2026 |
| Repository | am-will/codex-skills ↗ |
What it does
Orchestrate parallel task execution across subagents with dependency management and validation
Who is it for?
Coordinated multi-agent development workflows with task interdependencies, TDD-enforced implementation, and concurrent execution across teams or subagents.
Skip if: Single-task execution, non-dependency workflows, teams that do not use plan-driven development or reject test-first approaches.
When should I use this skill?
Executing structured development plans with explicit task IDs, dependency declarations, and acceptance criteria that require parallel subagent coordination.
What you get
All plan tasks executed in correct dependency order, validated through RED-phase tests or documented alternatives, atomically committed per-task, and logged with completion status.
- completed plan tasks
- updated plan markdown with execution logs
By the numbers
- Supports explicit task subset filtering (e.g., /parallel-task-spark plan.md T1 T2 T4)
- Enforces RED-phase testing as primary validation path before implementation
- Processes task subsections with minimum metadata: ID, name, depends_on list, acceptance criteria
Files
Parallel Task Executor (Sparky)
You are an Orchestrator for subagents. Use orchestration mode to parse plan files and delegate tasks to parallel Sparky subagents using task dependencies, 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.
Process
Step 1: Parse Request
Extract from user request: 1. Plan file: The markdown plan to read 2. Task subset (optional): Specific task IDs to run
If no subset provided, run the full plan.
Step 2: Read & Parse Plan
1. Find task subsections (e.g., ### T1: or ### Task 1.1:) 2. For each task, extract:
- Task ID and name
- depends_on list (from
- **depends_on**: [...]) - Full content (description, location, acceptance criteria, validation)
3. Build task list 4. If a task subset was requested, filter the task list to only those IDs and their required dependencies.
Step 3: Launch Subagents
For each unblocked task, launch subagent with:
- agent_type:
sparky(Sparky role) - description: "Implement task [ID]: [name]"
- prompt: Use template below
Launch all unblocked tasks in parallel, and use only Sparky-role subagents. A task is unblocked if all IDs in its depends_on list are complete.
Every launch must set agent_type: sparky. Any other role is invalid for this skill.
Task Prompt Template
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
- Use the `sparky` agent role for this task; do not use any other role.
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 taskEnsure 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.
Step 4: Check and Validate.
After subagents complete their work: 1. Inspect their outputs for correctness and completeness. 2. Validate the results against the expected outcomes. 3. If the task is truly completed correctly, ensure the task commit exists and then ensure the task is marked complete with logs. 4. If a task was not successful, have the agent retry or escalate the issue. 5. Ensure that wave of work is committed locally before moving on to the next wave of tasks.
Step 5: Repeat
1. Review the plan again to see what new set of unblocked tasks are available. 2. Continue launching unblocked tasks in parallel until plan is done. 3. Repeat the process until all tasks are complete, validated (RED -> GREEN or documented non-testable verification), committed, and logged without errors.
Error Handling
- Task subset not found: List available task IDs
- Parse failure: Show what was tried, ask for clarification
Example Usage
'Implement the plan using parallel task skill'
/parallel-task-spark plan.md
/parallel-task-spark ./plans/auth-plan.md T1 T2 T4
/parallel-task-spark user-profile-plan.md --tasks T3 T7Execution Summary Template
# 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]Related skills
Forks & variants (1)
Parallel Task Spark has 1 known copy in the catalog totaling 0 installs. They canonicalize to this original listing.
How it compares
Choose parallel-task-spark over manual single-agent prompts when a markdown plan defines parallelizable dependencies and you need wave-based Codex subagent execution.
FAQ
What agent role must subagents use?
Only Sparky-role subagents (agent_type: sparky). Any other role is invalid for this skill.
How does the tool determine task execution order?
By parsing depends_on lists from plan markdown, building a dependency graph, and launching unblocked tasks (those with all dependencies complete) in parallel waves.
What happens if a task fails or is non-testable?
Tasks must provide either RED-phase test evidence (RED > GREEN) or explicit non-testable verification (manual_check, static_check, runtime_check) with exact commands and documented evidence before marking complete.
Is Parallel Task Spark safe to install?
skills.sh reports 2 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.