playbook

Every category of code has a playbook — the battle-tested standard practice a senior engineer expects. Functional code that ignores its playbook (retry without jitter, write without a transaction, endpoint without authz) passes tests and bites in production. This skill audits a set of changes against the playbook and voices every departure, so the convention class can't be silently skipped.

Run the three steps in order.

Step 1 — Resolve scope

Fix exactly one concrete review target before reading any convention. Priority:

1. User named a target in the invocation (a path, HEAD, a SHA, origin/<branch>, a A...B range) → use it verbatim.
2. Working-tree changes exist and nothing was named → audit them:

   git status --porcelain          # staged + unstaged + untracked
   git diff --stat                 # unstaged
   git diff --cached --stat        # staged
   

3. Ambiguous — clean tree, OR both local edits and an obvious intended commit, OR you cannot tell which the user means → AskUserQuestion. Offer concrete options: uncommitted changes / last commit HEAD / this branch vs origin/<base> / a specific SHA. Never assume a target.