53  53. Working Effectively with Claude Code

Claude Code can read your files, run commands, and fix its own mistakes, but how much you get out of it depends on how you work with it. This page collects the habits that matter most, based on Anthropic’s official best practices.

53.1 The core workflow

As of Oct 6, 2026 · Official docs: Best practices for Claude Code

1. Explore  -->  2. Plan  -->  3. Implement  -->  4. Verify  -->  5. Commit
plan mode:       Claude        leave plan         tests, build,   clear message;
read and ask     writes a      mode; Claude       run the app;    you review
questions        plan; you     edits files        fix failures    the diff
                 review it
  • Explore in plan mode: press Shift+Tab until the status bar shows ⏸ plan mode on, or start with claude --permission-mode plan. Claude reads files and answers questions but doesn’t edit your files (Permissions, Modes, and Safety).
  • Plan: ask “which files need to change? Create a plan.” Press Ctrl+G to open the plan in your text editor and change it before approving.
  • Implement: approve the plan, and ask Claude to write tests, run them, and fix any failures.
  • Verify and commit: see the sections below.

Planning adds overhead, so skip it for small, clear changes. If you could describe the change in one sentence (fix a typo, rename a variable), just ask for it.

53.2 Give Claude a way to check its work

As of Oct 6, 2026 · Official docs: Best practices for Claude Code

This is the single most useful habit. Claude stops when the work looks done. If it has a check it can run (tests, a build, a linter, a screenshot to compare with a design), it can run the check, read the result, and keep fixing until the check passes. Without one, you are the only check, and every mistake waits for you to notice it.

Instead of… Try…
“implement a function that validates email addresses” “write a validateEmail function. Test cases: user@example.com is true, invalid is false, user@.com is false. Run the tests after implementing”
“make the dashboard look better” “[paste screenshot] implement this design. Take a screenshot of the result, compare it to the original, list the differences, and fix them”
“the build is failing” “the build fails with this error: [paste error]. Fix it and verify the build succeeds. Fix the root cause; don’t just hide the error”

Ask for evidence, not just “done”: the test output, the command it ran and what it returned, or a screenshot. The bundled /verify command goes one step further: it builds and runs your app to confirm a change really works.

53.3 Be specific and give context

As of Oct 6, 2026 · Official docs: Best practices for Claude Code · Prompt library

Claude can infer a lot, but it can’t read your mind.

Strategy Vague Specific
Scope the task “add tests for foo.py” “write a test for foo.py covering the case where the user is logged out. Avoid mocks.”
Point to an example “add a calendar widget” “look at how the existing widgets on the home page are built, and follow the same pattern for a calendar widget”
Describe the symptom “fix the login bug” “users say login fails after their session times out. Check the auth flow in src/auth/. Write a failing test that reproduces it, then fix it”

Give Claude the real material instead of describing it:

  • Type @ to mention a file: explain the logic in @src/utils/auth.js.
  • Paste a screenshot (Ctrl+V; Alt+V on Windows) or drag an image in. Screenshots of error pages and designs work well.
  • Paste the exact error message or log lines.
  • Pipe data in from the terminal: cat error.log | claude -p "explain this error".

For a bigger feature, let Claude interview you before it builds anything:

I want to build [brief description]. Interview me in detail using the
AskUserQuestion tool. Ask about implementation, UI/UX, edge cases, and
tradeoffs. Keep interviewing until we've covered everything, then write a
complete spec to SPEC.md.

Then start a fresh session to build it from SPEC.md, with a clean context focused only on implementation.

53.4 Steer early and keep sessions focused

As of Oct 6, 2026 · Official docs: Best practices for Claude Code · Checkpointing

  • Esc stops Claude mid-action. The work so far is kept, so you can redirect.
  • Type a correction and press Enter while Claude works; it reads your message after its current step.
  • Esc twice (on an empty prompt) or /rewind restores the code and/or the conversation to an earlier point. You can also just say “undo that”.
  • /clear between unrelated tasks (Context, Models, Effort, and Usage).
  • Corrected it twice and it’s still wrong? The context is now full of failed attempts. Run /clear and write a better first prompt that includes what you learned.
  • Use subagents for research: “use subagents to investigate how our login handles expired sessions” keeps all that file reading out of your main context (Subagents).
  • Name and resume sessions: /rename login-fix, then later claude --continue (the most recent session) or claude --resume (pick from a list).

53.5 Git habits with Claude

As of Oct 6, 2026 · Official docs: Checkpointing · Common workflows

