Agent-skills 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.
install
source · Clone the upstream repo
git clone https://github.com/jdrhyne/agent-skills
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/jdrhyne/agent-skills "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/planner" ~/.claude/skills/jdrhyne-agent-skills-planner && rm -rf "$T"
manifest:
skills/planner/SKILL.mdsource content
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
Load the full planner prompt from
prompts/planner.md and follow its 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.
Files
— Full planner agent promptprompts/planner.md
— Parallel task worker promptprompts/parallel-task.md
Both are based on am-will's codex-skills prompts.