chore(skills): rename design-review to code-review so Copilot picks it up

GitHub's docs are explicit: "if you want to ensure that Copilot code
review will read and use a skill, use a review-focused skill directory
name such as code-review". They also list .claude/skills alongside
.github/skills and .agents/skills as recognised locations, so the skill
was already in a place Copilot reads -- just not under a name that
reliably signals what it is for.

Renaming it means it owns the repo's review entry point, so it should
cover the whole job rather than only conformance. It now opens with two
passes: correctness first, then whether the change fits the design. That
also removes a self-reference, since the old text told the reader to run
the generic /code-review, which is now this.

The description is rewritten to lead with "review a pull request or
diff", which is what a reviewer's relevance matching has to match on.

Note for humans: `/code-review` in a Claude Code session on this repo
will now resolve to this skill rather than the built-in one. The CI
workflow is unaffected -- it invokes the plugin explicitly as
`/code-review:code-review`.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DyHK7L8S1XDX3EihTnSKaX

.claude/skills/code-review/SKILL.md

@@ -1,16 +1,21 @@
 ---
-name: design-review
-description: Review a change against this repository's own written architecture — the Cmd/Effect split, exhaustive enums, crate layering, the CellKey/layout/persistence invariants, and the testing doctrine. Use when reviewing a diff or PR, and before pushing your own work, especially when it touches commands, effects, AppMode/Axis/CategoryKind variants, persistence, or crate boundaries.
+name: code-review
+description: Review a pull request or diff against this repository's own written architecture and testing doctrine — the Cmd/Effect split, exhaustive enums over AppMode/Axis/CategoryKind, crate layering, the CellKey/layout/persistence invariants, and when a green suite is not evidence. Use when reviewing any change to this repo, and before pushing your own work.
 ---
 
-# Design review
+# Code review
 
-This repo has already written down what "correct shape" means. A review here
-is mostly checking a change against that, not inventing standards.
+This repo has already written down what "correct shape" means, in more detail
+than most. A review here is mostly checking a change against that, rather than
+against generic standards.
 
-Complements the generic `/code-review`, which hunts for correctness bugs.
-This one asks a different question: *does this change fit the design?* Run
-both on anything substantial.
+Two passes, in order:
+
+1. **Correctness** — does the change do what it claims? Wrong logic, missed
+   edge cases, error paths that swallow failures. Ordinary review judgement.
+2. **Conformance** — does it fit the design? That is what the rest of this
+   file is for, and it is the part a reviewer who has not read `context/`
+   will miss.
 
 ## Read the sources, don't trust this file
 

context/repo-map.md

@@ -273,7 +273,7 @@ examples/pretty-print.rs            Parse stdin, print formatted .improv
 
 ### Context docs
 ```
-.claude/skills/design-review/       Review skill: checks a change against the doctrine in these docs + kb.pl
+.claude/skills/code-review/         Review skill: checks a change against the doctrine in these docs + kb.pl
 scripts/nix-seed-flake-inputs.sh    Seeds locked flake inputs over git so `nix develop` works in cloud sessions
 prolog-sessions/kb.pl               Executable knowledge base: invariants, doctrine, decisions (CI-checked)
 context/cloud-agents.md             Cloud-session environment: tracker sync, bd pitfalls, what is blocked