/planner

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

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