Swarm Planner
Turn a feature request into a dependency-graph task list so multiple coding agents can work in parallel without stepping on each other.
Overview
Swarm Planner is an agent skill most often used in Build (also Validate scope, Ship launch prep) that produces dependency-aware implementation plans optimized for parallel multi-agent execution.
Install
npx skills add https://github.com/am-will/codex-skills --skill swarm-plannerWhat is this skill?
- Six core principles: codebase exploration, Context7-first external docs, clarifying questions, explicit task dependencie
- Dependency-aware task graph optimized for parallel multi-agent execution
- Explicit invocation only—runs inside or outside Codex Plan Mode when you deliberately call it
- Optional stop-and-yield via AskUserQuestions when architecture is unclear before continuing research
- Subagent gap review step before the plan is handed to implementers
- 6 core planning principles documented in the skill
- Mandatory subagent review before finalizing the plan
Adoption & trust: 1.2k installs on skills.sh; 941 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You know what to build but your agent plan is a flat checklist—so parallel agents duplicate work, block each other, or miss prerequisites.
Who is it for?
Solo builders orchestrating several agent sessions on one repo, refactors with clear file boundaries, or features where tasks can run in parallel after shared foundations land.
Skip if: One-liner fixes, spikes with no codebase access, or situations where you already have an approved writing-plans spec and only need line-by-line execution without re-exploration.
When should I use this skill?
Explicit invocation only when you want a swarm-ready, dependency-aware implementation plan for parallel agent execution (with or without Plan Mode).
What do I get? / Deliverables
You get an atomic, dependency-labeled task graph reviewed for gaps, ready to assign to multiple agents or sequential handoffs without re-planning from scratch.
- Dependency-aware implementation plan with atomic per-agent tasks
- Documented prerequisites and blocking relationships between tasks
- Reviewed plan after subagent gap pass
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is build/pm because the primary artifact is an implementation plan with atomic tasks—not shipping gates or growth work. Plans name dependencies, ownership, and execution order—the same artifacts solo builders use in backlog and agent dispatch during product construction.
Where it fits
Break a MVP epic into atomic agent tasks with depends-on edges before anyone writes production code.
Map a cross-cutting refactor so database migration tasks finish before parallel UI agents touch shared types.
Plan API and worker changes so contract tasks unblock frontend agents on stable OpenAPI shapes.
Order release checklist items (migrations, feature flags, smoke tests) for parallel owners with clear sequencing gates.
How it compares
Use instead of ad-hoc chat task lists when you need explicit depends-on edges for parallel agents—not a generic brainstorming or PR review skill.
Common Questions / FAQ
Who is swarm-planner for?
Indie and solo developers using Codex, Claude Code, or Cursor who routinely split implementation across multiple agent runs and need formal task dependencies.
When should I use swarm-planner?
During Validate when scoping a multi-part feature into agent-sized chunks; in Build when kicking off a refactor or greenfield module; and before Ship when you want ordered prep tasks (tests, migrations) with parallelizable follow-ups—always with explicit invocation.
Is swarm-planner safe to install?
Treat it like any third-party skill: review the Security Audits panel on this Prism page and your org policy before enabling repo-wide; planning skills read the codebase and may call documentation tools you configure (e.g. Context7).
SKILL.md
READMESKILL.md - Swarm Planner
# Swarm-Ready Planner Create implementation plans with explicit task dependencies optimized for parallel agent execution. This skill can be ran inside or outside of Plan Mode. ## Core Principles 1. **Explore Codebase**: Investigate architecture, patterns, existing implementations, dependencies, and frameworks in use. 2. **Fresh Documentation First**: Use Context7 for ANY external library, framework, or API before planning tasks 3. **Ask Questions**: Clarify ambiguities and seek clarification on scope, constraints, or priorities throughout the planning process. At any time. 4. **Explicit Dependencies**: Every task declares what it depends on, enabling maximum parallelization 5. **Atomic Tasks**: Each task is independently executable by a single agent 6. **Review Before Yield**: A subagent reviews the plan for gaps before finalizing ## Process ### 1. Research **Codebase investigation:** - Architecture, patterns, existing implementations - Dependencies and frameworks in use ### 1a. Optional: Stop to Clarification Questions - If the architecture is unclear or missing STOP AND YIELD to the user, and request user input (AskUserQuestions) before moving on. Always offer recommendations for clarification questions. - If architecture is present, skip 1a and move onto next step. ### 2. Documentation **Documentation retrieval (REQUIRED for external dependencies):** Use Context7 skill or MCP to fetch current docs for any libraries/frameworks or APIs that are or will be used in project. If Context7 is not available, use web search. This ensures version-accurate APIs, correct parameters, and current best practices. ### 3. STOP and Request User Input When anything is unclear or could reasonably be done multiple ways: - Stop and ask clarifying questions immediately - Do not make assumptions about scope, constraints, or priorities - Questions should reduce risk and eliminate ambiguity - Always offer recommendations for clarification questions. - Use request_user_input or AskUserQuestion tool if available. ### 4. Create Dependency-Aware Plan Structure the plan with explicit task dependencies using this format: #### Task Dependency Format Each task MUST include: - **id**: Unique identifier (e.g., `T1`, `T2.1`) - **depends_on**: Array of task IDs that must complete first (empty `[]` for root tasks) - **description**: What the task accomplishes - **location**: File paths involved - **validation**: acceptance criteria **Example:** ``` T1: [depends_on: []] Create database schema migration T2: [depends_on: []] Install required packages T3: [depends_on: [T1]] Create repository layer T4: [depends_on: [T1]] Create service interfaces T5: [depends_on: [T3, T4]] Implement business logic T6: [depends_on: [T2, T5]] Add API endpoints T7: [depends_on: [T6]] Write integration tests ``` Tasks with empty/satisfied dependencies can run in parallel (T1, T2 above). ### 4. Save Plan Save to `<topic>-plan.md` in the CWD. ### 5. Subagent Review After saving, spawn a subagent to review the plan: ``` Review this implementation plan for: 1. Missing dependencies between tasks 2. Ordering issues that would cause failures 3. Missing error handling or edge cases 4. Gaps, holes, gotchas. Provide specific, actionable feedback. Do not ask questions. Plan location: [file path] Context: [brief context about the task] ``` If the subagent provides actionable feedback, revise the plan before yielding. ## Plan Template ```markdown # Plan: [Task Name] **Generated**: [Date] ## Overview [Summary of task and approach] ## Prerequisites - [Tools, libraries, access needed] ## Dependency Graph ``` [Visual representation of task dependencies] T1 ──┬── T3 ──┐ │ ├── T5 ── T6 ── T7 T2 ──┴── T4 ──┘ ``` ## Tasks ### T1: [Name] - **depends_on**: [