Claude Code installed and connected to a real project (see the Claude Code 101 install guide if you have not done this yet).
A codebase with an existing test suite or linter configured - the examples below assume npm test, but substitute your project's actual test/lint commands.
A terminal session open in the project root so Claude Code's file reads, edits, and commands all resolve against the same working directory.
One-line description: point Claude Code at a symbol and let its built-in search tool find every place it lives and is used.
> Find the function that calculates the order total and show me every place it's called.
Claude Code runs its built-in grep-like search across the repo instead of guessing a file path from the name alone.
It returns the definition plus each call site, which is the starting point for any edit - you cannot safely change a function's signature without knowing who calls it.
No files are modified in this step; it is pure investigation, so it typically needs no permission approval.
If the first search misses matches (e.g. the function is re-exported under an alias), ask Claude Code to widen the search rather than editing blind.
One-line description: the loop always starts with a read, even for a file you think you already know.
> Open src/utils/pricing.ts and explain what calculateOrderTotal does.
Claude Code reads the full file (or the relevant region) into context before proposing any change, rather than relying on a summary from memory.
This grounds the edit in the code as it actually exists right now, including comments, edge-case handling, and formatting conventions.
A read-only step like this is usually auto-approved since it does not touch the filesystem.
Skipping straight to "just fix it" without a read step tends to produce edits that ignore local conventions - asking for a read first sets up a better diff.
Claude Code proposes the change as a diff against the file it just read, so you can see exactly what will change before it lands.
Small, targeted edits are easier to verify by eye than large rewrites - ask for the smallest change that fixes the described problem.
Depending on permission mode, applying the edit may be auto-approved (file edits) while a follow-up command like running a test is what triggers an approval prompt.
If the diff touches more than the described bug, ask Claude Code to narrow it before accepting.
One-line description: Claude Code re-reads a file immediately before editing it again, even within the same session.
> Now also update the discount logic in the same file.
Claude Code re-reads the file right before applying a second edit rather than trusting the in-memory copy from step 2.
This protects against working from a stale version if the file changed since it was last read - by you, a formatter, or a prior tool call.
You will sometimes notice a second read happen automatically with no extra prompt from you - that is expected behavior, not wasted work.
If you edited the file outside of Claude Code (in your own editor) between turns, this re-read is what prevents the next diff from clobbering your changes.
One-line description: know what you are looking at when Claude Code asks before running a command.
Claude wants to run: npm testAllow this command? (y/n)
Some actions - notably running bash commands - can prompt for explicit approval depending on your current permission mode, while many file reads and edits are auto-approved.
Read the exact command before approving; it is your one checkpoint against an unintended side effect (like a destructive script or a network call).
If you expect to run the same safe command repeatedly in a session, most permission modes let you approve it once for the rest of the session instead of every time.
Denying a prompt is a normal part of the loop, not a failure - Claude Code will propose an alternative once it knows the command was rejected.
One-line description: let Claude Code run the full suite, read a failure, and fix it without you relaying the stack trace by hand.
> Run the full test suite. If anything fails, look at the failure and fix it, then re-run until it passes.
FAIL src/checkout.test.ts ● applies discount before tax expected 90 to equal 92.5
Claude Code runs the suite, reads failing output like the snippet above directly, and proposes a fix targeted at the failing assertion rather than a broad rewrite.
After the fix, it re-runs the suite (or at least the failing file) automatically, closing the loop instead of stopping at "I think this should work."
This only works when Claude Code is permitted to run the test command - in a stricter permission mode you may need to approve each run.
If a fix causes a different test to fail, that is useful signal - let the loop continue rather than reverting immediately.
One-line description: pull in an external tool, like an issue tracker, so the loop can start from a ticket instead of a manual description.
> Look up issue PROJ-482 and implement the fix it describes, then open a linked test run once it passes.
An MCP (Model Context Protocol) server connects Claude Code to external tools - issue trackers, databases, internal APIs - so the read step can start from a ticket instead of a prompt you typed from memory.
The rest of the loop is unchanged: read the relevant code, propose an edit, run the tests, verify the result - the MCP tool just supplies additional context or performs an external action.
Each MCP tool call is subject to the same permission logic as a bash command or file edit - expect a prompt the first time a new tool is used, depending on your permission mode.
Start with one MCP server for one workflow (like ticket lookup) before wiring up several - it is easier to trust the loop's output when you know exactly which tools it touched.
Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5. Model names, pricing, and product features move quickly - verify current specifics at platform.claude.com/docs before relying on them.
Reviewed by Chris St. John·Last updated Jul 18, 2026