One Claude Code Tip a Day: Start in the Right Repo

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

The real failure: a correct patch in the wrong place

The most expensive Claude Code mistake is not a bad patch. It is a good patch applied to the wrong checkout. In a real team, you may have a production repo, a fork, an old clone used for experiments, and a sibling package with the same component names. Claude can reason beautifully inside any of them. If you start the session in the wrong directory, it will still produce confident file paths, plausible tests, and a tidy git diff. None of that matters when the pull request belongs somewhere else.

Today’s habit is simple: before you ask Claude Code to analyze, edit, or debug, make it prove the working directory. Treat repo identity as part of the task, not as background trivia. This is especially important when you jump between customer projects, monorepos, deployment folders, and local reproductions of a production bug.

Start with an orientation prompt

Open Claude Code from the directory you believe is correct, then make the first prompt read-only:

`Before editing anything, verify where we are. Run or inspect the equivalent of pwd, git remote -v, git branch --show-current, git status --short, and the package/app structure. Tell me which repository, branch, and application this session is in, and list any evidence that this might be the wrong checkout.`

The wording matters. You are not asking for a summary of the codebase yet. You are asking for evidence: path, remote, branch, dirty files, and top-level structure. A good answer should sound slightly boring. If Claude says, ‘remote origin points to the staging fork’ or ‘this branch is release/2026-06, not main,’ you just saved yourself a false start.

Make Claude identify the active app, not just the repo

In monorepos, the repo can be right while the working app is wrong. Suppose the task is a frontend bug: the settings drawer fails only in the admin console after a feature-flag rollout. The top-level repo contains `apps/web`, `apps/admin`, `packages/ui`, and an archived `apps/legacy-admin`. If your prompt says ‘fix the settings drawer,’ Claude may chase the first matching component.

Use a second gate:

`Now identify the active app for this bug. Search only enough to locate the route, package scripts, and tests. Do not edit. If there are multiple settings drawers, trace which one is reachable from the admin route and explain the evidence.`

This turns ‘right repo’ into ‘right execution path.’ You want Claude to connect the issue to a route, package script, test file, or deployment artifact before it writes code.

The edit contract after orientation

Once the repo and app are verified, narrow the edit permission:

`We are in the correct repo and the active app is apps/admin. Fix only the mobile settings drawer path you traced. Before editing, state the files you expect to touch. After editing, run the smallest relevant test or typecheck, then show git diff and call out any unrelated changes.`

This prompt gives Claude a contract. It may inspect broadly enough to stay accurate, but the patch must stay attached to the proven path. The moment Claude edits a file outside the expected app, you have a reason to stop and ask why.

Verification: prove the session stayed grounded

After the first patch, do not accept ‘done’ as a status. Ask for a repo-grounded review:

`Before we call this fixed, re-check pwd, branch, git status --short, and git diff --stat. Confirm the changed files are all inside the intended repo/app. Then summarize the verification command and its result.`

This catches two subtle failures. First, Claude may have generated files or modified snapshots in a sibling package because a test command did more than expected. Second, you may discover that the session started on a dirty branch with someone else’s local changes. The diff review is not only about code quality; it is also a location check.

Failure modes

The first failure mode is trusting folder names. A directory called `client-dashboard` might be a reproduction harness, not the deployed app. Prefer remotes, package scripts, route traces, and deployment config over names.

The second failure mode is skipping git status because you are in a hurry. Claude can mix its patch with old local edits and then explain the combined diff as if it created all of it. Make it identify pre-existing changes before editing.

The third failure mode is starting from an issue link and assuming Claude knows which local clone matches it. It does not. Paste the issue, but still make the session verify the remote and branch.

Second-pass correction

If verification shows the wrong repo or app, do not ask Claude to ‘move the fix’ blindly. Restart the workflow:

`We appear to be in the wrong checkout. Stop editing. Summarize what you learned that may transfer, list the exact files changed here, and give me a clean prompt to rerun from the correct repo. Do not create another patch in this directory.`

Then open Claude Code in the correct checkout and begin again with the orientation prompt. The previous session may still be useful as research, but it should not become your patch source unless you deliberately port it and re-run verification.

Rule of thumb

Start every serious Claude Code session by proving three things: this is the right repository, this is the right app or package inside that repository, and the current git state is safe to edit. A grounded start feels slow for ninety seconds, then saves hours of debugging a patch that never belonged to the project in the first place.