feat: add pr-review skill, project rules, and Node pin

[nathanredblur]

Summary

Adds a project-local Claude Code skill for reviewing this repo's pull requests, tracks the .claude/ project rules that were previously untracked, and pins Node so astro build stops failing with an engine error.

Why a skill, and why not code-review

Named pr-review rather than code-review because the Anthropic code-review plugin already provides a command by that name, and the two behave differently in the way that matters most: that one posts to the PR automatically; this one never publishes without an explicit yes.

The design centres on a single failure mode — the confident false positive. A wrong finding costs the author real time and teaches them to skim the next review, which is worse than missing a nit. So the bar for every finding is a file:line that was actually opened, and the skill is explicitly barred from claiming the build or lint fails, since it does not run them.

What's here

Path
.claude/skills/pr-review/SKILL.md	The review workflow, severity scale, and an explicit list of what not to flag
scripts/pr-context.sh	One call for a PR: metadata, eligibility flags, diff, and the review comments earlier PRs on the same files attracted
scripts/pr-tree.sh	Reads and greps the PR's tree, not your working directory
scripts/pr-stack.py	Places a PR in its stack and searches the rest of the chain
scripts/post-review.py	Validates every inline comment against the real diff hunks before posting
.claude/rules/ + .claude/CLAUDE.md	Project conventions, previously untracked
.claude/pr-review-evals/	The eval harness (results gitignored)

Two of those scripts exist because of mistakes made while using an earlier draft of the skill on a real PR:

• pr-tree.sh — the working directory is usually main. Grepping src/ to reason about a branch produced "these four components have no references", which was flatly wrong: the references were on the branch. Any question about a PR's file contents now goes through the PR's own tree.
• pr-stack.py — this repo stacks deep (main → #25 → #26 → #21 → #18 → #24 → #19 was a real chain), and position decides what a finding means. An ancestor supplies things, so "X is missing" is wrong when the parent adds X. A descendant may already fix things, which makes a finding a merge-ordering constraint rather than a defect. Sampling the stack by hand missed a PR that touched the same component.

Verification

Both gates pass on this branch:

pnpm exec biome ci ./src   → exit 0, 34 files, 3 warnings + 1 info (all pre-existing on main)
pnpm build                 → 9 pages built, complete

pnpm build needs Node >= 22.12; the mise.toml in this PR is what makes that reproducible.

The skill itself was evaluated against three real PRs from this repo, each run with and without the skill: a stacked i18n PR, a Dependabot bump, and a bare "which PRs need review?". The assertions that actually separated the two runs were about restraint rather than thoroughness — the unaided baseline asserted a strictNullChecks compilation failure with no typechecker installed, and reviewed PRs of its own choosing when given no target. Harness and criteria are in .claude/pr-review-evals/.

Not verified

• pr-tree.sh's auto-fetch fallback never ran: every PR tested already had its head commit locally. Only the refs/pull/N/head refspec was confirmed valid against the remote.
• No timing or token figures in the eval benchmark — the data was not available, and estimates would have been worse than the omission.
• The eval baseline is an unaided agent, not an earlier version of the skill, so the numbers say "this beats working from scratch" and not "the revisions improved it".

Reviewing this

.claude/rules/architecture.md describes the JSON-LD components as wired from layouts/Home.astro — accurate as of #25 merging.

🤖 Generated with Claude Code