Claude Code’s checkpoints let you rewind Claude’s file edits, but they only track changes made with Claude’s file-editing tools, not files changed by shell commands or other programs, and they can’t undo things outside your computer, such as a database change or a deployment. Git is your real safety net (What Is Version Control?):

  • Commit before a big change, so you have a clean point to return to.
  • Review the diff before you commit: git diff in the terminal, or /diff inside Claude Code. You can also ask: “review my uncommitted changes and flag anything that looks risky before I commit”.
  • Let Claude write the commit message: “commit these changes with a message that summarizes what I did”. Then read it.
  • Make small, frequent commits, so undoing one step is easy.
  • Get a second opinion: /code-review checks your current changes for bugs in a fresh context (Pull Requests and Code Review).

53.6 Understanding a repository without changing it

As of Oct 6, 2026 · Official docs: Common workflows · Prompt library

To learn an unfamiliar project safely, start in plan mode:

cd ~/Documents/some-project
claude --permission-mode plan

Then ask the questions a new team member would ask:

give me an overview of this codebase: architecture, key directories, and how the pieces connect
trace what happens when a user logs in, from the front end to the database
which files would I need to touch to add a "remember me" checkbox? Don't edit anything yet.

For stronger guarantees (removing the editing tools entirely, or working on a read-only copy), see Permissions, Modes, and Safety.

53.7 Keep Claude working until it’s done: /goal and /loop

As of Oct 6, 2026 · Official docs: Keep Claude working toward a goal · Run prompts on a schedule

Normally Claude works until it thinks it is done and then waits for you. Two commands keep it going.

/goal <condition> sets a finish line. Claude starts working right away. After every turn, a separate small, fast model reads the conversation and judges whether the condition is met; if not, Claude starts another turn on its own. The goal ends when the condition is met, when the judge decides it is impossible, or when an error you have to fix stops the work. For example, to keep fixing bugs until the tests pass:

/goal npm test exits 0 with all tests passing; fix the code, not the tests; or stop after 20 turns

A good condition has one measurable end state, says how Claude should prove it, and names what must not change. The judge doesn’t run anything itself: it only reads what Claude showed in the conversation. Type /goal alone to see progress, and /goal clear to stop early.

/loop [interval] [prompt] re-runs a prompt on a schedule while the session stays open:

/loop 30m run the test suite and fix any new failures

Without an interval, Claude picks the wait itself (one minute to one hour). Without a prompt, it runs a built-in maintenance routine: continue unfinished work, tend to the current pull request, then hunt for bugs or simplify code. Press Esc to stop a self-paced loop. To stop a loop with a fixed interval, ask Claude to cancel it; otherwise it expires after seven days.

Next turn starts when… Stops when…
/goal The previous turn finishes The condition is met or judged impossible, an error you must fix occurs, or you run /goal clear
/loop A time interval passes You stop it, or Claude decides the work is done

Both run only while your session is open, and every turn counts against your usage. Neither changes your permission mode: in Manual mode, Claude still stops to ask before actions that need approval. For jobs that should run even when your computer is off, see routines on Claude Code Beyond the Terminal.

53.8 Common mistakes

As of Oct 6, 2026 · Official docs: Best practices for Claude Code

Mistake What happens Fix
The kitchen-sink session One session drifts across unrelated tasks; the context fills with noise /clear between unrelated tasks
Correcting over and over The context fills with failed attempts After two failed corrections, /clear and write a better prompt
The over-long CLAUDE.md Important rules get lost in the noise Prune it; turn must-happen rules into hooks
Trusting without verifying Plausible-looking code that misses edge cases Always give Claude a check (tests, scripts, screenshots); if you can’t verify it, don’t ship it
Endless exploration “Investigate X” with no limits reads hundreds of files Scope the question, or use a subagent
Not reading the diff You commit code you don’t understand Review every diff; ask Claude to explain anything unclear

A fresh context reviews code better, because it isn’t attached to the code it just wrote. The official guide suggests a Writer/Reviewer pattern: one session implements a feature; a second session (or a subagent) reviews it, for example “review the rate limiter in @src/middleware/rateLimiter.ts for edge cases and race conditions”; then you paste the review back into the first session to fix the issues. Tell the reviewer to report only problems that affect correctness or the requirements: a reviewer asked to find gaps will usually find something, and chasing every comment leads to over-engineering.

Practice Questions

Easy

Question 1 · Ordering

Put these steps of the recommended workflow in order: Implement, Commit, Explore, Verify, Plan.

Explore → Plan → Implement → Verify → Commit.

Exploring and planning first avoids solving the wrong problem; verifying before committing catches mistakes while they are cheap to fix.

Question 2 · Multiple choice

What does plan mode do?

  1. Claude edits files immediately, without asking
  2. Claude reads files and proposes a plan, but doesn’t edit your files until you approve
  3. Claude only answers general questions and can’t read your files
  4. Claude schedules the work to run later

b. In plan mode Claude explores (reads files, answers questions) and writes a plan; edits stay blocked until you approve the plan. It doesn’t edit without asking (a), it can read your files (c), and scheduling is what /loop and routines are for (d).

