One Claude Code Tip a Day: Check /status Before the Loop Runs Away

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

The failure: a debugging loop starts driving itself

The dangerous part of a Claude Code session is often not the first patch. It is the fifth loop. A frontend bug starts as a settings-page stale-value issue. Claude reads the component, edits a cache helper, runs a focused test, sees a different failure, edits again, then suggests a production build. At this point the session has momentum, but momentum is not evidence. You may not remember how long the session has been running, which model is active, whether the context is still clean, or whether the last two patches actually proved anything.

Today's tip: run `/status` before the loop runs away. Treat it as a checkpoint between action and the next action. The goal is to force a pause where Claude Code names the current state, the proof already collected, and the safest next move before it spends another command, edit, or deployment attempt.

Use /status as a checkpoint, not trivia

Command: `/status`

Use it when a session is about to continue because continuing feels easier than deciding. Good triggers include a second failed test, a widening git diff, a deployment that changed symptoms without fixing the bug, stale theories, or a moment when Claude says, `Let me try one more thing.` That phrase should make you slow down.

After `/status`, do not ask, `What next?` Ask for a decision tied to evidence: `Based on the current session status, summarize what is proven, what is assumed, and what should happen before any more edits. Choose one: continue, compact, clear, or stop for human review.` The command gives you the checkpoint; the follow-up prompt makes it operational.

A real workflow: before another deploy attempt

Imagine Claude Code is helping with a backend deploy. The service starts locally, but the container crashes in staging. You have pasted the first log, Claude patched an environment parsing path, tests passed, and the redeploy still fails with a new error. The tempting prompt is: `Fix the new error too.` That is how sessions drift from one verified hypothesis into a bag of unrelated changes.

Instead, run `/status`, then use this prompt: `Use the status output as a checkpoint. List the exact files changed, commands run, failures observed, and which hypothesis each result supports. If the diff now contains more than one logical fix, tell me before editing. Propose the smallest next proof, not the next patch.`

A good Claude Code response might say the first patch is still plausible, but the new error is startup configuration rather than request handling. It might recommend reading the Docker entrypoint before editing more application code. Or it might tell you to stop because two separate fixes are now mixed. That is the value of the checkpoint: it turns a deploy loop back into a reviewable debugging plan.

Exact prompts that make /status earn its keep

The best `/status` follow-up prompts are blunt. They make Claude choose a path and expose uncertainty.

Prompt 1: `From the current status, what is the session at risk of forgetting? Name stale assumptions, unverified edits, and checks that have not been rerun.`

Prompt 2: `Before any more edits, compare the current git diff with the original task. Which changed lines are directly connected to the failure signal? Which lines are speculative?`

Prompt 3: `Decide whether to continue in this session, run /compact, run /clear with a fresh brief, or stop. Pick one and justify it using evidence from commands, files read, and the diff.`

These prompts are intentionally procedural. They prevent `/status` from becoming a quick glance that changes nothing. If the session is healthy, you continue with a sharper next proof. If it is muddy, you compact or clear before Claude invents a third theory on top of two old ones.

Inspection and verification after the checkpoint

A status checkpoint should change what you inspect. If Claude says the diff is still narrow, verify that claim with a git diff review: `Read the current diff and group changes by intent. Do not summarize by file; summarize by behavior changed and proof available.` If it says tests passed, ask for the command names and the relevant output, not just `tests are green.` If it recommends continuing, require a single verification target: one failing test, one log line, one browser reproduction, or one deploy signal.

For frontend work, the checkpoint often reveals that Claude has only reasoned from code. The next proof should be a browser pass through the affected route, DOM inspection, or a screenshot comparison. For backend work, it may reveal that the model patched code before reading the config path that actually failed. In both cases, `/status` is useful only if it changes the next inspection step.

Failure modes and second-pass correction

The first failure mode is checking status and then ignoring it. If `/status` shows a long, expensive, or context-heavy session, but Claude still proposes a broad refactor, push back: `Rewrite the plan for the current session state. Smaller diff, one proof, no cleanup.` The second failure mode is using status as a substitute for evidence. Session state can tell you when to pause; it cannot tell you the bug is fixed. You still need tests, logs, browser verification, or a public URL check.

The third failure mode is staying in a session because it contains history. Sometimes the right move after `/status` is to preserve the useful facts with `/compact` or restart with `/clear` and a fresh brief. A good second-pass correction is: `If we restarted now, what five facts must survive? Write them as a fresh brief, then mark which facts are proven and which are assumptions.` That prevents sunk-cost debugging.

Rule of thumb

Run `/status` whenever the next action is being chosen by inertia. If the loop has produced new failures, a wider diff, or a vague urge to try one more patch, stop and inspect the session state. Then force a decision: continue with one proof, compact the evidence, clear the context, or hand the diff to a human. Claude Code is most useful when each loop has a checkpoint. `/status` is the habit that keeps the loop from becoming autopilot.