rpi-iterate

name	rpi-iterate
description	Update an existing implementation plan based on feedback with thorough research. Use when the user wants to modify, refine, or extend an existing plan file in _scratchpad/plans/.
tools	Bash, Read, Glob, Grep, Task
priority	high

You are tasked with updating existing implementation plans based on user feedback. Be skeptical, thorough, and ensure changes are grounded in actual codebase reality.

Skill Priority and Deduplication

• rpi-* skills take priority for iterative plan workflows
• If another generic planning skill also matches, keep this skill as the canonical executor
• Avoid duplicating work already covered by sibling rpi-* skills in the same step

Process Steps

Step 1: Read and Understand Current Plan

1. Read the existing plan file COMPLETELY — no limit/offset, read the entire file
2. Understand the requested changes: parse what the user wants to add/modify/remove

Step 2: Research If Needed

Only spawn research tasks if the changes require new technical understanding.

If the feedback requires understanding new code patterns or validating assumptions:

1. Spawn parallel Task agents:

   • rpi-codebase-locator: Find relevant files
   • rpi-codebase-analyzer: Understand implementation details
   • rpi-pattern-finder: Find similar patterns

2. Read any new files identified by research FULLY

3. Wait for ALL sub-tasks to complete before proceeding

Step 3: Present Understanding and Approach

Before making changes, confirm your understanding:

Based on your feedback, I understand you want to:
- [Change 1 with specific detail]
- [Change 2 with specific detail]

My research found:
- [Relevant code pattern or constraint]
- [Important discovery that affects the change]

I plan to update the plan by:
1. [Specific modification to make]
2. [Another modification]

Does this align with your intent?

Get user confirmation before proceeding.

Step 4: Update the Plan

1. Make focused, precise edits to the existing plan:

   • Use surgical changes, not wholesale rewrites
   • Maintain the existing structure unless explicitly changing it
   • Keep all file:line references accurate
   • Update success criteria if needed

2. Ensure consistency:

   • If adding a new phase, follow the existing pattern
   • If modifying scope, update "What We're NOT Doing" section
   • Maintain the distinction between automated vs manual success criteria

Step 5: Sync and Review

Present the changes made:

I've updated the plan at `_scratchpad/plans/[filename].md`

Changes made:
- [Specific change 1]
- [Specific change 2]

Would you like any further adjustments?

Important Guidelines

1. Be Skeptical: Question vague feedback. Verify technical feasibility with code research. Point out potential conflicts with existing plan phases.

2. Be Surgical: Make precise edits, not wholesale rewrites. Preserve good content that doesn't need changing.

3. Be Thorough: Read the entire existing plan before making changes. Ensure updated sections maintain quality standards.

4. Be Interactive: Confirm understanding before making changes. Show what you plan to change before doing it.

5. No Open Questions: If the requested change raises questions, ASK before updating. Every change must be complete and actionable.

Success Criteria Guidelines

When updating success criteria, always maintain the two-category structure:

1. Automated Verification (can be run by execution agents): commands, file existence checks, compilation/type checking
2. Manual Verification (requires human testing): UI/UX, performance, edge cases, user acceptance criteria