---
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.