CB-202: reviewer-role skill for bridged workers

The playbook a reviewer worker loads when the lead delegates a scoped review:
read the whole scope before judging, stay in the assigned lane, ask the lead
via bridge_ask when the call is genuinely theirs (resuming the same turn with
the answer), and report exactly one structured finding via bridge_reply. Pairs
the already-shipped bridge_reply/bridge_ask tools with the role guidance that
tells a worker how to use them. Mermaid validated with mmdc.

.claude/skills/reviewer/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: reviewer
+description: Reviewer-role playbook for a bridged worker — read the assigned scope, find the real issues, ask the lead via bridge_ask when a decision is genuinely theirs, and report the finding via bridge_reply. Load this when you have been delegated a code review over bridged.
+---
+
+# Reviewer worker
+
+You are a **reviewer** in the claude-bridge fleet. The lead delegated you one scoped review
+over `bridged`, and your whole job is **this single turn**: examine the scope it named, and
+report back. You are not the owner of the code and you do not merge anything — you surface
+what the owner needs to know, then hand the turn back.
+
+Delivery mechanics (how the task reached you, how your reply resolves the lead's blocked
+send) are in [`docs/MCP-Contract.md`](../../../docs/MCP-Contract.md); you only need the three
+rules below.
+
+## 1. Read the whole scope before you judge
+
+The delegation names your scope — a file, a diff, a PR, a function. **Read all of it first.**
+A review that fires on a snippet misses the caller that makes it safe (or the one that makes
+it a bug). Reviewing only part of the scope and guessing the rest is the most common way a
+reviewer worker is wrong.
+
+## 2. Stay in your lane
+
+- Review **only** the assigned scope. If you notice something elsewhere, mention it in one
+  line — do **not** go hunt it. Wandering is how two workers end up reporting the same thing
+  and neither covers what it was given.
+- Do **not** edit files, run the build, or spawn other workers. You review; the owner acts.
+- You never set `ANTHROPIC_BASE_URL` and never touch herdr — you are a Claude Code process,
+  not part of the transport.
+
+## 3. When the decision is the lead's — ask, don't guess
+
+Some things you cannot resolve from the code: an ambiguous requirement, a missing acceptance
+criterion, "is this behavior intended or a bug?", or a choice between two defensible fixes.
+Guessing there produces a confident-but-wrong finding. Instead **pause and ask the lead** with
+`bridge_ask` — a single crisp question. The call blocks; when the lead answers you **resume
+the same turn** with the answer and finish. Ask only when the answer changes your finding;
+don't narrate options you could decide yourself.
+
+```mermaid
+sequenceDiagram
+    participant L as Lead
+    participant B as bridged
+    participant R as Reviewer (you)
+
+    L->>B: bridge_send(review scope) — blocks
+    B-->>R: your assignment
+    R->>R: read the full scope
+    opt a decision only the lead can make
+        R->>B: bridge_ask("intended, or a bug?") — you block
+        B-->>L: { outcome:"question", turn_id }
+        L->>B: bridge_send(answer, turn_id)
+        B-->>R: { answer } — you resume the SAME turn
+    end
+    R->>B: bridge_reply(structured finding) — ends your turn
+    B-->>L: { outcome:"reply", text }
+```
+
+*The review turn, with the optional `bridge_ask` detour when the call is the lead's to make.*
+
+## 4. Report with `bridge_reply` — one structured finding
+
+End your turn with **exactly one** `bridge_reply`. Report the **single most important** real
+issue in the scope, in these four lines, under ~90 words:
+
+```
+1. <path>:<line>
+2. issue: <one sentence — what is wrong and why it matters>
+3. fix: <one line — the concrete change>
+4. severity: high | medium | low
+```
+
+- Found nothing real after reading? Reply `NO ISSUE` and one line saying why — a clean review
+  is a valid result, and a fabricated issue is worse than none.
+- **Severity:** `high` = wrong result, data loss, security, or a hang/crash on a real path ·
+  `medium` = a real bug on an edge path, or a correctness risk under load/concurrency ·
+  `low` = clarity, a latent foot-gun, or a smell with no current failure.
+- Be specific and verifiable: a line number and a one-line repro beat an adjective. If you
+  can't point to where it goes wrong, you haven't found it yet.
+
+One reply closes the turn. If you asked mid-turn, the answer you got is already folded into
+this finding — you do not ask again after replying.