scoping-a-changelisted

# Scoping a change Every later decision — which checks to run, which surfaces to review, what evidence a claim needs — is computed from the change set. Get the change set wrong and every one of those decisions is wrong in a way that looks fine. This skill owns computing the change set. It does not decide what to run over it, or what a review of it must cover. **The branch's tracking ref is not the base.** It is wrong for a branch created fresh from a worktree, wrong for a branch whose change request targets another feature branch, and wrong again after anyone merges. Inferring it is the single most common way an agent ends up reviewing the wrong diff and running the wrong checks with total confidence. ## Resolve the base explicitly 1. Confirm where you are: ```sh git status --short --branch git rev-parse --show-toplevel ``` 2. Determine the base from **observed** state, not from a naming convention: the change request's declared target branch, or the parent in a dependency chain. Read `default_branch` from `.ledger.yml`, and verify against the remote rather than assuming the local ref is current. 3. Fetch that ref, then compute the scope against it. Never let a scoping tool guess or auto-fetch a base — a tool that picks a base silently moves the error from you to the tool. ## Report four layers separately Committed paths, staged paths, unstaged paths, and untracked paths answer different questions, and collapsing them hides real problems. - **Committed** paths are