Sno Station Skills

---
name: peer-review
description: "Adversarial review and fix loop for code, specs, plans, and migration manifests."
requires:
  programs:
    - {name: subscription-quota-check, min_version: "1.0"}
  harness:
    - {slot: 4.shell, need: required}
    - {slot: 4.file-read-write, need: required}
    - {slot: 4.background-processes, need: required}
---

# Peer Review

Classify → gather context → **run bundled adversarial-review script** → root cause → fix/report → repeat until clean.

"Owner" below means whoever owns the work, usually the user.

Prerequisites: Linux, bash, python3, jq, GNU `date`, `timeout`, `sha1sum`, `pgrep` and GNU `xargs`, Sno's quota pick and answer-provider commands, plus an installed, logged-in reviewer CLI on another vendor. Without python3 the findings ledger and receipts do not work.

The bundled script's adversarial-review pass is the authoritative reviewer. It runs in a fresh, separate headless session that has none of the caller's conversation. Only an answer from a different model vendor counts: the script walks Sno's ordered reviewer candidates and discards failed, empty, unknown-vendor or same-vendor answers. There is no same-vendor fallback. The active agent gathers context, investigates root causes, and applies fixes — it never overrides, filters, softens, or rewords the nested reviewer's findings. Every authoritative finding reaches the user; tag suspected false positives `[Possible FP]` with your reasoning instead of dropping them. Findings the active agent adds on its own are labeled "Active-agent supplementary" and kept clearly separate.

Works for both code and documents: classify first, then load the right verification layers. Code gets a root-cause-driven fix loop; documents get a structured report with optional edits.

## Review Calibration

The review exists to catch expensive failures — data loss, security holes, silently wrong results, primary flows breaking under real production conditions — not to audit style or completeness. Review primary flows first: establish what the artifact is for and where failure costs most, then trace those paths end to end; do not sweep line-by-line collecting local blemishes.

**First, simulate the ordinary use and prove it cannot go wrong there.** Before anything else, write down how this artifact is *normally* used — by a person, by an LLM, by an agent — and walk each of those paths end to end with the values they will really carry: the actual input formats produced by the surrounding system, the actual calls those callers make, and the actual ways their inputs fail (empty, blank, truncated, missing, stale). **A defect on the ordinary path outranks any number of exotic ones.** Edge cases deserve a few probes and never the bulk of the review; if the findings list is mostly exotic inputs, the review has not been done yet.

Exotic-input hunting feels like rigour and reliably misses the main path — a review whose findings are mostly extreme inputs has not walked the common call yet. The common failure it misses is the plausible, silent one: a caller whose variable broke passes an empty value and the tool answers with a default that looks right.

**Process-machinery doctrine:** when the
target is agent-process machinery — orchestration/supervision scripts, task
templates, skill process text, messaging contracts — the severity order is fixed:
**silent death, stalls/deadlocks, wrong-flow execution, and agents
stepping on each other outrank everything else.** A judgment error is
recoverable; a process that dies quietly, waits forever, or tramples a
parallel agent's work is not. Hunt specifically: paths where a failure
produces NO signal; waits without timeouts; state that can go stale without an