A plan you can answer beats a plan you can read

The bottleneck moved from writing to reviewing

When Claude writes code or drafts a project, producing the work is no longer the slow part. Reviewing the plan before it executes is. And the plan is where the real decisions sit: which approach, what to leave out, what happens in the edge case.

A 400-line plan in a text file doesn't get read. People skim, say fine, and the decisions inside get made by the model, silently. You approved it, technically. You just didn't know what you approved.

A plan should be a list of decisions

The fix is a change of shape, not more discipline. A good plan is a tree of claims you can open one level at a time. At the top, what this is and why you want it, in your own words. Under that, what someone can now do or see. Under that, how it works. At the bottom, where it lives in the code. You read the top in a minute and open deeper only where something looks wrong.

Each decision sits in the plan as a numbered question with options. You answer it in place. A question like does this look good invites a nod. A question like pick A or B forces a choice, and that is the point.

A community plugin that does this

There is a plugin for Claude Code called html-plan, listed in a community marketplace hosted under Anthropic's GitHub organization. It is contributed by the community, not maintained by Anthropic. Its README describes the goal as a plan you can read in a minute and answer in place.

It shows decisions as numbered items, with a button that jumps to the next unanswered one. You pick options, edit a schema, or comment on any line, then press Respond and paste the single answer back to Claude. It needs node. In the terminal:

claude plugin marketplace add anthropics/claude-plugins-community
claude plugin install html-plan@claude-community

Then, inside Claude Code:

/html-plan add send later to the composer

You don't need the plugin

The idea is the part worth keeping, and it applies well beyond code. Any plan Claude writes, whether a migration, a campaign, a hiring process or a report structure, can be shaped this way. Ask for it directly:

Before you execute, present the plan as a short list of decisions. For each one, write the question, the options, and your recommended answer with a reason. Wait for my answers before you start.

You get a short list instead of a long document, and a recommended answer is much easier to accept or push back on than a blank question.

Where it breaks

The model still chooses which decisions to surface. A decision it doesn't flag is still made silently, and a tidy list can look more complete than it is. So add one question to the end of every plan: what did you assume that you did not ask me about? That answer is often the most useful part.

What to do tomorrow

Next time you ask Claude for something with more than three steps, paste this before it starts:

Before you execute, list every assumption you are about to make that I have not confirmed. Then present the plan as numbered decisions with options and a recommendation, and wait.