abhiroopb/skills/rpi-iterate

RPI Iterate

Iteration phase of the RPI (Research, Plan, Implement) methodology. Updates existing implementation plans based on user feedback, grounded in actual codebase reality.

Initial Response

When this skill is invoked:

1. Parse the input to identify:

   • Plan file path (e.g., thoughts/shared/plans/2025-10-16-feature.md)
   • Requested changes/feedback

2. Handle different input scenarios:

   If NO plan file provided:

   I'll help you iterate on an existing implementation plan.
   
   Which plan would you like to update? Please provide the path to the plan file (e.g., `thoughts/shared/plans/2025-10-16-feature.md`).
   
   Tip: You can list recent plans with `ls -lt thoughts/shared/plans/ | head`
   

   Wait for user input, then re-check for feedback.

   If plan file provided but NO feedback:

   I've found the plan at [path]. What changes would you like to make?
   
   For example:
   - "Add a phase for migration handling"
   - "Update the success criteria to include performance tests"
   - "Adjust the scope to exclude feature X"
   - "Split Phase 2 into two separate phases"
   

   Wait for user input.

   If BOTH plan file AND feedback provided:

   • Proceed immediately to Step 1
   • No preliminary questions needed

Process Steps

Step 1: Read and Understand Current Plan

1. Read the existing plan file COMPLETELY:

   • Read entire file without truncation or partial reads
   • Understand the current structure, phases, and scope
   • Note the success criteria and implementation approach

2. Understand the requested changes:

   • Parse what the user wants to add/modify/remove
   • Identify if changes require codebase research
   • Determine scope of the update

Step 2: Research If Needed

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

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

1. Create a research checklist to track investigation tasks

2. Spawn parallel sub-agents for research:

   • Find relevant files related to the change
   • Understand implementation details of affected areas
   • Find similar patterns that inform the update
   • Be specific about directories and include full path context

3. Read any new files identified by research:

   • Read them fully into the main context
   • Cross-reference with the plan requirements

4. 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:

   • Make 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, ensure it follows the existing pattern
   • If modifying scope, update "What We're NOT Doing" section
   • If changing approach, update "Implementation Approach" section
   • Maintain the distinction between automated vs manual success criteria

3. Preserve quality standards:

   • Include specific file paths and line numbers for new content
   • Write measurable success criteria
   • Keep language clear and actionable

Step 5: Sync and Review

Present the changes made:

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

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

The updated plan now:
- [Key improvement]
- [Another improvement]

Would you like any further adjustments?

Be ready to iterate further based on feedback.

Important Guidelines

1. Be Skeptical:

   • Don't blindly accept change requests that seem problematic
   • Question vague feedback — ask for clarification
   • 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
   • Only research what's necessary for the specific changes
   • Don't over-engineer the updates

3. Be Thorough:

   • Read the entire existing plan before making changes
   • Research code patterns if changes require new technical understanding
   • Ensure updated sections maintain quality standards
   • Verify success criteria are still measurable

4. Be Interactive:

   • Confirm understanding before making changes
   • Show what you plan to change before doing it
   • Allow course corrections

5. No Open Questions:

   • If the requested change raises questions, ASK
   • Research or get clarification immediately
   • Do NOT update the plan with unresolved questions
   • Every change must be complete and actionable

Related Skills

• rpi-research — Research phase (run before planning)
• rpi-plan — Planning phase (produces plans to iterate on)
• rpi-implement — Execute an approved plan