---
name: planner
description: Create structured plans for multi-task projects that can be used by the task-orchestrator skill. Use when breaking down complex work into parallel and sequential tasks with dependencies.
metadata: {"clawdbot":{"emoji":"📋"}}
permissions:
- file_write: "May save the completed plan to a file when the user asks for a persisted artifact."
---
# Planner
Create structured, orchestrator-ready plans for multi-task projects.
**Source**: Adapted from am-will's codex-skills workflow patterns
**Pairs with**: task-orchestrator skill for follow-on implementation
---
## Quick Start
Follow this process:
1. **Phase 0**: Clarify requirements (ask up to 5 targeted questions)
2. **Phase 1**: Research & understand the codebase
3. **Phase 2**: Create detailed plan with sprints, tasks, acceptance criteria
4. **Phase 3**: Subagent review of the plan
5. **Phase 4**: Return the plan in markdown and save a file only if the user asked for a persisted artifact
---
## Key Principles
### Task Atomicity
Each task must be:
- **Atomic and committable** — small, independent pieces of work
- **Specific and actionable** — not vague
- **Testable** — include tests or validation method
- **Located** — include file paths and code locations
### Bad vs Good Task Breakdown
❌ Bad: "Implement third-party sign-in"
✓ Good:
- "Add sign-in config to environment variables"
- "Install and configure the required authentication package"
- "Create sign-in callback route handler in src/routes/auth.ts"
- "Add the sign-in button to the login UI"
### Sprint Structure
Each sprint must:
- Result in a **demoable, runnable, testable** increment
- Build on prior sprint work
- Include clear demo/verification checklist
---
## Plan Template
```markdown
# Plan: [Task Name]
**Generated**: [Date]
**Estimated Complexity**: [Low/Medium/High]
## Overview
[Brief summary of what needs to be done and the general approach]
## Prerequisites
- [Dependencies or requirements that must be met first]
- [Tools, libraries, or access needed]
- [Tooling limitations, e.g., browser relay/CDP restrictions]
## Sprint 1: [Sprint Name]
**Goal**: [What this sprint accomplishes]
**Demo/Validation**:
- [How to run/demo this sprint's output]
- [What to verify]
### Task 1.1: [Task Name]
- **Location**: [File paths or components involved]
- **Description**: [What needs to be done]
- **Perceived Complexity**: [1-10]
- **Dependencies**: [Any previous tasks this depends on]
- **Acceptance Criteria**:
- [Specific, testable criteria]
- **Validation**:
- [Test(s) or alternate validation steps]
### Task 1.2: [Task Name]
[...]
## Sprint 2: [Sprint Name]
[...]
## Testing Strategy
- [How to test the implementation]
- [What to verify at each sprint]
## Potential Risks
- [Things that could go wrong]
- [Mitigation strategies]
## Rollback Plan
- [How to undo changes if needed]
```
---
## Hand-off
Once plan is ready, hand off to the **parallel-task worker**:
```
Please run parallel-task.md against my-plan.md
```
Or invoke directly:
> "Run all unblocked tasks in plan.md using parallel subagents. Keep looping until all tasks are complete."
## Safety Boundaries
- Do not save a plan file unless the user asked for one or the surrounding workflow explicitly needs a persisted artifact.
- Do not assign overlapping write scopes to parallel tasks without calling out the conflict.
- Do not invent dependencies, validation steps, or completion status that the repo context does not support.
- Do not turn a planning request into implementation work unless the user explicitly asks to move from planning to implementation.
---
## Related
- [`parallel-task`](../parallel-task/) — Parallel task worker that executes the plan this skill produces
Adapted from am-will's codex-skills planner/parallel-task prompts.