Core Claude Code Workflows Basics

10 examples to get you started with Core Workflows - 7 basic and 3 intermediate.

Prerequisites / Quick Install

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.

Basic Examples

1. Ask Claude Code to locate a function

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.

Related: Searching a Codebase with Claude Code's Built-In Grep Tool - how the search step actually works

2. Read the file before proposing an edit

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.

3. Make a small, targeted edit

One-line description: turn a located function into a one-line fix and review the proposed diff.

- return price * quantity;
+ return Math.round(price * quantity * 100) / 100;

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.

Related: A Checklist for Reviewing Claude Code's Proposed Diffs - what to check before approving

4. Run a linter to check the edit

One-line description: after an edit, run the project's linter as the "run" step of the loop.

> Run the linter on src/utils/pricing.ts and fix anything it flags.

Claude Code runs the actual lint command (eslint, ruff, golangci-lint, whatever the project uses) rather than eyeballing style by hand.
Running an arbitrary bash command is the kind of action that commonly prompts for approval, depending on your permission mode.
Lint failures are read back into context, so Claude Code can propose a follow-up fix without you having to paste the error output yourself.
Keep the loop tight: one edit, one lint run, one look at the result, before moving to the next change.

Related: How Claude Code Decides When to Run a Command vs. Ask Permission - why some commands prompt and others don't

5. Run a single test to verify the fix

One-line description: narrow the test run to just the test that covers the change you made.

> Run only the pricing test file and tell me if it passes.

npm test -- pricing.test.ts

Running a single test file is faster feedback than the full suite while you are still iterating on one function.
Claude Code reads the test output directly, so a failure is followed by a diagnosis, not just a pass/fail report.
This is the "verify" step of the loop - an edit is not done until something has actually run and confirmed it.
If the test was already passing before your edit, this also confirms you have not introduced a regression.

6. Re-read a file before a second edit

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.

Related: Why Claude Code Re-Reads Files Before Editing Them - the staleness problem this solves

7. Approve or deny a permission prompt

One-line description: know what you are looking at when Claude Code asks before running a command.

Claude wants to run: npm test
Allow 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.

Related: How Claude Code Decides When to Run a Command vs. Ask Permission - the full permission-mode breakdown

Intermediate Examples

8. Make a small multi-file change in one turn

One-line description: rename or extend something that has call sites in more than one file, all in a single turn.

> Rename calculateOrderTotal to calculateCartTotal everywhere it's defined
  and used, and update the import in checkout.ts.

Claude Code coordinates the edit across every affected file in one turn, keeping the function definition, its exports, and its call sites consistent.
It re-reads each file just before editing it, the same staleness check from example 6, applied file by file across the set.
After the edits land, run the loop's verify step again - a lint pass and the relevant tests - to catch any call site the search missed.
Multi-file changes are exactly where a narrow, well-scoped search (example 1) pays off - an incomplete search here means an incomplete rename.

Related: Making Multi-File Edits in a Single Claude Code Turn - deeper walkthrough of this pattern

9. Run the test suite and iterate on a failure

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.

Related: Running Tests and Iterating on Failures Automatically - the full pattern for this workflow

10. Extend the loop with an MCP server

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.

Related: Connecting an MCP Server to Extend Claude Code's Toolset - how to set one up | Navigating the Claude Code REPL, Prompts, and Slash Commands - REPL basics if you are new to the session model

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.

Core Claude Code Workflows Basics

10 examples to get you started with Core Workflows - 7 basic and 3 intermediate.

Prerequisites / Quick Install

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.

Basic Examples

1. Ask Claude Code to locate a function

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.

Related: Searching a Codebase with Claude Code's Built-In Grep Tool - how the search step actually works

2. Read the file before proposing an edit

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.

3. Make a small, targeted edit

One-line description: turn a located function into a one-line fix and review the proposed diff.

- return price * quantity;
+ return Math.round(price * quantity * 100) / 100;

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.

Related: A Checklist for Reviewing Claude Code's Proposed Diffs - what to check before approving

4. Run a linter to check the edit

One-line description: after an edit, run the project's linter as the "run" step of the loop.

> Run the linter on src/utils/pricing.ts and fix anything it flags.

Claude Code runs the actual lint command (eslint, ruff, golangci-lint, whatever the project uses) rather than eyeballing style by hand.
Running an arbitrary bash command is the kind of action that commonly prompts for approval, depending on your permission mode.
Lint failures are read back into context, so Claude Code can propose a follow-up fix without you having to paste the error output yourself.
Keep the loop tight: one edit, one lint run, one look at the result, before moving to the next change.

Related: How Claude Code Decides When to Run a Command vs. Ask Permission - why some commands prompt and others don't

5. Run a single test to verify the fix

One-line description: narrow the test run to just the test that covers the change you made.

> Run only the pricing test file and tell me if it passes.

npm test -- pricing.test.ts

Running a single test file is faster feedback than the full suite while you are still iterating on one function.
Claude Code reads the test output directly, so a failure is followed by a diagnosis, not just a pass/fail report.
This is the "verify" step of the loop - an edit is not done until something has actually run and confirmed it.
If the test was already passing before your edit, this also confirms you have not introduced a regression.

6. Re-read a file before a second edit

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.

Related: Why Claude Code Re-Reads Files Before Editing Them - the staleness problem this solves

7. Approve or deny a permission prompt

One-line description: know what you are looking at when Claude Code asks before running a command.

Claude wants to run: npm test
Allow 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.

Related: How Claude Code Decides When to Run a Command vs. Ask Permission - the full permission-mode breakdown

Intermediate Examples

8. Make a small multi-file change in one turn

One-line description: rename or extend something that has call sites in more than one file, all in a single turn.

> Rename calculateOrderTotal to calculateCartTotal everywhere it's defined
  and used, and update the import in checkout.ts.

Claude Code coordinates the edit across every affected file in one turn, keeping the function definition, its exports, and its call sites consistent.
It re-reads each file just before editing it, the same staleness check from example 6, applied file by file across the set.
After the edits land, run the loop's verify step again - a lint pass and the relevant tests - to catch any call site the search missed.
Multi-file changes are exactly where a narrow, well-scoped search (example 1) pays off - an incomplete search here means an incomplete rename.

Related: Making Multi-File Edits in a Single Claude Code Turn - deeper walkthrough of this pattern

9. Run the test suite and iterate on a failure

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.

Related: Running Tests and Iterating on Failures Automatically - the full pattern for this workflow

10. Extend the loop with an MCP server

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.

Related: Connecting an MCP Server to Extend Claude Code's Toolset - how to set one up | Navigating the Claude Code REPL, Prompts, and Slash Commands - REPL basics if you are new to the session model

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.

Core Claude Code Workflows Basics

Search Documentation

Core Claude Code Workflows Basics