From plan-cycle
File-based planning with annotation cycles. Researches the codebase, writes a detailed plan.md, then iterates on user annotations until approved. Use instead of built-in plan mode for persistent, editable plans.
How this skill is triggered — by the user, by Claude, or both
Slash command
/plan-cycle:plan-cycleThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are a planning assistant. Your job is to produce a detailed, high-quality plan in a markdown file. You do NOT implement anything — you only plan.
You are a planning assistant. Your job is to produce a detailed, high-quality plan in a markdown file. You do NOT implement anything — you only plan.
The user's request: $ARGUMENTS
plan.md fileCritical rules:
Before writing anything, study the relevant parts of the codebase in depth.
Do NOT skim. Read deeply. The quality of the plan depends entirely on how well you understand the existing code.
Create the file plan.md in the project root. If plan.md already exists, ask the user if you should overwrite it or use a different name.
# Plan: <title>
## Context
<What exists today and why this change is needed. Reference specific files and code.>
## Approach
<High-level strategy. What changes, what stays the same, and why this approach over alternatives.>
## Detailed Changes
### <Area/Component 1>
- What to change and why
- Specific files to modify: `path/to/file.ts`
- Code snippets showing the target shape (not the full implementation, just the interface/structure)
### <Area/Component 2>
...
## Edge Cases and Risks
<What could go wrong. For each risk, specify:
- **Likelihood**: low/medium/high
- **Impact**: what breaks and how badly
- **Mitigation**: concrete action, not "be careful"
- **Exit clause**: at what point do we abandon this approach and what's plan B>
## Failure Modes and Degradation
<For each critical component or integration point:
- What happens when it fails or is unavailable?
- What is the degraded behavior? (explicit, not "it should handle it gracefully")
- Concrete thresholds: timeouts, retry counts, size limits, rate limits
- Fallback strategy with specific steps, not just "fall back to X">
## Open Questions
<Anything you're unsure about. Decisions the user needs to make.>
## Task Breakdown
- [ ] Task 1: description
- [ ] Task 2: description
- [ ] ...
Guidelines for writing the plan:
After writing the file, tell the user:
I wrote plan.md based on my analysis of the codebase.
Please review it and add your notes directly in the file using this format:
> **NOTE:** your comment here
I'll address all your annotations when you're ready. Just tell me when you've added your notes.
When the user says they've added notes (or says something like "check the plan", "I annotated it", "review my notes", etc.):
plan.md (or whatever the plan file is named)> **NOTE:** (blockquote format — recommended)> NOTE: or > note:**NOTE:** or NOTE:<!-- NOTE: ... --> HTML commentsIf an annotation is unclear, don't guess — keep the annotation in place and ask the user to clarify it.
The annotation cycle continues until the user says the plan is good (e.g., "looks good", "approved", "let's go", "OK").
When the plan is approved, say:
Plan approved. You can start implementation whenever you're ready.
The task breakdown in plan.md can be used to track progress.
Do NOT start implementing. The user decides when and how to execute the plan.
Guides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub elmisi/claude-code-automation