One Claude Code Tip a Day: Start in the Repo That Can Prove the Fix

This post is part of the “One Claude Code Tip a Day” series — a daily guide to using Claude Code more effectively.

The real task: a good fix in the wrong directory

The easiest way to waste a Claude Code session is to start it from the directory that feels convenient instead of the directory that can prove the work. I have seen this happen in monorepos, split frontend/backend apps, and deployment folders. Claude reads enough files to sound confident, patches the package it can see, and only later do you realize the failing test, route, or deployment script lived one level away.

Today’s habit is simple: before you type `claude`, choose the repo or subfolder that contains the proof path. The right starting directory is not just where the code lives. It is where Claude Code can inspect the implementation, run the focused check, read the relevant config, and review the resulting diff without guessing across project boundaries.

Start with a repo preflight

Use this when you are about to fix a bug, implement a small feature, or update docs in a project with multiple apps. Instead of launching Claude from your home directory or the top of a giant workspace, do a thirty-second preflight:

`pwd`

`git rev-parse --show-toplevel`

`git status --short`

`find . -maxdepth 2 -name package.json -o -name pyproject.toml -o -name Cargo.toml -o -name go.mod`

Then start Claude Code from the smallest directory that still contains the evidence. For a frontend rendering bug, that may be `apps/web`, not the root. For a billing webhook failure, it may be the API service, not the dashboard. For a deployment regression, it may be the infra repo plus the application repo, which means you should explicitly tell Claude which one is read-only and which one may be edited.

The prompt that prevents repo drift

After launching Claude Code, do not immediately ask for a fix. Make the first message a repo-orientation check:

`We are in apps/web. Before editing, confirm this is the right working directory for fixing the checkout total bug. Identify the files, test command, and config that would prove the fix. If the evidence appears to live in another repo or package, stop and tell me what directory I should open instead.`

This prompt changes the session. Claude is no longer rewarded for patching the first plausible file. It has to justify the working directory. In a real checkout bug, a useful answer might point to `src/components/OrderSummary.tsx`, `tests/e2e/checkout-total.spec.ts`, `playwright.config.ts`, and the command `pnpm test:e2e --grep "checkout total"`. A weak answer says “I can inspect the codebase” without naming a proof command.

A realistic failure loop

Imagine you are fixing a missing success banner after a payment callback. You start Claude Code from the frontend repo because the bug is visual. Claude finds the banner component, adds a loading state, and the local UI looks better. But the actual failure is that the API callback returns `pending` for one provider, so production never emits the success event. The patch is not useless, but it did not touch the cause.

The second-pass correction should be direct:

`Stop editing. Our proof command only exercised the frontend state. Inspect whether the success event is produced by the API. Tell me whether this session should move to ../api, and list the exact log line or test that would prove the callback path.`

That is the TonBisa-style loop in miniature: prompt, inspect, find the gap, correct the scope, verify again. The mistake was not that Claude wrote bad React. The mistake was that the session started in a repo that could not observe the backend truth.

What to inspect before edits

Ask Claude to produce a small field report before touching files. It should name the current directory, the likely package boundary, the files it expects to edit, the command it expects to run, and what evidence would prove the change. If it cannot name those things, you do not have a coding session yet; you have a search session.

For monorepos, make it check workspace wiring. Does `pnpm --filter web test` run from here? Are shared packages symlinked or built separately? Is the failing code generated from another package? For docs work, ask whether the documented command exists in this repo or a sibling. For deployments, ask whether logs and environment variables are available from this checkout or from the platform dashboard.

Failure modes

The first failure mode is starting too high. A repository root can be useful for global search, but it also encourages wide, unfocused edits. If Claude proposes touching three packages before it has run one focused check, narrow the directory or narrow the prompt.

The second failure mode is starting too low. If you open only `src/components`, Claude may miss test setup, routing, build config, or generated types. The right directory is the smallest one that still contains the proof path, not the smallest one that contains the file you suspect.

The third failure mode is hiding a dirty working tree. Before Claude edits, run `git status --short` and ask it to account for existing changes. Otherwise it may build its plan on half-finished work and make the diff impossible to review.

Rule of thumb

Start Claude Code where the fix can be proven. If the current directory cannot name the failing command, the relevant logs, and the files likely to change, pause before editing. Move the session, widen the context deliberately, or mark another repo as read-only evidence. A good Claude Code session begins with the same question a good engineer asks: where can I see the truth?