Claude picks the first idea that works. Make it pick the best one.

Claude picks the first idea that works. Make it pick the best one.

⚡ TL;DR

Claude satisfices: the first workable approach it finds, it commits to.

That’s fine for straightforward tasks. For design decisions with high switching costs (architecture, data models, API surfaces), you want the best approach, not the first one that clears the bar.

Replan is a custom skill that forces Claude through iterative critique-and-refine loops. Each iteration generates alternatives, stress-tests assumptions, and checks in with you before converging. The result is a plan that’s been pressure-tested from multiple angles before implementation begins.

Want to skip the explanation? Jump to the setup prompt.

⚠️ The problem: satisficing

Herbert Simon coined “satisficing” in the 1950s: a portmanteau of “satisfy” and “suffice,” or choosing the first option that meets minimum criteria. It’s a rational strategy for humans with limited time and attention. It’s a terrible strategy for AI planning, where exploring alternatives costs seconds, not hours.

Your mileage may vary, but I’ve never seen Claude seriously consider alternative plans once it has one it thinks is viable. First workable plan wins. And if you suggested it, or even hinted at an implementation path, sycophancy drives Claude to make whatever you suggested into a workable strategy.

Claude Code’s plan mode (Shift+Tab twice) helps by making Claude research before acting, but it still thinks in a straight line: research, form opinion, write plan. One pass. No adversarial review of its own conclusions.

Replan breaks Claude out of this “first plan wins” local optimum and forces it to explore the design space more thoroughly.

🔄 How replan works

The core loop is simple: critique, generate alternatives, develop the best one, repeat.

  1. Understand & clarify. Read code and constraints. State assumptions. Ask questions before proposing anything. This prevents Claude from building an elaborate plan on a misunderstood requirement.
  2. Initial plan. A first draft, expected to be imperfect.
  3. Critique. Structured self-review: simplicity, maintainability, testability, hand-wavy gaps, unverified API assumptions. The specific critique questions matter. Without them, Claude produces vague critiques like “this could be more robust.” With them, you get “this assumes the Redis client handles reconnection, but I haven’t verified that.”
  4. Alternatives. Address the specific weaknesses found in step 3.
  5. Develop best alternative. 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, checking in with you between iterations. Without a floor, Claude will do one pass and declare it sufficient. Without user checkpoints, Claude converges on its own preferences instead of yours.
  7. Final plan. Cherry-pick the best elements from all iterations.

🙋 Checkpoints are where you add what Claude can’t grep for

The user checkpoints between iterations aren’t just for steering. They’re where you inject context Claude can’t find in the codebase: product goals, domain constraints, recent decisions from team conversations, regulatory requirements, upcoming migrations. Claude can read your code (and your technical project plans!), but it can’t read your roadmap or your Slack history. A plan built without that context may be technically sound and strategically wrong.

📋 The skill definition

Create this file at .claude/skills/replan/SKILL.md:

---
name: replan
description: Iterative deep planning with critiques and alternatives. Use when facing complex design decisions requiring thorough analysis.
allowed-tools: Read, Glob, Grep, WebSearch
---

# Replan

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

## Process

### 1. Understand & Clarify

- Read relevant code, documentation, and constraints
- State any assumptions you're making
- Ask clarifying questions before proceeding

### 2. Initial Plan

Design your first approach, considering requirements and existing solutions.

### 3. Critique

Generate thorough 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 with web searches
- Note uncertainties as risks

### 4. Alternatives

Brainstorm alternatives based on critiques. Goals:

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

### 5. Develop Best Alternative

Select the most promising alternative and develop it fully.

### 6. Iterate

Repeat steps 3-5 at least **three times**, asking for user feedback at each iteration.

### 7. Final Plan

Assemble the best features from all iterations into a robust final plan.

## Output Format

For each iteration, present options with pros/cons:

### Option A: [Name]

[Description]

**Pros:** ...
**Cons:** ...
**Risks:** ...

### Recommendation

[Which option and why, per design principles]

## Guidelines

- Consider Kent Beck's Simple Design rules
- Consider coupling, cohesion, testability
- Be honest about tradeoffs
- Ask questions - don't guess

Note the allowed-tools list: no Write or Edit. Replan is for thinking, not doing. If Claude could edit files, it would start implementing before the plan is settled.

Bash is deliberately excluded from the default, but there’s an argument for including it. Sometimes the best way to evaluate a plan is to prototype a small piece: “does this library actually expose the API I’m assuming it does?” or “what does git log say about how this module has changed?” Read-only tools can’t answer those questions. The tradeoff is real, though. Give Claude a shell during planning, and “let me just write a quick script to test this” can become the implementation. If you add Bash, add a guideline to scope it (see “Adapting for your project” below).

🔧 Adapting for your project

The skill above is generic. Here’s what to customize:

Add a “Required Reading” section. If your project has a CLAUDE.md, DESIGN-PRINCIPLES.md, or architecture docs, add a section before the Process steps:

## Required Reading First

Before any work, you MUST read:

- [CLAUDE.md](CLAUDE.md)
- [ARCHITECTURE.md](docs/ARCHITECTURE.md)

Every file listed here gets read at the start of every /replan invocation, so keep the list short and high-value.

Add domain-specific critique prompts. The generic critique questions work, but project-specific ones are more powerful. Examples:

  • “Does this respect our backwards compatibility guarantees?”
  • “How does this affect cold-start latency?”
  • “Does this introduce new dependencies? Are they justified?”
  • “How does this interact with our existing caching layer?”

Add these to the Critique section of the skill.

Adjust the iteration count. Three is a minimum. For high-stakes decisions (database schema migrations, public API design), consider bumping to five. For lower-stakes decisions, three is fine. You can always ask for more iterations if the plan isn’t converging.

Reference your design principles. Replace the Kent Beck line with whatever your team actually uses. If you follow hexagonal architecture, say so. If you have a style guide, reference it. The more specific the guidelines, the more specific the critiques.

Optionally add Bash for read-only validation. If you want Claude to run commands like git log, npm ls, or test commands to validate assumptions during planning, add Bash to allowed-tools. The tradeoff: Claude may start doing instead of thinking. If you add it, consider adding a guideline like “Use Bash only to verify assumptions, not to implement changes.”

🚀 Setting this up

Open Claude Code in your project directory, switch to “plan” mode (Shift+Tab to cycle), and paste this prompt:

Set up the replan skill described at
https://photostructure.com/coding/claude-code-replan/index.md
for this project.

Create .claude/skills/replan/SKILL.md with the skill
definition from the article. Then customize it:

1. Add a "Required Reading First" section pointing to any
   existing project documentation (CLAUDE.md, architecture
   docs, design principles, etc.)
2. Add domain-specific critique prompts to the Critique
   section based on this project's priorities (performance,
   backwards compatibility, security, etc.)
3. Replace the generic design principles reference with
   whatever this project actually uses
4. Ask me if there are specific concerns or constraints
   that should be part of every replan critique

Refer to https://code.claude.com/docs/en/skills.md for
skill syntax.

Review what it produces and edit to taste.

🎲 Your mileage WILL vary

The iteration count, the critique prompts, the guidelines: these are starting points. Different models respond to instructions differently, and small changes in phrasing can produce very different results.

The core principle holds even if the details need tuning: force multiple passes of structured critique before committing to a design. The first idea is rarely the best idea. Make Claude prove it.