How to Make Claude Plan Before It Starts

To make Claude plan before starting, explicitly request a plan as the first deliverable and name the actions that must wait for your approval. Include the goal, the allowed scope, the unknowns and what finished means. A reusable prompt in fenbs can keep that planning instruction beside the accepted scope decisions for the next session.

The useful result is a plan you can evaluate, not a longer introduction to work Claude already intends to do. You should be able to see what it will inspect, what it proposes to change, what needs a human choice and how it will check the result.

What should you ask Claude to do first?

1. State the outcome in one sentence. Describe the result the reader, customer or teammate needs, rather than a broad activity such as improving the website.
2. Separate research from changes. Say what Claude may read or inspect now and which actions must wait.
3. Request the smallest useful sequence of steps, with a check for each meaningful result.
4. Ask Claude to list assumptions and questions that could change the approach.
5. Set a clear stopping point: return the plan and wait, or proceed through explicitly allowed steps.

For example, a studio revising a proposal might allow Claude to read the approved outline and identify missing sections. Rewriting the proposal, changing the fee or sending it to the client are separate actions. Naming those boundaries is clearer than saying “be careful” and hoping that everyone interprets careful the same way.

Anthropic recommends explicit output constraints and ordered instructions in its prompting guidance↗ (opens in a new tab). Here, apply that principle to the deliverable: request a proposed route through the work before requesting the completed work.

What planning prompt can you copy?

Plan this work before starting implementation.
Goal: [the concrete outcome].
Materials you may inspect now: [files, sources or documents].
In scope: [allowed changes].
Out of scope: [things to leave alone].
Return: a short goal summary, assumptions and unknowns, numbered steps, expected deliverables, checks, and decisions needed from me.
Name the point where each important decision is needed. Distinguish confirmed facts from guesses.
Do not change files, send messages, publish, buy anything or modify live data during this planning step.
Stop after the plan and wait for my approval. If the scope cannot be met, explain the obstacle and propose a smaller option.

Replace the brackets before using it. “Relevant files” is less helpful than naming the folder or document Claude should inspect. Likewise, “test thoroughly” is less useful than a check such as “compare every quoted delivery date with the signed proposal.” Specific checks make it easier to recognize a finished step.

Keep the prompt proportional to the task. A short email may need three bullets: intended message, facts to confirm and recipient approval. A change across several systems needs more detail. Requiring a page of planning for a two-sentence edit can create work without reducing any meaningful uncertainty.

Does the same approach work in chat and Claude Code?

The planning request can be expressed in either workflow, but a chat instruction and an app permission mode serve different purposes. The instruction explains your intent. A permission setting controls what a particular app lets Claude do. Use the available controls as well as clear wording when the work can change files or other systems.

For coding work, Anthropic documents planning before editing↗ (opens in a new tab): Claude Code can inspect files and propose a plan in plan mode before edits are approved. Our Claude Code plan mode guide covers that specific workflow. Check the current controls in the interface you use rather than assuming every Claude app has identical behavior.

A shared subscription is a separate question from an individual planning instruction; see Claude Team plan for that topic. If you are still choosing where to work, what Claude is explains the broader product. Start with the workflow that matches the actual task, then give it the same clear goal and review boundary.

How do you review the plan before approving it?

• Scope: does every proposed action help the requested outcome, and are unrelated improvements left out?
• Evidence: has Claude inspected the materials it says the plan depends on, or are those inspections still future steps?
• Decisions: are choices about cost, content, access or public release reserved for the right person?
• Verification: does the plan name a useful check and the evidence you will receive?
• Stopping points: does it say what happens if an assumption fails or a new requirement appears?

Ask for a revision when a step is too vague to review. “Update the integration” could conceal several decisions; “change the request field, preserve the existing response and run the documented example” is easier to assess. You do not need to dictate every implementation detail to require a clear description of the intended behavior.

Approve a named version of the plan and specify the allowed next step. In fenbs Decisions and rules, keep the human decision separate from the assistant’s proposal so a later session can see which scope was actually accepted.

What if Claude starts working or discovers new scope?

Stop the action when possible and ask for a factual account of what has already happened. Request changed files or records, checks performed and anything still running. Do not approve a revised plan until you know whether the original boundary has already been crossed.

Then clarify the missed boundary in concrete language. For instance: “You may read the existing report and propose changes. Do not replace its text until I approve the outline.” If a tool permission offers additional control, use it. A prompt is useful guidance, but it is not a universal access restriction on every connected tool.

When new information changes the plan, ask for the smallest revision and its consequence. A missing source might only delay one section; it need not reopen the whole project. Preserve the accepted parts, identify the new choice and pause only the work that depends on it.

How to do this with fenbs

1. Create a free account and add the project whose work needs a plan.
2. Save the reusable planning instruction in Skills and prompts. Include the usual scope questions and the review boundary you want it to ask about.
3. Add a task for the actual work and put its current implementation steps in the task plan. Keep the problem and intended outcome in the task description.
4. Record the person’s accepted scope and any continuing approval rules in Decisions and rules. An assistant can record what a person chose; the person makes the decision.
5. Connect Claude through the integration guide, ask it to read the project context before working, and save progress with the next step before ending the session.

fenbs does not enforce every permission setting in Claude or turn a suggested plan into approval. If you only need one disposable planning conversation, a short prompt in that chat may be enough. Use the shared record when accepted plans, decisions and handoffs need to survive future sessions.

For more reusable instructions, explore the AI prompts topic. Test this planning loop on a small real task: a good first result is that you can approve, revise or reject the next action without having to guess what Claude intends to do.