Claude Code · Advanced · Part 5 of 8

Working with Claude Code day to day: prompts, git, and fixing things when they go wrong

Parts 1 to 4 got you installed, safe, and set up with memory and cost control. This is where the advanced level starts. You can run Claude Code; now the question is how to get good results from it every day: what to type, how to ship a change with git, how to steer when it goes the wrong way, and what to do when something breaks. Everything here follows the official best-practices, common-workflows and troubleshooting pages, with my own advice marked as such.

1. How Claude actually works: the loop

The official docs describe three phases that blend together: gather context, take action and verify results. A question about your code might need only the first. A bug fix cycles through all three repeatedly. Claude decides what each step needs from what it learned in the previous one, and you can step in at any moment.

One constraint explains most of the advice in this post. Per the official best-practices guide: Claude's context window fills up fast, and performance degrades as it fills. Everything in the conversation counts: every message, every file Claude reads, every command output. A single debugging session can use tens of thousands of tokens. Keeping that window clean is the skill to build.

2. Explore, plan, implement, commit

Letting Claude jump straight to code can produce a neat solution to the wrong problem. The recommended workflow separates thinking from doing, using plan mode (Part 1) for the first two steps:

Here are the four steps with the example prompts the docs use. The first two run in plan mode (press Shift+Tab until the status bar says plan mode, or start with claude --permission-mode plan):

# 1. Explore (plan mode)
read /src/auth and understand how we handle sessions and login.
also look at how we manage environment variables for secrets.

# 2. Plan (plan mode)
I want to add Google OAuth. What files need to change?
What's the session flow? Create a plan.

# 3. Implement (approve the plan, or press Shift+Tab to leave plan mode)
implement the OAuth flow from your plan. write tests for the
callback handler, run the test suite and fix any failures.

# 4. Commit
commit with a descriptive message and open a PR

In step 2, press Ctrl+G to open the plan in your text editor and change it before Claude proceeds. A wrong assumption fixed in the plan costs one sentence; the same assumption fixed after twenty edited files costs a lot more.

3. Writing prompts that work

Claude can infer intent, but it cannot read your mind. The more precise the instruction, the fewer corrections you need. These before-and-after pairs come straight from the official guide:

A pattern worth copying from the last row: symptom, likely location, and what “fixed” looks like. Vague prompts are fine when you are exploring and can afford to course-correct; “what would you improve in this file?” can surface things you would not have asked about.

Give Claude richer context

• Reference files with @. Explain the logic in @src/utils/auth.js includes the file's content when it fits the Read tool's limit (25,000 tokens by default). Type @ to open a path menu. A directory reference shows a listing, not contents, and you can mention several files in one message.
• Paste or drag in images. Copy and paste with Ctrl+V (on Windows and WSL use Alt+V), drag a file into the window, or give an image path. Useful for error screenshots, designs and diagrams.
• Give URLs for docs or API references. Use /permissions to allow domains you use often.
• Pipe data in: cat error.log | claude -p "explain this error".
• Let Claude fetch what it needs with shell commands, MCP tools or by reading files (Part 6).

4. Prompt recipes for everyday tasks

These are prompts from the official common-workflows page, grouped by task. Adapt the wording to your project.

Notice how every recipe is a short conversation, not one giant prompt. You are not expected to get it perfect the first time: ask, read, refine. The docs also recommend asking Claude the questions you would ask a senior engineer (“How does logging work?”, “What edge cases does this class handle?”). That alone is an effective way to onboard onto a codebase.

5. Give Claude a way to check its work

The official guide calls this the highest-leverage habit. Claude stops when the work looks done. Without a check it can run, looking done is the only signal, and you become the verification loop. Give it something that returns pass or fail and it iterates by itself.

