iterate-plan
Update existing implementation plans based on feedback or changed requirements. **ALWAYS use when** the user says 'update the plan', 'change the plan', 'the requirements changed', 'revise the approach', or wants to modify an existing plan in thoughts/shared/plans/ after review feedback or discovered issues.
Best use case
iterate-plan is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Update existing implementation plans based on feedback or changed requirements. **ALWAYS use when** the user says 'update the plan', 'change the plan', 'the requirements changed', 'revise the approach', or wants to modify an existing plan in thoughts/shared/plans/ after review feedback or discovered issues.
Teams using iterate-plan should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/iterate-plan/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How iterate-plan Compares
| Feature / Agent | iterate-plan | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Update existing implementation plans based on feedback or changed requirements. **ALWAYS use when** the user says 'update the plan', 'change the plan', 'the requirements changed', 'revise the approach', or wants to modify an existing plan in thoughts/shared/plans/ after review feedback or discovered issues.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Iterate Plan
You are tasked with updating an existing implementation plan based on user feedback,
partial implementation results, or changed requirements. You update plans with
research-backed modifications, not just text edits.
## Prerequisites
```bash
# Check project setup (thoughts, CLAUDE.md snippet, config)
if [[ -f "${CLAUDE_PLUGIN_ROOT}/scripts/check-project-setup.sh" ]]; then
"${CLAUDE_PLUGIN_ROOT}/scripts/check-project-setup.sh" || exit 1
fi
# Auto-discover most recent plan (workflow context + filesystem fallback)
RECENT_PLAN=""
if [[ -f "${CLAUDE_PLUGIN_ROOT}/scripts/workflow-context.sh" ]]; then
RECENT_PLAN=$("${CLAUDE_PLUGIN_ROOT}/scripts/workflow-context.sh" recent plans)
fi
if [[ -n "$RECENT_PLAN" ]]; then
echo "📋 Auto-discovered recent plan: $RECENT_PLAN"
else
echo "⚠️ No recent plan found in workflow context or filesystem"
fi
```
## Initial Response
Auto-discovery has already run in Prerequisites above. Check its output and follow this priority:
1. **If user provided a plan file path**: Use the provided path (user override). Read it FULLY immediately.
2. **If no path provided AND Prerequisites discovered a plan (📋)**: Show the path and ask "**Update this plan?** [Y/n]"
3. **If no path AND no plan found (⚠️)**: Ask user to provide the plan file path
Then ask: "What changes need to be made to this plan?"
## Process Steps
### Step 1: Read and Understand the Existing Plan
1. Read the plan document FULLY (no limit/offset)
2. Identify all phases, success criteria, and current completion state
3. Note which phases are already completed vs pending
4. Understand the overall architecture and approach
### Step 2: Understand the Requested Changes
Parse the user's feedback:
- **Scope changes**: Adding/removing phases or features
- **Technical corrections**: Wrong approach, better alternative discovered
- **Feedback from review**: Reviewer comments on the plan
- **Partial implementation learnings**: Things discovered during implementation
- **Requirement changes**: Business requirements shifted
### Step 3: Research If Needed
If the changes require new technical understanding:
1. Spawn parallel sub-agents to research the codebase:
- **codebase-locator** to find relevant files
- **codebase-analyzer** to understand current implementation
- **codebase-pattern-finder** to find similar patterns
2. Wait for ALL agents to complete before modifying the plan
3. Present research findings to user before making changes:
```
Based on my research:
- [Finding 1 with file:line reference]
- [Finding 2 with file:line reference]
This affects the plan in these ways:
- [Impact 1]
- [Impact 2]
Shall I proceed with these updates?
```
### Step 4: Update the Plan
1. Preserve completed phases unchanged (unless explicitly asked to modify)
2. Update pending phases with new information
3. Add new phases if scope expanded
4. Remove phases if scope narrowed
5. Update success criteria to reflect changes
6. Add an "Iteration History" section at the bottom:
```markdown
## Iteration History
### Iteration 1 - YYYY-MM-DD
**Reason**: [Why the plan was updated]
**Changes**:
- [Phase X]: [What changed and why]
- [Phase Y]: [Added/removed/modified]
**Research conducted**: [[research-doc-filename]] — [Brief summary, if any]
```
### Step 5: Save and Sync
1. Save the updated plan (overwrite the existing file)
2. Sync thoughts: `humanlayer thoughts sync`
### Step 6: Present Summary
```
Plan updated!
**Plan**: [file path]
**Changes made**:
- [Summary of each change]
**Impact on implementation**:
- Phases affected: [list]
- New phases added: [list, if any]
- Phases removed: [list, if any]
Please review the updated plan.
```
## Important Guidelines
1. **Research before modifying** — Don't just edit text; verify changes against the codebase
2. **Preserve completed work** — Never modify phases marked as done unless explicitly asked
3. **Update success criteria** — Every plan change must have corresponding criteria updates
4. **Track iterations** — Always add to the Iteration History section
5. **Read fully** — Always read the entire plan before making changes
6. **No open questions** — Resolve all uncertainties before saving
**IMPORTANT: Document Storage Rules**
- ALWAYS write to `thoughts/shared/plans/` for plan documents
- NEVER write to `thoughts/searchable/` — this is a read-only search indexRelated Skills
weekly-plan
Set next week's priorities
daily-plan
Generate PM daily plan with context
validate-plan
Validate that implementation plans were correctly executed. **ALWAYS use when** the user says 'validate the plan', 'check if the plan was implemented correctly', 'verify the implementation', or after completing /implement-plan to confirm all phases were properly executed and success criteria met.
phase-plan
Phase agent for the plan step of the 9-phase orchestrator pipeline (CTL-450). Wraps /catalyst-dev:create-plan and produces thoughts/shared/plans/<date>-<ticket>.md, then emits phase.plan.complete.<ticket>. Reads the prior research document from thoughts/shared/research/ as its prior-phase artifact. Spawned via plugins/dev/scripts/phase-agent-dispatch, which invokes it via slash command — hence `user-invocable: true`.
implement-plan
Implement approved technical plans from thoughts/shared/plans/. **ALWAYS use when** the user says 'implement the plan', 'start implementing', 'build from the plan', or wants to execute a previously created implementation plan using TDD (Red-Green-Refactor). Supports team mode for parallel implementation.
create-plan
Create detailed implementation plans through an interactive process. **ALWAYS use when** the user says 'plan this', 'create a plan', 'let's plan the implementation', 'design the approach', or wants a structured TDD implementation plan before writing code. Works best after /research-codebase.
write-prod-strategy
Product strategy docs using 7-component framework
strategy-sprint
Create product strategy in 1 day, 1 week, or 1 month timeframes. Progressive strategy development framework.
ralph-wiggum
Devil's advocate PRD/document reviewer with humor and sharp critique
prioritize
Classify PM tasks using LNO Framework (Leverage/Neutral/Overhead) to focus on high-impact work.
prd-review-panel
Multi-agent PRD review (7 perspectives)
prd-draft
Create a PRD (product requirements document) for features and initiatives. Guides through clarifying questions, generates a structured draft with hypothesis, strategic fit, non-goals, success metrics, and rollout plan, then offers multi-agent review. Use when the user asks to create a PRD, product spec, feature spec, requirements doc, or product brief.