There is a specific failure mode in chat-based assistance that wastes more time than any code-generation bug: the model gives you eight steps at once, step three is wrong because the UI has moved, you cannot tell which subsequent step still makes sense, and the conversation spirals into “try this, no try that, no try this other thing.” Twenty minutes later you are no closer to the goal than when you started.

The fix is small. It is “show one step, wait for confirmation, then show the next.” It is not new (Microsoft Style Guide, Nielsen Norman Group, Diataxis tutorials all describe it). What is new is writing it down as a rule the model loads on every session so it actually changes how the model behaves.

The story behind the rule

The trigger was a routine task: “set up a new repository in a cloud provider’s UI.” The model gave me a numbered list of fourteen steps. Step 4 said “click the Settings icon in the top navigation.” There was no Settings icon in the top navigation; it had been moved to a side panel two months earlier. I told the model. It said “okay, try the side panel instead, then continue with step 5.” Step 5 referenced something only present if step 4 had succeeded the way the model imagined. I was now improvising my way through an outdated tutorial.

This is the failure mode the rule prevents. The model does not know the current state of the UI. The training data is months or years stale. The user knows the current state, but only the part visible right now. The right shape of collaboration is: model proposes one step, user confirms it worked, model proposes the next. Catching a mismatch at step 1 is cheap. Catching it at step 8 is expensive.

The rule

The full rule, from ~/.claude/rules/guide-user.md:

# User Guidance Style

How to walk the user through a procedure (GUI navigation, CLI setup,
web settings, API config, etc.). Follows Microsoft Style Guide for
step-by-step instructions and Nielsen's progressive disclosure
principle, adapted for chat.

## When to gate steps (one at a time, wait for confirmation)

Use wizard mode, show one step, wait for the user to confirm done,
then show the next, when ANY of these apply:

- Procedure is long (4+ steps).
- A later step depends on an earlier step's output (B blocked by A).
- Steps involve a real GUI the user must navigate (UI may differ
  from what the model remembers).
- User seems unfamiliar with the tool (Diataxis tutorial mode).

Why: if step A does not match the actual UI, listing A through Z
up front strands the user. They re-prompt, the model guesses
again, and the loop wastes turns. Gating catches the mismatch at A.

## Step format

Each step has three parts:

1. Location first, action second: "In Settings (top right), click
   Billing." Not just "click Billing." User needs to know where
   before what.
2. One action per step. Do not combine "click X and then enter Y
   and then save." Combine only when both happen in the same place
   in the UI.
3. Anchor for confirmation. Tell the user what they should see
   when the step succeeds, so they can confirm they are in the
   right place: "You should now see a panel titled 'Payment
   methods'. Confirm?"

## When listing all steps at once is OK

- Short procedure (2-3 steps) with independent steps.
- A single CLI command block meant to be copy-pasted as one unit.
- User explicitly asks for the full list ("just give me all the
  steps").
- User has confirmed their tool version or UI matches what you
  are describing.

## When the user says "I don't see that" or retries

Stop guessing alternative steps. Instead:

- Ask for a screenshot, exact output, or version number.
- Do NOT list more options for the user to try blindly. That
  compounds the mismatch.

## Cap on steps per procedure

Microsoft Style Guide caps a single procedure at 7 steps,
preferably fewer. If a flow needs more, split into sub-procedures
with clear checkpoints.

The rule is short on logic but heavy on specifics. The specifics matter because they replace the model’s defaults, which lean toward “be helpful by listing more.”

Why wizard mode works

The argument for wizard mode is mathematical, not stylistic. If each step has a small chance of mismatch (the model’s memory of the UI is stale, the version is different, the user is on a different OS), and there are N steps, the probability that the whole procedure works as written is roughly (1 minus mismatch rate) to the Nth power. With N equal to 14 and a 10 percent mismatch rate per step, you get about a 23 percent chance of the whole thing working. With wizard mode, every mismatch is caught at the step that fails, with all subsequent steps still ungenerated, so the conversation can pivot.

That is the technical version. The user-facing version is “you do not waste time trying to interpret a step that does not exist.”

Why location first, action second

This one is from Microsoft Style Guide and it is a small change with big effect. “Click Save” tells you nothing if there are five Save buttons on the screen. “In the Settings dialog (lower right of the screen), click Save” tells you which Save, where to find it, and confirms that you are in the right context. The cost is six more words. The benefit is no ambiguity.

The model defaults to terse instructions, which read well in prose but fail in practice. The rule forces the verbose version.

Why one action per step

Steps that combine actions (“click X and enter Y and click Save”) fail in two ways. First, if any of the three substeps does not match, you cannot tell which one. Second, the model is more likely to skip the anchor for the combined step (no clear “you should now see” after a three-action step). One action per step lets each step have its own confirmation.

The exception is when two actions genuinely happen in the same place in the same flash of UI: a modal that has two inputs and a single Save. There the rule allows combining. The rest of the time, split.

Why “stop guessing” when the user says “I don’t see that”

This is the hardest rule for the model to follow. When the user says “I don’t see Settings,” the model’s default response is to suggest other places to look. Sometimes the suggestion is right. Often the suggestion is also wrong, and the user is now trying their third location. Each guess that fails amplifies the mismatch.

The rule says: stop. Ask for a screenshot, the exact text the user is looking at, or the tool’s version. Concrete evidence is the only way to get out of the loop. Without evidence, both sides are guessing, and the conversation gets longer with each guess.

I have to remind the model of this rule mid-conversation sometimes, because the model’s instinct is to keep proposing. The rule helps but does not entirely eliminate the pattern. It does reduce it.

When the rule does not apply

The rule explicitly carves out cases where listing everything at once is fine:

  • Short procedures (2 to 3 independent steps). If there is no dependency between steps and the whole thing fits on one screen, list them.
  • A single CLI command block meant to be copy-pasted. “Run this:” followed by a multi-line command is not a procedure, it is a single action. List it.
  • The user asks for the full list. “Just give me all the steps” overrides wizard mode. The user is choosing speed over safety; respect the choice.
  • The user has confirmed their version matches. If we have already verified that the tool is at version X.Y and the UI matches what I am describing, the mismatch risk is low enough to list everything.

The rule also has a hard cap: 7 steps per procedure, preferably fewer. Anything longer gets split into sub-procedures with their own checkpoints. The cap comes from Microsoft Style Guide, which I trust on this kind of thing.

Variants you might want

  • Bilingual wizard. If you guide users in two languages, the rule should specify both. The model can lose track of language mid-conversation; the rule should remind it.
  • Wizard mode only for GUI, never for CLI. Some users want CLI procedures listed all at once because they want to read the whole flow first. You can scope the rule to “GUI only” if that fits.
  • Add a default disclaimer. Every procedure starts with “the UI may have changed since this rule was written; if a step does not match, tell me.” Sets the expectation up front.
  • Tool version probing. A more aggressive variant: every procedure starts by asking the user to confirm the tool’s version. This costs a turn but eliminates a whole class of mismatch.

Closing note

This rule has improved my interaction with the model more than any code-generation rule. Most of my Claude Code use is not generating code; it is procedural questions (“how do I set up X” or “what is the right way to configure Y”). The wizard pattern is what turns those interactions from “long list, half of it wrong” into “one step, confirm, next step.”

If you copy this rule, the part most worth copying verbatim is the “stop guessing” section. It is the hardest thing to write but the most valuable when the conversation hits a wall.