Plan
Turn a fuzzy feature or epic into a verification-backed task list your coding agent can execute without losing scope across long sessions.
Overview
Plan is an agent skill most often used in Build (PM) (also Validate scope, Ship launch) that decomposes complex work into verification-driven tasks with optional Sibyl tracking.
Install
npx skills add https://github.com/hyperb1iss/hyperskills --skill planWhat is this skill?
- Five-phase rhythm: SCOPE → EXPLORE → DECOMPOSE → VERIFY & APPROVE → TRACK (not a rigid checklist—compress or skip when w
- Verification-driven decomposition: each step must land in concrete checks so plans survive contact with the repo
- Sibyl-native tracking so plans persist beyond the context window that wrote them
- Explicit replanning as normal; first plan is a hypothesis, not a contract
- Activates on natural language: write a plan, break this down, implementation plan, spec this out, decompose this feature
- Five named planning phases: SCOPE, EXPLORE, DECOMPOSE, VERIFY & APPROVE, TRACK
- Methodology mined from 200+ real planning sessions
Adoption & trust: 559 installs on skills.sh; 13 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You know what you want built, but your agent keeps executing vague bullets that drift from scope and cannot be checked as you go.
Who is it for?
Multi-day features, refactors, or integrations where you want agent-readable tasks with pass/fail checks before any implementation pass.
Skip if: Obvious one-file fixes, chores with a single clear diff, or work that already has a signed-off spec and ordered ticket list—just implement.
When should I use this skill?
Decomposing complex work into structured tasks before implementation—mentions of write a plan, create a plan, break this down, task decomposition, implementation plan, what are the steps, plan the work, spec this out, or
What do I get? / Deliverables
You get an approved, stepwise implementation plan with explicit verification hooks and durable tracking so coding can start without silent scope creep.
- Scoped, decomposed task list with verification hooks
- Approved plan snapshot suitable for agent execution and replanning
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build → PM because decomposition happens immediately before implementation, when work must become ordered, checkable tasks. PM subphase covers specs, backlogs, and implementation plans—not shipping code yet, but making the next build steps honest and measurable.
Where it fits
Slice an MVP feature into verifiable milestones before you commit to a two-week build.
Decompose a cross-service change into ordered tasks each with a concrete check before the agent edits multiple packages.
Plan webhook and idempotency work with explicit verification steps before touching production-adjacent code.
Break release prep into checkable launch tasks instead of a single scary 'ship it' prompt.
How it compares
Use instead of dumping a markdown todo list into chat without scope boundaries, exploration notes, or verification criteria.
Common Questions / FAQ
Who is plan for?
Solo and indie builders using Claude Code, Cursor, Codex, or similar agents who need durable, verifiable task breakdowns before and during implementation.
When should I use plan?
Use it when you mention writing a plan, breaking down a feature, or spec’ing steps—especially in Validate when scoping an MVP, in Build before PM-heavy work, and in Ship when launch prep needs ordered, checkable tasks.
Is plan safe to install?
Review the Security Audits panel on this Prism page for install risk and file integrity; the skill is procedural planning guidance and does not require shell or network by default.
SKILL.md
READMESKILL.md - Plan
# Structured Planning Verification-driven task decomposition with Sibyl-native tracking. Mined from 200+ real planning sessions: the plans that actually survived contact with code. **Core insight:** Plans fail when steps can't be verified. Decomposition that lands in concrete checks survives contact with reality; abstract bullets don't. Tracking in Sibyl lets plans outlive the context window that produced them. **How to read this skill:** the phases below describe the rhythm of a useful planning pass, not a procedure to march through. Skip planning entirely for small clear work, compress phases when the answers are obvious, and treat the first plan as a hypothesis. Replanning is the rule, not the exception. ## The Shape ```dot digraph planning { rankdir=TB; node [shape=box]; "1. SCOPE" [style=filled, fillcolor="#e8e8ff"]; "2. EXPLORE" [style=filled, fillcolor="#ffe8e8"]; "3. DECOMPOSE" [style=filled, fillcolor="#e8ffe8"]; "4. VERIFY & APPROVE" [style=filled, fillcolor="#fff8e0"]; "5. TRACK" [style=filled, fillcolor="#e8e8ff"]; "1. SCOPE" -> "2. EXPLORE"; "2. EXPLORE" -> "3. DECOMPOSE"; "3. DECOMPOSE" -> "4. VERIFY & APPROVE"; "4. VERIFY & APPROVE" -> "5. TRACK"; "4. VERIFY & APPROVE" -> "3. DECOMPOSE" [label="gaps found", style=dashed]; } ``` --- ## Phase 1: SCOPE Bound the work before decomposing it. The goal is calibrating planning depth to actual scope, not generating a deliverable. ### Common moves - **Search Sibyl** for related tasks, decisions, and prior plans: `sibyl search "<feature keywords>"`, `sibyl task list -s todo`. Cheap and often surfaces an already-decomposed predecessor. - **Define success criteria** in measurable terms ("tests pass", "endpoint returns X", "p95 latency < 200ms") instead of vague goals like "improve performance". - **Identify constraints**: files that shouldn't change, dependencies to respect, timeline or budget pressure. - **Calibrate planning depth** to scope: | Scale | Description | Planning depth | | ------------- | -------------------------- | -------------------------- | | **Quick fix** | < 3 files, clear solution | Skip planning, go build | | **Feature** | 3-10 files, known patterns | Light plan (this skill) | | **Epic** | 10+ files, new patterns | Full plan + orchestration | | **Redesign** | Architecture change | Full plan + research first | If the work is a quick fix, stop planning and go build. Planning a five-minute change is pure overhead. --- ## Phase 2: EXPLORE Understand the codebase surface before decomposing it. Plans built from filenames alone fall apart at contact with the actual code. ### Common moves - **Map the impact surface**: which files and modules will this touch? Read the actual code rather than guessing from names; spawn an Explore agent when scope is genuinely uncertain. - **Identify existing patterns**: how does similar functionality already work? What conventions apply (naming, file structure, test patterns)? - **Trace dependencies**: what must exist before this can work, and what breaks if we change X? You're aiming for a mental model you can articulate: "this touches module A (new endpoint), module B (type changes), module C (tests); pattern follows existing feature X; depends on infrastructure Y being available." If you can't write that sentence, decomposition will rest on guesses. --- ## Phase 3: DECOMPOSE Break the work into steps you can actually verify. The discipline that separates plans-that-survive from plans-that-fail is connecting each step to a concrete check. ### Measure twice: look for the reframe f