
Swarm Planner
- 4 installs
- 224 repo stars
- Updated April 18, 2026
- am-will/swarms
This is a copy of swarm-planner by am-will - installs and ranking accrue to the original listing.
Swarm Planner is a Claude Code skill that creates dependency-aware implementation plans optimized for parallel multi-agent execution, without implementing them.
About
Swarm Planner is a Claude Code skill that creates implementation plans with explicit task dependencies optimized for parallel multi-agent execution. Each task declares an id, depends_on array, description, location, and validation, so root tasks can run in parallel and later tasks wait on their prerequisites. The skill only plans and does not implement, and it spawns a subagent to review the plan for missing dependencies and gaps before finalizing.
- Creates dependency-aware plans with explicit depends_on per task for parallel execution
- Requires fresh docs via Context7 for any external library before finalizing tasks
- Spawns a subagent to review the plan for gaps before yielding; does not implement
Swarm Planner by the numbers
- 4 all-time installs (skills.sh)
- Data as of Aug 2, 2026 (Skillselion catalog sync)
swarm-planner capabilities & compatibility
- Capabilities
- parallel task · super swarm · parallel task tmux
- Works with
- github
- Use cases
- planning · project management · research
What swarm-planner says it does
Creates dependency-aware implementation plans optimized for parallel
Do NOT implement - only create the plan
Every task declares what it depends on, enabling maximum parallelization
npx skills add https://github.com/am-will/swarms --skill swarm-plannerAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 4 |
|---|---|
| repo stars | ★ 224 |
| Last updated | April 18, 2026 |
| Repository | am-will/swarms ↗ |
What it does
Produce a dependency-aware, review-checked implementation plan that downstream swarm skills can execute in parallel.
Who is it for?
Developers who want a structured, parallelizable plan before running a swarm executor.
Skip if: Anyone wanting the plan implemented; this skill only produces the plan.
When should I use this skill?
You need a dependency-annotated plan.md to feed parallel-task or super-swarm.
What you get
A reviewed <topic>-plan.md with per-task depends_on, validation, and parallel execution waves.
- <topic>-plan.md with per-task depends_on, location, and validation
- parallel execution wave table
- dependency graph
By the numbers
- 6 core principles
- 5-step planning process
Files
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 testsTasks 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
# 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**: []
- **location**: [file paths]
- **description**: [what to do]
- **validation**: [how to verify]
- **status**: Not Completed
- **log**: [leave empty, to be filled out later]
- **files edited/created**: [leave empty, to be filled out later]
### T2: [Name]
- **depends_on**: []
- **location**: [file paths]
- **description**: [what to do]
- **validation**: [how to verify]
- **status**: Not Completed
- **log**: [leave empty, to be filled out later]
- **files edited/created**: [leave empty, to be filled out later]
### T3: [Name]
- **depends_on**: [T1]
- **location**: [file paths]
- **description**: [what to do]
- **validation**: [how to verify]
- **status**: Not Completed
- **log**: [leave empty, to be filled out later]
- **files edited/created**: [leave empty, to be filled out later]
[... continue for all tasks ...]
## Parallel Execution Groups
| Wave | Tasks | Can Start When |
|------|-------|----------------|
| 1 | T1, T2 | Immediately |
| 2 | T3, T4 | Wave 1 complete |
| 3 | T5 | T3, T4 complete |
| ... | ... | ... |
## Testing Strategy
- [How to test]
- [What to verify]
## Risks & Mitigations
- [What could go wrong + how to handle]Important
- Every task must have explicit
depends_onfield - Root tasks (no dependencies) can be executed in parallel immediately
- Do NOT implement - only create the plan
- Always use Context7 for external dependencies before finalizing tasks
- Always ask questions where ambiguity exists
Related skills
FAQ
Does this skill write code?
No. Its instructions state Do NOT implement, only create the plan.
How does it ensure the plan is sound?
After saving, it spawns a subagent to review the plan for missing dependencies, ordering issues, and gaps before yielding.