replan

Replan

Documented in depth: Claude picks the first idea that works. Make it pick the best one.

You are going to replan — an iterative process of designing, critiquing, and refining a plan.

Coding agents tend to commit to the first workable approach they find. For design decisions with high switching costs (architecture, data models, API surfaces), seek the best approach rather than the first one that clears the bar. This skill forces multiple structured critiques before settling the design.

Process

1. Understand & Clarify

• Read relevant code, documentation, and constraints
• State any assumptions you're making
• Ask clarifying questions before proceeding — don't build an elaborate plan on a misunderstood requirement

2. Initial Plan

Design your first approach, considering requirements and existing solutions. Expect it to be imperfect.

3. Critique

Generate thorough, specific critiques of your plan:

• Does it balance simplicity with good engineering?
• Is it maintainable, testable, DRY, scalable?
• Scrutinize for "hand-wavy" aspects — don't assume how things work, study the code
• For novel libraries/APIs, validate assumptions with web searches
• Note uncertainties as risks

Vague critiques like "this could be more robust" are useless. Aim for "this assumes the client handles reconnection, but I haven't verified that."

4. Alternatives

Brainstorm alternatives that address the specific weaknesses found in step 3. Goals:

• Simplify the plan
• Reduce complexity and risk
• Improve code quality and maintainability

5. Develop Best Alternative

Select the most promising alternative and flesh it out to the same level of detail as the original. A hand-wavy alternative that "sounds simpler" isn't a real comparison.

6. Iterate

Repeat steps 3-5 at least three times, asking for user feedback at each iteration. The checkpoints aren't just for steering — they're where the user injects context you can't grep for: product goals, domain constraints, recent team decisions, upcoming migrations.