Question 3 · True or false

Because Claude Code has checkpoints and /rewind, you no longer need Git.

False. Checkpoints only track edits made with Claude’s file-editing tools. They don’t capture files changed by shell commands or other programs, and they can’t undo outside effects such as a database change or a deployment. Git records your whole project history and is the real safety net.

Question 4 · Matching

Match each action with what it does.

Action What it does
1. Esc A. Re-runs a prompt on a time interval
2. Esc twice (empty prompt) B. Keeps Claude working until a condition is met
3. /clear C. Stops Claude mid-action so you can redirect
4. /goal D. Opens the rewind menu
5. /loop E. Starts a new conversation with an empty context

1 → C, 2 → D, 3 → E, 4 → B, 5 → A.

Question 5 · Short answer

Why is “give Claude a way to check its work” called the single most useful habit?

Claude stops when the work looks done. With a check it can run (tests, a build, a linter, a screenshot comparison), it can see failures itself and keep fixing until the check passes. Without one, you become the only check, and every mistake waits for you to notice it.

Question 6 · Multiple choice

For which task is it most reasonable to skip plan mode?

  1. Adding login with Google to an app you don’t know well
  2. Changing how data flows through five different files
  3. Fixing a typo in a button label
  4. Choosing between two database designs

c. If you can describe the change in one sentence, just ask for it. Planning pays off when you are unsure of the approach (a, d), when many files change (b), or when you don’t know the code well (a).

Medium

Question 7 · Rewrite

Rewrite these vague prompts to be specific and checkable:

  1. “Fix the signup form.”
  2. “Make the homepage look nicer.”

Possible rewrites:

  1. “When I submit the signup form with an email that already exists, the page shows a blank screen. The form is in src/app/signup/page.tsx. Write a failing test that reproduces it, fix it so the form shows ‘This email is already registered’, and run the tests.”
  2. “[paste screenshot of the design] Make the homepage match this design. Take a screenshot of the result, compare it to the design, list the differences, and fix them.”

Good rewrites name the place, the symptom or goal, and a way to verify.

Question 8 · Write the command

Write a /goal that keeps Claude fixing code until npm test passes, without letting it change or delete the test files, and that stops after at most 15 turns.

/goal npm test exits 0 with all tests passing; do not modify or delete any test files; or stop after 15 turns

It has one measurable end state (npm test exits 0), a constraint (test files unchanged), and a limit (15 turns).

Question 9 · Write the command

Write a /loop command that checks every 10 minutes whether the deployment has finished and reports what happened.

/loop 10m check whether the deployment finished and tell me what happened

Here the interval (10m) comes first, followed by the prompt; a trailing clause such as “every 10 minutes” also works. The loop runs only while the session stays open.

Question 10 · Scenario

Sam has corrected Claude twice about how the app should calculate event capacity, and the result is still wrong. What does the official guide recommend, and why?

Run /clear and start again with a better first prompt that includes what he has learned (for example the exact capacity rule and a test case). After two failed corrections, the context is cluttered with failed approaches; a clean session with a better prompt almost always does better than a long session full of corrections.

Question 11 · Write the command

Maria wants Claude to explain a classmate’s project without changing anything. Write the commands to open it in plan mode, and give one good first prompt.

cd ~/Documents/classmate-project
claude --permission-mode plan

A good first prompt: “give me an overview of this codebase: architecture, key directories, and how the pieces connect.” (Any broad overview question works; she can then narrow down to specific parts.)

Question 12 · Find the bug

What is wrong with this goal, and how would you fix it?

/goal make the app better

“Better” can’t be measured, so the judge can’t tell when the goal is met, and Claude can’t prove it. A good condition has a measurable end state, a stated check, and limits, for example:

/goal npm run lint reports no errors and npm test exits 0; do not change any test files; or stop after 20 turns

Question 13 · Multiple choice

How does the /goal judge decide whether your condition is met?

  1. It runs your tests itself after every turn
  2. It reads the conversation, including what Claude ran and the results it showed
  3. It opens and inspects your files
  4. It asks you after every turn

b. A separate small, fast model reads the conversation after each turn. It doesn’t run commands (a) or read files (c) on its own, and it doesn’t ask you (d). That’s why the condition should say how Claude should prove it, for example “npm test exits 0”, so the evidence appears in the conversation.

Question 14 · Scenario

Claude just finished a new feature for Maria. List the Git habits she should follow before and after this point.

  • Before starting the feature: commit, so there is a clean point to return to.
  • Now: review the changes with git diff (or /diff), and/or ask Claude to “review my uncommitted changes and flag anything risky”; optionally run /code-review.
  • Make sure the checks (tests, build) passed.
  • Ask Claude to commit with a message that summarizes the change, and read the message.
  • Keep commits small and frequent.

Hard

Question 15 · Scenario

