Create structured plans for multi-task projects that can be
Planner

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.
---
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 StartOverview
Create structured, orchestrator-ready plans for multi-task projects.
Manual install (npx, ZIP)
npx skills add jdrhyne/agent-skills --skill planner -g -a claude-codemkdir -p ~/.claude/skills && curl -sL https://codeload.github.com/jdrhyne/agent-skills/tar.gz/439cd3a9da78 \
| tar -xz -C ~/.claude/skills --strip-components=2 agent-skills-439cd3a9da78/skills/plannerNew-Item -ItemType Directory -Force "$HOME\.claude\skills" | Out-Null; Invoke-WebRequest "https://m.agentalley.io/zip/ae207e8d3b3122603495/planner.zip" -OutFile "$env:TEMP\planner.zip"; Expand-Archive "$env:TEMP\planner.zip" -DestinationPath "$HOME\.claude\skills" -ForceConnects with Agent Alley MCP · agentalley.io/mcp
Files included
SKILL.md3.7 KB
Read the files here
jdrhyne/
Shared references1SKILL.md reads these from elsewhere in the repo. Not in the ZIP.
Get them on GitHub ↗Show the full text135 lines
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:
- Phase 0: Clarify requirements (ask up to 5 targeted questions)
- Phase 1: Research & understand the codebase
- Phase 2: Create detailed plan with sprints, tasks, acceptance criteria
- Phase 3: Subagent review of the plan
- 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 worker that executes the plan this skill produces
Adapted from am-will's codex-skills planner/parallel-task prompts.
| 1 | |
| 2 | name planner |
| 3 | 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. |
| 4 | metadata {"clawdbot":{"emoji":"📋"}} |
| 5 | permissions |
| 6 | - file_write: "May save the completed plan to a file when the user asks for a persisted artifact." |
| 7 | |
| 8 | |
| 9 | # Planner |
| 10 | |
| 11 | Create structured, orchestrator-ready plans for multi-task projects. |
| 12 | |
| 13 | **Source**: Adapted from am-will's codex-skills workflow patterns |
| 14 | **Pairs with**: task-orchestrator skill for follow-on implementation |
| 15 | |
| 16 | |
| 17 | |
| 18 | ## Quick Start |
| 19 | |
| 20 | Follow this process: |
| 21 | |
| 22 | **Phase 0**: Clarify requirements (ask up to 5 targeted questions) |
| 23 | **Phase 1**: Research & understand the codebase |
| 24 | **Phase 2**: Create detailed plan with sprints, tasks, acceptance criteria |
| 25 | **Phase 3**: Subagent review of the plan |
| 26 | **Phase 4**: Return the plan in markdown and save a file only if the user asked for a persisted artifact |
| 27 | |
| 28 | |
| 29 | |
| 30 | ## Key Principles |
| 31 | |
| 32 | ### Task Atomicity |
| 33 | Each task must be: |
| 34 | **Atomic and committable** — small, independent pieces of work |
| 35 | **Specific and actionable** — not vague |
| 36 | **Testable** — include tests or validation method |
| 37 | **Located** — include file paths and code locations |
| 38 | |
| 39 | ### Bad vs Good Task Breakdown |
| 40 | |
| 41 | ❌ Bad: "Implement third-party sign-in" |
| 42 | |
| 43 | ✓ Good: |
| 44 | "Add sign-in config to environment variables" |
| 45 | "Install and configure the required authentication package" |
| 46 | "Create sign-in callback route handler in src/routes/auth.ts" |
| 47 | "Add the sign-in button to the login UI" |
| 48 | |
| 49 | ### Sprint Structure |
| 50 | |
| 51 | Each sprint must: |
| 52 | Result in a **demoable, runnable, testable** increment |
| 53 | Build on prior sprint work |
| 54 | Include clear demo/verification checklist |
| 55 | |
| 56 | |
| 57 | |
| 58 | ## Plan Template |
| 59 | |
| 60 | |
| 61 | # Plan: [Task Name] |
| 62 | |
| 63 | **Generated**: [Date] |
| 64 | **Estimated Complexity**: [Low/Medium/High] |
| 65 | |
| 66 | ## Overview |
| 67 | [Brief summary of what needs to be done and the general approach] |
| 68 | |
| 69 | ## Prerequisites |
| 70 | - [Dependencies or requirements that must be met first] |
| 71 | - [Tools, libraries, or access needed] |
| 72 | - [Tooling limitations, e.g., browser relay/CDP restrictions] |
| 73 | |
| 74 | ## Sprint 1: [Sprint Name] |
| 75 | **Goal**: [What this sprint accomplishes] |
| 76 | **Demo/Validation**: |
| 77 | - [How to run/demo this sprint's output] |
| 78 | - [What to verify] |
| 79 | |
| 80 | ### Task 1.1: [Task Name] |
| 81 | - **Location**: [File paths or components involved] |
| 82 | - **Description**: [What needs to be done] |
| 83 | - **Perceived Complexity**: [1-10] |
| 84 | - **Dependencies**: [Any previous tasks this depends on] |
| 85 | - **Acceptance Criteria**: |
| 86 | - [Specific, testable criteria] |
| 87 | - **Validation**: |
| 88 | - [Test(s) or alternate validation steps] |
| 89 | |
| 90 | ### Task 1.2: [Task Name] |
| 91 | [...] |
| 92 | |
| 93 | ## Sprint 2: [Sprint Name] |
| 94 | [...] |
| 95 | |
| 96 | ## Testing Strategy |
| 97 | - [How to test the implementation] |
| 98 | - [What to verify at each sprint] |
| 99 | |
| 100 | ## Potential Risks |
| 101 | - [Things that could go wrong] |
| 102 | - [Mitigation strategies] |
| 103 | |
| 104 | ## Rollback Plan |
| 105 | - [How to undo changes if needed] |
| 106 | |
| 107 | |
| 108 | |
| 109 | |
| 110 | ## Hand-off |
| 111 | |
| 112 | Once plan is ready, hand off to the **parallel-task worker**: |
| 113 | |
| 114 | |
| 115 | Please run parallel-task.md against my-plan.md |
| 116 | |
| 117 | |
| 118 | Or invoke directly: |
| 119 | > "Run all unblocked tasks in plan.md using parallel subagents. Keep looping until all tasks are complete." |
| 120 | |
| 121 | ## Safety Boundaries |
| 122 | |
| 123 | Do not save a plan file unless the user asked for one or the surrounding workflow explicitly needs a persisted artifact. |
| 124 | Do not assign overlapping write scopes to parallel tasks without calling out the conflict. |
| 125 | Do not invent dependencies, validation steps, or completion status that the repo context does not support. |
| 126 | Do not turn a planning request into implementation work unless the user explicitly asks to move from planning to implementation. |
| 127 | |
| 128 | |
| 129 | |
| 130 | ## Related |
| 131 | |
| 132 | [`parallel-task`] — Parallel task worker that executes the plan this skill produces |
| 133 | |
| 134 | Adapted from am-will's codex-skills planner/parallel-task prompts. |
| 135 |
Details
- Updated
- Aug 30, 2026
- License
- MIT
- Stars on the repo
- ★ 240
- Checked
- Source
- jdrhyne/agent-skills ↗
- Creator
- jdrhyne · 24 listings
Similar skills
See all →
SkillReverse engineer native, managed, Electron/JavaScriptREA
SkillBrainstorms ideas into designs before any creative workBrainstorming Ideas Into Designs
SkillRequires technical rigor and verificationCode Review Reception
SkillDiagnosis loop for hard bugs and performance regressionsDiagnosing bugs
SkillImplement the result of /to-spec and /to-tickets in codeImplement spec
SkillWriting a PR bodyMore from jdrhyne
SkillRun Codex CLI or references OpenAI Codex for code analysisCodex Skill Guide
SkillCreating a Claude Code slash commandCommand creator
SkillRecover missing conversation context after explicitContext recovery
SkillGenerate beautifully designed PDF reportsElegant reports
SkillRead Google Analytics 4 reporting data through the GA4 DataGA4 Data API
SkillBulk download images from login-protected gallery websitesGallery scraper