• Ask for evidence, not claims: the test output, the command it ran and what it returned, or a screenshot. Reviewing evidence is faster than re-running the check yourself.
• A second opinion: have a fresh subagent review the diff (Part 6), or run the bundled /code-review skill. A reviewer that did not write the code is not biased toward it. The docs warn that a reviewer told to find gaps will usually find some, so ask for correctness and requirement gaps only, not style preferences.
• If you cannot verify it, do not ship it. This is the “trust-then-verify gap” the docs list as a classic failure.

6. Big feature? Let Claude interview you

For larger work, start with a minimal prompt and have Claude question you before it writes anything. This prompt is from the official guide (replace the bracketed part):

I want to build [brief description]. Interview me in detail using the AskUserQuestion tool.

Ask about technical implementation, UI/UX, edge cases, concerns, and tradeoffs. Don't ask obvious questions, dig into the hard parts I might not have considered.

Keep interviewing until we've covered everything, then write a complete spec to SPEC.md.

When the spec is done, start a fresh session to build it. The new session has clean context focused on implementation, and the written spec is the shared reference. The most useful specs name the files and interfaces involved, state what is out of scope, and end with an end-to-end verification step. This pairs naturally with the feature notes and handoff notes from Part 3.

7. Git with Claude: branch, commit, pull request

Claude Code works directly with git. The official quickstart shows that you can drive it conversationally:

Tips that make this smoother:

• Install the GitHub CLI (gh) and sign in with gh auth login. Without it Claude can still use the GitHub API, but unauthenticated requests often hit rate limits.
• Put your repository etiquette in CLAUDE.md (Part 2): branch naming, commit message style, PR conventions. The docs list “repository etiquette” as something worth writing down.
• Pre-approve safe git commands instead of clicking through prompts. The docs' own example for scripts is Bash(git diff *), Bash(git log *), Bash(git status *) and Bash(git commit *). Notice they do not allow git push.
• Ask Claude to highlight risks in a pull request it wrote before you submit it, and review the result yourself.
• Review before merging. The bundled /code-review skill reviews the current diff for bugs, and /security-review runs an on-demand security pass over the changes on your branch.

Two changes at once: worktrees

If you want one session on a feature and another fixing a bug without their edits colliding, use a git worktree, a separate checkout on its own branch:

claude --worktree feature-auth

Run the same command with a different name in a second terminal for a second isolated session. The repository needs at least one commit first. The docs also describe a Writer/Reviewer pattern: one session writes the code and a fresh session reviews it, so the reviewer is not biased toward code it just wrote.

8. Steering: correct early, rewind, start clean

Conversations are persistent and reversible. The docs recommend tight feedback loops: correct Claude as soon as you notice it drifting.

Every prompt that starts a turn creates a checkpoint, and Claude snapshots files before it edits them. That means you can let Claude try something risky and rewind if it fails. The limits matter, though: checkpoints cover only edits made through Claude's file tools, not changes made by shell commands, and they are not a substitute for git.

Five failure patterns to recognise

The docs end this topic with a reminder worth quoting: these are starting points, not rules. Sometimes you should let context accumulate because you are deep in one hard problem, and sometimes a vague prompt is exactly right. Notice what works and build your own intuition.

9. When something goes wrong

Install and login problems were covered in Part 1. These are the problems you can hit once Claude Code is running. Start with the built-in checkups: run /doctor inside a session for an automated check of your installation, settings, extensions and context usage, or claude doctor from your shell if claude will not start. /mcp shows MCP server status, and /feedback reports a problem to Anthropic.

10. Wrap-up and glossary

1. Work in a loop you can interrupt, and keep the context window clean.
2. Explore and plan before you implement, unless the change is one sentence.
3. Be specific, use @ for files, and always give Claude a check to run.
4. Let Claude handle branching, commits and pull requests, then review the result yourself.
5. Correct early, rewind when needed, and /clear after two failed corrections.
6. When something breaks, run /doctor and /context first.

Next, Part 6 extends Claude Code: connecting external tools with MCP, delegating to subagents, installing plugins, and using it from your editor, the desktop app or the web.