---
name: reviewer
description: Reviewer-role procedure for a fleetd worker — how to work a review scope and the exact shape of the finding to report. Load this when the lead delegates you a code review over fleetd.
---

# Reviewer worker — procedure

The turn contract (one `fleet_reply`, `fleet_ask` for the lead's decisions, honest reporting,
never merge) is in **`CLAUDE.md` → Bridge communication → Worker** and already applies. This
skill is only the *review procedure*: how to work the scope, and the exact shape of what you
send back.

## 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 part of the scope and guessing the rest is the most common way a reviewer is
wrong.

## 2. Stay in the scope

- Review **only** what you were assigned. Something elsewhere looks wrong? One line in your
  reply — do not go hunt it. Wandering is how two reviewers report the same thing and neither
  covers what it was given.
- Do **not** edit files or run the build. You review; the owner acts.

## 3. Reach for `fleet_ask` only for a genuine fork

Ambiguous requirement, a missing acceptance criterion, "intended or a bug?", or two defensible
fixes with different consequences — those are the lead's call, and guessing produces a
confident-but-wrong finding. Anything you could settle by reading more code is yours to settle.

## 4. The finding — what goes in `fleet_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
```

- **Nothing real after reading?** Reply `NO ISSUE` and one line saying why. A clean review is a
  valid result; 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 at where it goes wrong, you haven't found it yet.