Planner
Create structured plans for multi-task projects that can be used by the task-orchestrator skill.
How to use it
Claude Code
- Run the line below. It pulls the whole folder into
~/.claude/skills/planner, including the files SKILL.md points to. - Describe your job in plain words. Claude Code follows the skill from there.
npx degit jdrhyne/agent-skills/skills/planner#main ~/.claude/skills/plannerFor one project only, change the path to .claude/skills/planner. This skill also uses parallel-task.md, my-plan.md, plan.md — copying SKILL.md alone won't be enough. See the folder on GitHub.
Claude (web or desktop app)
- On this page open ⋯ → Download .md.
- Save it as SKILL.md in a folder, zip the folder, then Customize → Skills → + → Create skill → Upload a skill.
- Pick the file and Save. Claude shows the name and description and runs a security scan.
- Check the skill is switched on.
- Start a new chat and describe your job in plain words. The AI follows the skill from there.
ChatGPT or another app
- ChatGPT: make a Project and paste it into Instructions.
- Neither? Paste it at the top of a new chat — it works for that chat.
Not working?
- Check which app you pasted it into — the steps above name the right one.
- Some skills need the paid tier of Claude or ChatGPT.
Paste into Claude, ChatGPT or Cursor.
Source of Planner
Show the full text135 lines
| name | description | metadata | permissions |
|---|---|---|---|
| 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. | {"clawdbot":{"emoji":"📋"}} | - 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:
- 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 |
Discussion
Browse more free Claude skills.