pr-brief

A brief lets the reviewer decide a PR's future without reading its code. It is built from two things:

• A decision is a choice the codebase will live with after this PR merges. That covers a public API or contract (endpoints, GraphQL types, exported signatures, event payloads), the data model, a module boundary or dependency direction, a new abstraction or pattern, a rule in the logic (what gets validated, computed, or branched on), cross-cutting behavior, and config or infra. Everything else is implementation detail, and it stays out of the brief unless it carries a finding.
• A finding is a problem one of the audit lenses turns up. LENSES.md defines the lenses, the bar a finding must clear, and its two severities: a blocking finding goes straight to the author in an auto review, and a note waits in the brief for the user.

Arguments: $ARGUMENTS is a PR URL or number. With neither, use the PR for the current branch.

Steps 1 through 6 run without asking the user anything. The run ends one of two ways: an auto review while a blocking finding stands (step 4), or, once none stands, the brief and a question about what to post (steps 6 and 7). Settle anything unclear by reading the worktree. When only the author can settle it, put it in the brief as a note whose consequence depends on the answer.

1. Load and link the PR

gh pr view <PR> --json url,number,title,body,author,baseRefName,headRefOid,additions,deletions,changedFiles,files,reviews,comments
gh pr diff <PR>
gh api user --jq .login

Line counts split into app code and test code, meaning code that doesn't ship (tests, mocks, fixtures, factories, snapshots, stories):