Super Swarm Spark
Run a markdown implementation plan in parallel with up to fifteen Sparky subagents, then integrate, add tests, and fix failures without manually sequencing every task.
Overview
Super-swarm-spark is an agent skill most often used in Build (also Ship) that parses markdown plans and executes tasks in parallel via a rolling pool of up to fifteen Sparky subagents until the plan is done, tested, and
Install
npx skills add https://github.com/am-will/codex-skills --skill super-swarm-sparkWhat is this skill?
- Rolling pool of up to 15 concurrent Sparky subagents until the plan is complete
- Parses plan markdown (e.g. ### T1: / Task 1.1:) with optional task-ID subset filtering
- Ignores dependency maps to keep slots filled and work moving continuously
- Per-task context packs to reduce path/folder-name drift across parallel agents
- Validates every subagent result, updates the plan file on completion, then runs integration fixes and tests
- Up to 15 concurrent Sparky subagents in a rolling pool
- Seven-step orchestration goals including plan updates, integration fixes, and test runs
Adoption & trust: 1.1k installs on skills.sh; 941 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a detailed markdown plan but serial subagent runs leave slots idle, drift filenames, and skip plan updates and test hardening at the end.
Who is it for?
Solo builders with an existing agent plan who want maximum concurrency and a enforced close-out pass (plan sync, integration, tests).
Skip if: Casual one-off prompts, work without an explicit super-swarm-spark trigger, or plans where strict dependency ordering must never be violated.
When should I use this skill?
Only when the user issues explicit super-swarm-spark commands with a plan file (and optional task ID subset).
What do I get? / Deliverables
The plan file reflects completed tasks, parallel work used up to fifteen agents with checked results, and the repo gets integration fixes plus tests run and failures addressed.
- Updated plan file with completed tasks reflected
- Integrated codebase changes with post-run test fixes
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build because the skill’s core job is executing plan tasks in parallel across the codebase; it also gates quality in Ship via post-run tests and integration fixes. Agent-tooling fits orchestration of many coding subagents, context packs, and filename drift control—not a single integration or frontend task.
Where it fits
Fan out twenty plan tasks across fifteen Sparky workers with per-task path context so API and UI folders stay consistent.
Mark tasks complete in the source plan markdown as subagents return so progress stays the single source of truth.
After all tasks finish, add missing tests and run the suite, fixing failures from parallel edits.
Run final integration fixes when parallel agents left conflicting interfaces or duplicate utilities.
How it compares
Use instead of hand-rolling one subagent at a time when you already have a structured plan file, not as a substitute for writing or approving that plan first.
Common Questions / FAQ
Who is super-swarm-spark for?
Indie and solo builders orchestrating Codex or similar agents who maintain markdown implementation plans and want a fifteen-agent rolling executor with validation and test close-out.
When should I use super-swarm-spark?
During Build when executing large multi-task plans in parallel, and again in Ship when you need integration fixes and test runs after bulk agent work—only when you explicitly invoke super-swarm-spark commands.
Is super-swarm-spark safe to install?
It drives many parallel agents with broad file context; review the Security Audits panel on this page and your repo permissions before running against production or sensitive code.
SKILL.md
READMESKILL.md - Super Swarm Spark
# Parallel Task Executor (Sparky Rolling 12-Agent Pool) You are an Orchestrator for subagents. Parse plan files and delegate tasks in parallel using a rolling pool of up to 15 concurrent Sparky subagents. Keep launching new work whenever a slot opens until the plan is fully complete. Primary orchestration goals: - Keep the project moving continuously - Ignore dependency maps - Keep up to 15 agents running whenever pending work exists - Give every subagent maximum path/file context - Prevent filename/folder-name drift across parallel tasks - Check every subagent result - Ensure the plan file is updated as tasks complete - Perform final integration fixes after all task execution - Add/adjust tests, then run tests and fix failures ## 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 - Task linkage metadata for context only - Full content (description, location, acceptance criteria, validation) 3. Build task list 4. If a task subset was requested, filter to only those IDs. ### Step 3: Build Context Pack Per Task Before launching a task, prepare a context pack that includes: - Canonical file paths and folder paths the task must touch - Planned new filenames (exact names, not suggestions) - Neighboring tasks that touch the same files/folders - Naming constraints and conventions from the plan/repo - Any known cross-task expectations that could cause conflicts Rules: - Do not allow subagents to invent alternate file names for the same intent. - Require explicit file targets in every subagent assignment. - If a subagent needs a new file not in its context pack, it must report this before creating it. ### Step 4: Launch Subagents (Rolling Pool, Max 12) Run a rolling scheduler: - States: `pending`, `running`, `completed`, `failed` - Launch up to 12 tasks immediately (or fewer if less are pending) - Whenever any running task finishes, validate/update plan for that task, then launch the next pending task immediately - Continue until no pending or running tasks remain For each launched task, use: - **agent_type**: `sparky` (Sparky role) - **description**: "Implement task [ID]: [name]" - **prompt**: Use template below Do not wait for grouped batches. The only concurrency limit is 12 active Sparky subagents. 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] - Task relationships: [related metadata for awareness only, never as a blocker] - Canonical folders: [exact folders to use] - Canonical files to edit: [exact paths] - Canonical files to create: [exact paths] - Shared-touch files: [files touched by other tasks in parallel] - Naming rules: [repo/plan naming constraints] - 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. Examine the plan and all listed canonical paths before editing 2. Implement changes for all acceptance criteria 3. Keep work atomic and committable 4. For each file: read first, edit carefully, preserve formatting 5. Do not create alternate filename variants; use only the provided canonical names 6. If you need to touch/create a path not listed, stop and report it first 7. Run validation if feasible 8. ALWAYS mark completed tasks IN THE *-plan.md file AS SOON AS Y