One Claude Code Tip a Day: Check Status Before You Steer

This post is part of the “One Claude Code Tip a Day” series — a daily guide to using Claude Code more effectively.

A real failure: the invisible environment mismatch

The worst Claude Code mistakes I see are not wild hallucinations. They are boring session mismatches. You open a repo, ask for a frontend bug fix, Claude reads a few files, runs one test, then you switch to a deployment question. Twenty minutes later it is confidently debugging the wrong assumption: the session is in a different working directory, the model changed earlier, the context is nearly full, or permissions are stricter than you remembered.

A concrete example: you are fixing a React dashboard where a pricing table renders blank in production. Claude correctly reads `src/components/PricingTable.tsx`, notices a `background-clip: text` style, and proposes a CSS fix. Then you ask it to inspect Railway logs for the same deployment. If the session state is muddy, Claude may keep optimizing the local CSS path while the real issue is an environment variable missing on the deployed build.

That is when `/status` earns its keep. It is not a decorative command. It is a preflight check before you steer the session into a new kind of work.

Run `/status` at transition points

My rule is simple: use `/status` whenever the task changes shape. Reading code to editing code is a transition. Local debugging to deployment debugging is a transition. Fast exploration to high-stakes refactor is a transition. Before you give Claude a new instruction, ask the session what it thinks its operating conditions are.

In Claude Code, run:

/status

Then inspect the output before typing the next prompt. You are looking for practical facts: current directory, active model, context usage, permission mode, and any other session-level warnings. The exact display can vary by version and configuration, but the habit is stable: do not assume the session is still in the state you had in mind.

A useful follow-up prompt looks like this:

`Before we continue, summarize the current task, the repo path you are operating in, the files you have inspected, and the next verification command you plan to run. Do not edit anything yet.`

This turns `/status` from a passive readout into a workflow checkpoint.

The workflow: status, restate, then act

Here is a field-tested loop for a messy debugging session.

First, make Claude read the code without editing:

`Read @src/components/PricingTable.tsx and @src/styles/pricing.css. Do not edit yet. Explain why the Pro plan label is invisible in production but visible locally.`

Claude may identify the CSS issue. Good. Before accepting the patch, run `/status`. If the session is already long, or if you previously asked unrelated questions about billing code, the context may be polluted. Then force a clean restatement:

`Based on the current session state, list the assumptions behind your proposed fix. Which assumption would be disproved by a screenshot, browser devtools output, or a production log?`

Now ask for the smallest edit:

`Make the minimal CSS change only. After editing, show the git diff and tell me exactly how to verify it in the browser.`

After Claude edits, do not trust the prose. Inspect the diff:

`!git diff -- src/components/PricingTable.tsx src/styles/pricing.css`

Then run the relevant check:

`!npm test -- --run PricingTable`

If the test suite is irrelevant to visual rendering, say so explicitly and ask for a browser-level verification plan. The point is not that `/status` fixes the bug. The point is that it prevents you from asking for the next step while blind to the session you are actually driving.

What to inspect after `/status`

Look for four things.

First: repo and working directory. If you have multiple clones, this is the classic footgun. A fix in `~/scratch/app` does not help the production repo in `~/work/app`.

Second: model choice. If you are about to ask for a risky migration or a subtle review, you may want a stronger model. If you are asking for a quick grep-like summary, you may not.

Third: context pressure. A nearly full context is a bad place to begin a new feature. Use `/compact` or `/clear` intentionally instead of letting old debugging debris influence the next answer.

Fourth: permissions and tool availability. If shell commands or edits are constrained, Claude’s “I verified it” may mean something weaker than you think. Make it name the command it actually ran.

Failure mode: treating status as bureaucracy

The common mistake is to run `/status`, glance at it, and continue with the same vague prompt. That is cargo-culting the command. The value comes from changing your next instruction based on what you learn.

If the wrong repo is active, stop and restart Claude Code in the right directory. If context is bloated, compact before continuing. If the model is overkill, switch down for cheap exploration. If the model is too weak for a thorny architecture review, switch up before the review, not after a bad patch.

Second-pass correction

When Claude’s first answer feels plausible but not grounded, combine `/status` with a correction prompt:

`Your previous answer may be mixing local debugging with deployment debugging. Re-check the session state, separate local evidence from production evidence, and propose one verification step for each. Do not edit code.`

This is especially useful in deployment loops. Local tests can pass while Railway fails because `DATABASE_URL` points to localhost, an async worker starts before env vars load, or a cron job uses a different working directory. A status checkpoint helps you catch when the session narrative has drifted away from the evidence.

Rule of thumb

Use `/status` before every steering decision you would regret getting wrong: changing task type, editing production-sensitive code, reviewing a large diff, switching models, compacting context, or moving from local tests to deployment logs.

Claude Code is most productive when you treat it like a real pair programmer: before giving new directions, check where both of you are standing. `/status` is the quick reality check that keeps the session honest.