--- description: Iterate on existing implementation plans for a bead issue model: opus --- # Beads Iterate You are tasked with updating existing implementation plans based on feedback. Plans are stored in `thoughts/beads-{id}/plan.md`. ## Initial Setup When this command is invoked: 1. **Parse the input**: - Bead ID (required or ask for it) - Requested changes/feedback (can be provided with command or after) 2. **Handle different scenarios**: **No bead ID provided**: ``` Which bead's plan would you like to iterate on? Recent beads with plans: {list beads that have thoughts/beads-{id}/plan.md} ``` **Bead ID but no feedback**: ``` I've found the plan at thoughts/beads-{bead-id}/plan.md What changes would you like to make? For example: - "Add a phase for migration handling" - "Update success criteria to include performance tests" - "Adjust scope to exclude feature X" - "Split Phase 2 into two separate phases" ``` **Both bead ID and feedback provided**: - Proceed immediately to Step 1 ## Iteration Process ### Step 1: Understand Current Plan 1. **Read the existing plan COMPLETELY**: ```bash cat thoughts/beads-{bead-id}/plan.md ``` - Understand current structure, phases, scope - Note success criteria and approach 2. **Read the bead for context**: ```bash bd show {bead-id} ``` 3. **Understand requested changes**: - Parse what user wants to add/modify/remove - Identify if changes require codebase research ### Step 2: Research If Needed **Only if changes require new technical understanding:** 1. **Spawn parallel research tasks**: - **codebase-locator**: Find relevant files - **codebase-analyzer**: Understand implementation details - **codebase-pattern-finder**: Find similar patterns 2. **Be specific about directories** in prompts 3. **Wait for ALL tasks** before proceeding ### Step 3: Present Understanding Before making changes: ``` Based on your feedback, I understand you want to: - {Change 1 with specific detail} - {Change 2 with specific detail} {If research was needed:} My research found: - {Relevant discovery} - {Important constraint} I plan to update the plan by: 1. {Specific modification} 2. {Another modification} Does this align with your intent? ``` Get user confirmation before proceeding. ### Step 4: Update the Plan 1. **Make focused, precise edits**: - Use Edit tool for surgical changes - Maintain existing structure unless explicitly changing it - Keep file:line references accurate 2. **Ensure consistency**: - New phases follow existing pattern - Update "What We're NOT Doing" if scope changes - Maintain automated vs manual success criteria distinction 3. **Update plan metadata**: - Update frontmatter `date` to current timestamp - Add `iteration: {N}` to frontmatter - Add `iteration_reason: "{brief description}"` to frontmatter 4. **Preserve completed work**: - Don't uncheck items that were already completed - If changing completed phases, discuss with user first ### Step 5: Save Iteration History (Optional) For significant changes, save the previous version: ```bash cp thoughts/beads-{bead-id}/plan.md thoughts/beads-{bead-id}/plan-v{N}.md ``` Then update the main plan. ### Step 6: Update Bead ```bash bd update {bead-id} --notes="Plan iterated: {brief description of changes}" ``` ### Step 7: Present Changes ``` I've updated the plan at `thoughts/beads-{bead-id}/plan.md` Changes made: - {Specific change 1} - {Specific change 2} The updated plan now: - {Key improvement} - {Another improvement} Would you like any further adjustments? ``` ## Important Guidelines 1. **Be Skeptical**: - Don't blindly accept changes that seem problematic - Question vague feedback - ask for clarification - Point out conflicts with existing phases 2. **Be Surgical**: - Make precise edits, not wholesale rewrites - Preserve good content that doesn't need changing - Only research what's necessary 3. **Be Thorough**: - Read entire plan before making changes - Ensure updated sections maintain quality - Verify success criteria are still measurable 4. **Be Interactive**: - Confirm understanding before making changes - Allow course corrections - Don't disappear into research without communicating 5. **No Open Questions**: - If changes raise questions, ASK - Don't update plan with unresolved questions ## Success Criteria Guidelines When updating success criteria, maintain two categories: **Automated Verification**: - Commands: `make test`, `npm run lint` - Prefer `make` commands when available - File existence checks **Manual Verification**: - UI/UX functionality - Performance under real conditions - Edge cases hard to automate ## Handling Major Changes If feedback requires significant restructuring: 1. **Discuss scope** before proceeding 2. **Consider if this should be a new plan** instead of iteration 3. **Preserve the original** in `plan-v{N}.md` 4. **Update bead description** if scope changed significantly ## Example Invocations **With full context**: ``` User: /beads:iterate nixos-configs-abc123 - add error handling phase Assistant: Based on your feedback, I understand you want to add a new phase for error handling... ``` **Interactive**: ``` User: /beads:iterate nixos-configs-abc123 Assistant: I've found the plan. What changes would you like to make? User: Split Phase 2 into backend and frontend phases Assistant: I'll split Phase 2 into two separate phases... ```