Crux — focus a PR review on what matters

Print a markdown block to the terminal identifying the most reviewer-critical parts of the current branch's diff. The user will copy/paste it directly into the PR description, so the heading must be a descriptive call-to-action aimed at human reviewers (not the word "Crux"). Use ## For human reviewers: start here followed by the italic one-line subtitle _These are the highest-impact changes in this PR_, then the numbered list.

Wrap the entire output in a fenced code block (```markdown … ```). The terminal renders markdown by default, which strips the raw ##/_..._ syntax on copy; wrapping it in a code fence preserves the source so the user can paste it straight into a PR description.

Pull request number: the user may pass a PR number as the first argument (in Claude Code this is $ARGUMENTS; other agents should accept it however they pass invocation args). If non-empty, item links go to the PR Files-Changed tab (deep-linked to the exact diff line). If empty, fall back to blob/SHA links (file view at the current HEAD, not a diff view). Pass the PR number whenever a PR is already open; it's strictly better.

Base branch: always main.

What "crux" means

Two things only:

Business rules encoded or changed in this PR — conditions, validations, state transitions, eligibility checks, thresholds, invariants. Logic that captures a domain decision.
Observable behavior changes — what shifts for a consumer of this code: API contract, response codes, persisted state, side effects, new error conditions.

If something doesn't fit either, it isn't crux. Out of scope: refactors that don't change behavior, renames, formatting, import reorgs, bug-hunting / risk hotspots, style nits, anything a linter or test would catch, comment-only changes, generated code, vendored deps, lockfiles.