Sam set /goal all tests pass. Claude made changes and wrote “All tests should pass now,” and the goal was marked as met, but npm test actually fails. How could this happen, and how should Sam write the goal instead?

The judge doesn’t run the tests; it only reads the conversation. If the conversation contains no real test output, the judge has to rely on Claude’s claims. Sam should name the check so the evidence must appear, and ask for evidence, for example:

/goal npm test exits 0 and its output shows every test passing; do not modify the tests; or stop after 20 turns

He should still look at the final test output himself before trusting the result.

Question 16 · Compare

Which tool fits each job best: /goal, /loop, or a hook? Explain briefly.

  1. Keep fixing a failing build until it succeeds.
  2. Every 15 minutes, check whether a classmate has commented on your pull request.
  3. In every session in this project, automatically run the linter whenever Claude finishes, with no exceptions.
  1. /goal: there is a clear, measurable end state (the build succeeds), and Claude should keep taking turns until it is reached.
  2. /loop: the work repeats on a time interval (/loop 15m ...), while the session stays open.
  3. A hook (for example a Stop hook in the project’s settings): it runs every time, in every session, no matter what Claude decides. /goal and /loop last only for the current session. See Hooks.

Question 17 · Long answer

Explain the Writer/Reviewer pattern and why a fresh context helps code review. What instruction should you give the reviewer, and why?

One session (the writer) implements the change. A second session or a subagent (the reviewer) reviews it in a fresh context, and its findings go back to the writer to fix. The reviewer sees only the code and the requirements, not the reasoning that produced the code, so it is not biased toward what was just written and judges the result on its own terms.

Tell the reviewer to report only issues that affect correctness or the stated requirements. A reviewer asked to find problems will usually find some even when the work is fine, and fixing every comment leads to over-engineering (extra layers, unnecessary defensive code, tests for impossible cases).

Question 18 · Scenario

Maria plans to start /loop 15m run the test suite and fix any new failures before going to bed and close her laptop. List at least three things she should think about.

  • The session must stay open. /loop runs only while Claude Code is running; closing the laptop (or the terminal) stops it.
  • Usage: every run sends the whole conversation and uses her plan’s usage, even when nothing changed.
  • Permissions: in Manual mode, Claude stops to ask before actions that need approval, so the loop can sit waiting all night. Unattended runs need pre-approved commands or auto mode, which reduces her oversight.
  • Review: she should still review every change in the morning (diffs, test output) before committing.
  • For work that must run while the computer is off, a cloud routine fits better (see Claude Code Beyond the Terminal).

Question 19 · Long answer

Describe how you would add a “forgot password” feature to the club-events site with Claude Code, using at least five habits from this page.

A model answer:

  1. Commit the current state (a clean point to return to).
  2. Start a fresh session in plan mode; ask Claude to explore how login works now and which files a “forgot password” feature would touch.
  3. Optionally have Claude interview you about edge cases (expired links, unknown emails), then write SPEC.md.
  4. Ask for a plan, review it (Ctrl+G to edit), then approve.
  5. Ask Claude to write tests for the new flow, implement it, and run the tests, or set a /goal such as “npm test exits 0 and the reset-password tests pass; don’t modify existing tests”.
  6. Check the result yourself: run the app, try the flow, and look at the evidence Claude shows.
  7. Review the diff (git diff or /diff), maybe run /code-review, then have Claude commit with a clear message.
  8. /clear before starting the next, unrelated task.

Question 20 · Scenario

Sam types “investigate why the app is slow.” Claude reads more than 200 files and his context fills up before anything is fixed. What went wrong, and how could he ask better?

This is the “endless exploration” mistake: an unscoped investigation makes Claude read everything, filling the context. Better options:

  • Scope it: “the events page takes 5 seconds to load. Check how src/app/events/page.tsx fetches data and find the slowest step.”
  • Give a target and a check: “make the events page load in under 1 second. Measure the load time before and after your change and show me both numbers.”
  • Use a subagent: “use a subagent to investigate why the events page is slow and report the top three causes”, so the file reading stays out of his main context.

Challenge

Question 21 · Hands-on

Pick a small practice project (for example the Git practice project). Commit its current state, then:

  1. In plan mode, ask Claude to explain the project and propose one small improvement with a way to verify it.
  2. Approve the plan and let Claude implement it, asking for evidence (output or a screenshot) that it works.
  3. Use /rewind to undo Claude’s edits, then redo the change with a more specific prompt.
  4. Review the diff, then have Claude commit with a clear message.

Write a short reflection: which habit made the biggest difference?

There is no single right answer. A strong reflection describes the workflow you followed (explore, plan, implement, verify, commit), shows that you reviewed the diff and the evidence before committing, and explains how a more specific prompt or a verification step changed the result.

© 2025-2026 Y. Rosenthal. All rights reserved.