Skill: rename change-review to review-code

.claude/skills/implement-spec/SKILL.md

@@ -71,7 +71,7 @@ the notes dir. Don't paste what they can read.
 6. **Advance.** Each merge can widen the frontier: launch implementers for
    newly unblocked tickets, keeping the max of 3. Stop when the frontier is
    empty; tickets left unmerged are **stuck**.
-7. **Review.** Run the `change-review` skill on the integration branch
+7. **Review.** Run the `review-code` skill on the integration branch
    against `origin/main`. One implementer sub-agent, in its own worktree on
    the integration tip like any ticket, fixes every `hard`, `missing`,
    `wrong` and security finding (and the rest unless they contradict a

.claude/skills/implement/SKILL.md

@@ -42,7 +42,7 @@ release). Same for any issue whose fix turns out to be a vulnerability.
    test files as you go; full suite once at the end.
 4. **Commit** per logical change (test + code for one slice can share a
    commit). No attribution lines.
-5. **Review.** Run the `change-review` skill against `origin/main`. Fix every
+5. **Review.** Run the `review-code` skill against `origin/main`. Fix every
    `hard`, `missing`, `wrong` and security finding; fix `judgement` and
    `unasked` ones unless they contradict the ticket, and list any you skip.
    Fixes are extra commits. The Security axis covered the earlier commits;

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

@@ -1,8 +1,8 @@
 ---
-name: change-review
+name: review-code
 description: >
   Checks a CertShell branch against its issue / SPEC.md and the repo's
-  CLAUDE.md rules. Use when the user says "change-review", "/change-review",
+  CLAUDE.md rules. Use when the user says "review-code", "/review-code",
   "does this match the issue", "review against the spec", "review since X",
   or when `/implement` or `/implement-spec` calls it. Separate axes in
   parallel sub-agents: Standards (CLAUDE.md, CONTRIBUTING.md, code smells),

.claude/skills/tdd/SKILL.md

@@ -79,7 +79,7 @@ Never mock our own modules.
 - **One slice per cycle**: one seam, one test, the minimal code.
 - **No refactoring in the loop.** Called from `/implement` or
   `/implement-spec`: refactor in their review-fix step, after
-  `/change-review`. Called directly: one refactor pass once everything is
+  `/review-code`. Called directly: one refactor pass once everything is
   green, keeping it green.
 - Security behaviour (authz, input checks, headers, rate limits, audit
   events) gets a test that fails without the check.