auto-plan
Breaks approved project specifications into actionable, ordered execution slices.
Install
mkdir -p .claude/skills/auto-plan && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/12995" && unzip -o skill.zip -d .claude/skills/auto-plan && rm skill.zipInstalls to .claude/skills/auto-plan
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Turn an approved spec into ordered slices. Use when framing is accepted and planning begins.Key capabilities
- →Load SPEC.md, DESIGN.md, and relevant source files for planning
- →Address approved_with_risks risks from product reviews in the plan
- →Preserve requirement IDs, gap IDs, invariants, and audit questions in PLAN.md
- →Break work into ordered, testable, bounded, and independent execution units
- →Attach a verification command and acceptance criteria to every material slice
- →Update state with canonical_plan and stage: plan
How it works
The skill loads approved specifications and related documents, assesses review states, and designs ordered, testable slices with verification commands, then updates the project state.
Inputs & outputs
When to use auto-plan
- →Plan project implementation
- →Slice requirements into tasks
- →Define execution order
- →Add verification commands
About this skill
auto-plan
Planning controller. Turns approved framing into ordered slices with verification commands.
First action: run node .agent/.automaton/scripts/get-context.mjs from the project root.
Preamble
auto-plan builds the smallest plan that makes execution safe while preserving the approved scope. It does not write code or broaden scope beyond the approved spec.
Loading discipline: hold SPEC.md, review state, and source files needed for accurate slices. Read wider project files when understanding existing code informs slice boundaries or verification commands. Read .agent/.automaton/references/CONTEXT-BUDGET.md when wider reads threaten context pressure. When a lookup would otherwise pull wide reads into context, dispatch the read-only automaton-librarian (see .agent/.automaton/references/LIBRARIAN.md): it returns evidence, you keep the decision.
Artifact discipline: PLAN.md is the reloadable execution index, not the whole implementation dossier. Keep PLAN.md compact enough to re-read. For large coherent work, summarize slices in PLAN.md and link optional detail files under .agent/work/<change>/slices/. Split only for independent outcomes, not because one coherent plan has many requirements.
Quality Gate
Before finalizing PLAN.md:
- Give every material slice a concrete output.
- Attach a verification command to every material slice.
- Name the execution topology: default continuation path, explicit checkpoints, subagent routes, and any parallel-safe groups.
- Remove vague tasks that do not define done.
- Read
references/quality.mdwhen the plan leaves execution decisions to the implementer.
Do
Context Loading
Load the canonical SPEC.md, linked spec detail that carries normative requirements, relevant DESIGN.md, and source files needed to choose slice boundaries, dependencies, and verification commands. Do not ignore linked spec/*.md files when they contain requirement IDs, gap IDs, invariants, audit questions, migration checkpoints, coverage targets, or acceptance detail.
Assess Review State (if reviews exist)
If engineering_review exists in current.json for this change, this is a re-plan: read ## Review: Engineering in the prior PLAN.md and address each correction and approved_with_risks risk in the revised plan. Syncing the revised plan clears the standing verdict (.agent/.automaton/references/ARTIFACT-LIFECYCLE.md, Review Verdict Routing).
If SPEC.md contains content fields or produces writing, articles, briefs, decks, newsletters, documentation, or proposals, read references/content-planning.md. Carry forward channel, source policy, factual risk, and format where they affect execution or verification.
If SPEC.md names requirement IDs, gap IDs, invariants, audit questions, migration checkpoints, or coverage targets, preserve them in PLAN.md and attach them to satisfying slices. Do not collapse traceable requirements into untraceable prose.
Design Slices
Break work into ordered execution units, not topic buckets. Each slice must be:
- Testable: it produces an outcome that can be verified.
- Bounded: it can be executed and verified without loading unrelated slices.
- Independent: it can be executed without loading slices that come after it.
- Checkpointed only for human input: it marks a pause only when a human must act or choose before the next approved slice can start.
Read references/slice-examples.md when a slice may need the subagent route, or when rendering the topology section.
For content slices, also name the artifact target, allowed sources, factual-risk gate, and format constraint so auto-execute does not invent missing context.
Before writing slices, choose the execution topology: serial order, subagent routes, checkpoints, and parallel-safe groups. Continuation is the default after a verified slice; mark a checkpoint only when the agent must pause for human verification, a human decision, or a human action. Parallel-safe means dependencies are independent and write sets are disjoint; default to none. For multi-slice plans, make clear that execution should continue through all approved slices; execution windows are context-management batches, not planned stopping points.
Frame each slice with required fields first, then only the overrides the slice needs:
### Slice N: [Name]
Required:
**Objective:** [one sentence]
**Acceptance criteria:**
- [observable criterion]
**Verification:** [command or check that proves the slice is done]
Defaults, state only when overriding:
**Execution:** direct | subagent recommended | subagent required (default: direct)
**Depends on:** none
**Checkpoint after:** none | human-verify | decision | human-action (default: none)
**Checkpoint reason:** none
Include when useful:
**Touches:** [files, directories, or subsystems]
**Produces:** [specific artifact or state change]
**Detail:** [linked `slices/slice-NNN.md` file]
Rules:
- Every material slice must have a verification command. Verify the exact behavior, not the absence of errors. Include rollback verification for migrations.
- Every material slice must have acceptance criteria. Execution cannot verify vibes.
- Use
subagent recommendedfor broad, cross-subsystem, interface, schema, or review-risk work. Usesubagent requiredonly for user-requested multi-agent execution or security-critical, production-data, or irreversible-state changes. - Continuation is the default. Omitted slice fields carry the defaults pinned in
.agent/.automaton/references/ARTIFACT-LIFECYCLE.md(Slice Defaults). - Checkpoint types are defined once in
.agent/.automaton/references/ARTIFACT-LIFECYCLE.md(Checkpoint Semantics). Assign a checkpoint only when its definition holds; default tonone. - Keep slices small enough for one session. Move extended instructions to
slices/slice-NNN.md. Split only for independent outcomes.
Do NOT write PLAN.md if:
- SPEC.md is missing or unreadable.
- The scope is still ambiguous after reading SPEC.md.
If any of these are true, recommend auto-frame and stop.
</GATE>
Write PLAN.md
Write the plan to .agent/work/<change>/PLAN.md.
Core sections (always present):
- Goal: one-line bounded goal or SPEC.md pointer. Do not mirror the full SPEC text.
- Ordered slice sequence: dependency order, with linked detail files when needed.
- Execution routing and topology: default continuation path, explicit overrides/checkpoints, and a Parallel-safe groups: line set to
noneor the slice groups. - Per-slice verification: one verification command inline on every material slice.
Conditional sections appear only when their trigger applies. Omit when the trigger does not apply:
- Architecture approach: introduces a new pattern, non-obvious decision, or cross-system integration. Name the contestable decisions and their tradeoffs plainly; a review can only bite what the plan states. Omit when the design is obvious from SPEC.
- Requirement traceability: SPEC names gap IDs, invariant IDs, audit questions, migration checkpoints, or coverage targets. Omit when the SPEC has no traceable IDs.
- Aggregate verification commands table: ≥ 3 slices or commands not captured per-slice. Per-slice inline suffices for smaller plans (index over transcript).
Apply the Artifact Signal Discipline rules from .agent/.automaton/references/FRAMEWORK.md while writing. Preserve existing ## Review: sections on re-run unless the user explicitly requests consolidation. Review skills replace their own sections.
Write DESIGN.md (if it earns existence)
Write .agent/work/<change>/DESIGN.md only when all three hold: the decision is hard to reverse, a future reader would be surprised without context, and it resolved a real trade-off between genuine alternatives. Any one missing means the rationale lives in PLAN.md prose. Keep it under 200 lines so it stays a reloadable contract rather than a dossier.
Update State
Run node .agent/.automaton/scripts/sync-status.mjs --canonical-plan ".agent/work/<change>/PLAN.md" --stage plan from the project root. Add --canonical-design ".agent/work/<change>/DESIGN.md" when DESIGN.md was written.
Hand Off
Planning always stops. The edge's why: .agent/.automaton/references/ARTIFACT-LIFECYCLE.md (Handoff Contract).
Report the slice count, the execution topology, and any checkpoint. Then end the turn with **Next:** auto-execute, <reason>, or **Next:** auto-eng-review, <reason> when the plan carries non-trivial engineering risk.
Output
PLAN.md: written to.agent/work/<change>/PLAN.mdDESIGN.md: written to.agent/work/<change>/DESIGN.md(if needed).agent/.automaton/state/current.json: recordscanonical_design(when written),canonical_plan, andstage: planthroughsync-status.mjs
Rules
- Do not add slices the approved SPEC does not call for. Scope questions return to
auto-frame; planning never expands scope.
When not to use it
- →When SPEC.md is missing or unreadable
- →When product_review is descoped or needs_clarification
- →When the scope is still ambiguous after reading SPEC.md
Limitations
- →Does not write code
- →Does not broaden scope beyond the approved spec
- →Does not write PLAN.md if SPEC.md is missing or unreadable
How it compares
This skill systematically structures an approved spec into concrete, verifiable execution slices with explicit dependencies and checkpoints, which is more structured than ad-hoc task breakdown.
Compared to similar skills
auto-plan side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| auto-plan (this skill) | 0 | 2mo | No flags | Advanced |
| create-plan | 36 | 8mo | Review | Beginner |
| project-planner | 32 | 9mo | Review | Intermediate |
| system-design | 19 | 9mo | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by appautomaton
View all by appautomaton →You might also like
create-plan
antinomyhq
Generate detailed implementation plans for complex tasks. Creates comprehensive strategic plans in Markdown format with objectives, step-by-step implementation tasks using checkbox format, verification criteria, risk assessments, and alternative approaches. Use when users need thorough analysis and structured planning before implementation, when breaking down complex features into actionable steps, or when they explicitly ask for a plan, roadmap, or strategy. Strictly planning-focused with no code modifications.
project-planner
adrianpuiu
Comprehensive project planning and documentation generator for software projects. Creates structured requirements documents, system design documents, and task breakdown plans with implementation tracking. Use when starting a new project, defining specifications, creating technical designs, or breaking down complex systems into implementable tasks. Supports user story format, acceptance criteria, component design, API specifications, and hierarchical task decomposition with requirement traceability.
system-design
lagz0ne
Use when designing, architecting, or planning a new system from requirements or ideas - transforms concepts into navigable design catalog using EventStorming methodology, Mermaid diagrams, and progressive elaboration through 5 phases (Requirements, Big Picture, Processes, Data/Flows, Integration)
spec-kit-workflow
jmanhype
Guides specification-driven development workflow. Automatically invoked when discussing new features, specifications, technical planning, or implementation tasks. Ensures proper workflow phases (specify → clarify → plan → checklist → tasks → analyze → implement).
sparc-methodology
ruvnet
SPARC (Specification, Pseudocode, Architecture, Refinement, Completion) comprehensive development methodology with multi-agent orchestration
spec-workflow
TencentCloudBase
Standard software engineering workflow for requirement analysis, technical design, and task planning. Use this skill when developing new features, complex architecture designs, multi-module integrations, or projects involving database/UI design.