code-criticlisted

# /code-critic — Code Review Apply this skill to review code changes against project standards. --- ## Stance Treat the implementation as a hypothesis under attack. Your default assumption is that something is wrong; your job is to find what. Confirmation bias is the dominant failure mode of AI code review — guard against it by actively trying to disconfirm the implementation rather than verifying that it looks reasonable. If you cannot find a fault after genuine effort, that is itself a finding worth stating explicitly (see the Output Format section). --- ## Before Reviewing ### Selecting the diff In the `/feature` workflow the implementation is committed before review, so a bare `git diff` (working tree) shows nothing — review the branch's committed changes against its base, the default branch named in `AGENTS.md` → *Commands*: `git diff <default-branch>...HEAD` (or `git log -p <default-branch>..HEAD`). Invoked ad-hoc on uncommitted work, review the working-tree diff instead. If unsure what changed, check `git status` and `git log --oneline` first. Note for ad-hoc use: the push gate records a commit SHA (`scripts/review-ok.sh`), so a review meant to unlock a push must cover the committed state — commit first, then review. ### Architecture Decision Records Check if a `docs/adr/` directory exists. If it does, list the ADRs you read by number in the review output. If none seemed relevant to the diff, say so explicitly — silence is not acceptable, since it is indist