A Typical Workflow, Step by Step

The individual tools covered so far — reading, editing, running commands, searching, git — come together into a consistent shape on almost every real task. Here's what that looks like end to end, using a concrete example: "users report that logging in with an expired session token doesn't redirect to the login page — it just shows a blank screen."

1. Describe the task, with context

The request above already includes more than the bare bug — it says what's observed (blank screen), what's expected (redirect to login), and the trigger (an expired token). That context shapes everything downstream: it's the difference between Claude guessing at what "fixed" means and actually knowing the target behavior.

2. Investigation before action

Claude searches the codebase for session and token-expiry handling, reads the relevant authentication and routing code, and — for anything non-trivial — proposes an approach before changing anything, which is exactly what plan mode is for on a bug like this where the root cause isn't yet confirmed.

3. Reproducing the problem

Where possible, reproducing the bug first — running the app, simulating an expired token, confirming the blank screen actually happens and roughly why — turns "I think this is the cause" into "I confirmed this is the cause" before a single line changes.

4. Making the edit

A targeted edit fixes the actual root cause: maybe the redirect logic checks for a missing token but not an expired one, and the fix adds that case. The change is scoped to exactly what the bug requires — not a broader refactor of the authentication module that wasn't asked for.

5. Verifying, not just claiming

This is the step that separates "should be fixed" from "is fixed": running the relevant tests, and ideally reproducing the original scenario again to confirm the blank screen is actually gone and the redirect actually happens. A test suite that passes without ever exercising the changed code path proves nothing.

6. Review

The diff is small and focused, which makes it fast to review: one logical change, addressing exactly the reported bug, with nothing unrelated mixed in.

7. Committing and shipping

A commit message describing the fix and its cause, written from the actual diff — and from there, a pull request if that's the project's workflow, or just moving on to the next task if it isn't.

What made this go well

Nothing here required any special configuration — it's the same loop (investigate, act, verify) applied with normal care. The two things that most affect how smoothly it goes are the quality of context in the initial request, and whether verification actually happened or got skipped. The final topic covers the habits that make that consistent across many tasks, not just one.