A calmer Claude Code workflow: /plan, then /goal

Use /plan to understand before changing

In Claude Code, /plan switches the current prompt into plan mode. Claude can read the repository and investigate the relevant paths, but it does not edit source files while it is planning. That turns the first part of the conversation into a shared inspection of the problem instead of an irreversible guess.

Start with a request that names the outcome, the user-facing behavior, and any constraints you already know. It does not need to prescribe the implementation. In fact, leaving room for Claude to inspect the existing structure is often the point.

/plan Add a saved-filter view to the orders screen. Reuse the existing filter controls, preserve the current URL behavior, and include the tests we need to trust the change.

A good planning prompt gives Claude a destination and boundaries. It should not become a ticket pasted into a terminal. Ask it to inspect the relevant code, identify the integration points, call out risks, and propose the smallest coherent change.

Plan mode is not a slower way to code. It is a way to spend the first few minutes on the decision that prevents an hour of corrective work.

Approve a plan that someone else could review

The useful output of planning is not a vague checklist such as “update the component” and “add tests.” It is a short implementation narrative: which files change, why they are the right places to change, what data moves between them, and how the result will be checked.

If the plan misses one of those pieces, stay in plan mode and ask the question now. “What happens to a saved filter when the underlying column is removed?” is much cheaper before implementation than after it. When the plan is right, approve it using the option Claude Code presents. Approval leaves plan mode and starts the implementation in the permission mode you choose.

You can also begin a terminal session in plan mode with claude --permission-mode plan, or cycle into it with Shift+Tab. The slash command is the one I reach for during an active conversation because it makes a single, substantial request deliberate without making every small edit ceremonial.

Use /goal to give the work a finish line

Once the direction is approved, the usual failure mode changes. The task is no longer ambiguous; it is easy for an assistant to stop after one plausible pass. /goal addresses that by setting a completion condition. After each turn, Claude Code evaluates whether the condition has been demonstrated. If it has not, the session continues instead of handing the next step back to you.

The condition should describe evidence, not aspiration. “Finish the filters” leaves too much room for interpretation. “The new saved-filter flow works, npm test -- orders exits 0, and the type check passes” gives the session something it can show.

/goal The saved-filter flow works for an existing order list, the affected test suite passes, and npm run typecheck exits 0. Do not change the public filter URL format.

A goal does not relax permissions. It determines whether Claude gets another turn; it does not grant permission to edit, run commands, or access the network. For an attended session, that is usually exactly what you want. For work you want to leave running, pair it with a permission mode appropriate to the repository and the risk.

Claude Code’s evaluator can only judge what appears in the conversation, so make the proof explicit. Name the test command, the build command, the expected file count, or the acceptance criteria. Add a limit when useful: “or stop after 15 turns and report the blocker.” A bounded goal keeps persistence from turning into aimless activity.

The two-command loop

For a feature, a bug that crosses layers, or a careful refactor, the workflow is uncomplicated:

1. Enter /plan with the outcome and constraints.
2. Read the proposed approach. Ask questions until the boundary and proof are clear.
3. Approve the plan and let Claude Code implement it.
4. Set /goal with a measurable condition for the finished result.
5. Review the diff and the evidence, not only the final summary.

The commands are deliberately sequential. A plan is for deciding what good work is. A goal is for continuing until that decision is supported by evidence. Combining them as though they were one magic prompt loses the useful pause between direction and execution.

There are two small controls worth remembering. Run /goal with no arguments to see the active condition and the evaluator’s latest reason. Run /goal clear to stop early when new information changes the job. That makes the goal a tool for persistence, not a promise to push through a bad assumption.