/cold-review

Run an independent review of actual work artifacts using fresh context. The goal is to surface issues the current agent misses because it has too much context, owns the work, or is biased toward its own implementation. This is a workflow, not a persistent mode.

Structured execution spec: protocol.yon. Read it for the canonical rules and step sequence; this file is explanation. The two must stay in sync — if you edit one, update the other and refresh the @STAMP date.

Caller Options. Before executing, run the Caller Options protocol (caller-options/SKILL.md): triage this invocation for material optionality across the venues and modes declared in front-matter; if one path clearly dominates, proceed silently; otherwise surface the options to the caller. cold-review's modes are the reviewer-count tiers (narrow/medium/broad → 1/2/3 reviewers); its venue is inline only (cold-review spawns its own reviewers — COP never wraps a self-orchestrating skill).

Boundary

Use cold-review for completed or in-progress work artifacts: diffs, files, code, tests, screenshots, UI states, plans, specs, docs, command outputs, worker reports. Do not use it for raw ideas. Use insight-adversarial for multi-POV critique of plans/ideas/strategy, verify for a formal self-gate, and double-check when the current agent should re-read and challenge a specific target itself.

Step 1 — Establish target and objectives

Identify: the work assessed; the objectives (infer and label as inferred if not given); the constraints (non-goals, compatibility, style, acceptance criteria, preferences); and the available evidence (tests, commands, screenshots, docs, diffs, source). If no concrete artifact exists, stop and ask for the target — do not review from vague memory.

For code, bind the selected candidate explicitly: working-tree files, staged content, named commit/range, or stated combination. Inspect actual selected bytes and diff; committed HEAD does not include uncommitted work. Resolve candidate ambiguity before reviewing; label inaccessible portions unchecked.

Keep two questions distinct within selected lenses and reviewer budget:

• Standards: does the candidate conform to applicable supplied or discovered repository standards?
• Spec: does it fulfill the approved specification and acceptance criteria?

Name sources for each. Missing standards or approved spec stay unknown; do not invent them or relabel inferred objectives as approved acceptance. A candidate can meet one and fail the other. Report both bases, naming each source or marking it unknown, and place findings under the applicable basis; preserve General findings that fit neither. This adds no reviewer, replaces no existing lens and preserves Caller Options and general-purpose review behavior.

Step 2 — Classify the work

Classify the primary target type and choose lenses accordingly:

Step 3 — Choose reviewer count

Spawn fresh reviewer agents when the runtime supports subagents:

• 1 — narrow work: one file, one small fix, one artifact, low risk.
• 2 — medium or mixed work: multiple files, UI plus logic, plan plus implementation, moderate risk.
• 3 — broad or high-risk work: shared abstractions, security changes, multi-surface UI, migrations, agent workflows, release-blocking work.

Do not spawn more than 3 reviewers without explicit user confirmation. If fresh agents are unavailable, perform a degraded single-agent review and label the report: Degraded review: no fresh reviewer agents were available, so this is a same-session review and may miss context-bias issues.

Step 4 — Brief reviewers

Each reviewer gets a narrow, evidence-based brief. Do not pass the lead agent's conclusions as ground truth. Assign each reviewer a coherent bundle of required lenses, covering every target lens across the selected pool. Name each bundle and its coverage explicitly; preserve the existing reviewer cap and report any uncovered lens as a gap rather than adding reviewers automatically.

Supply pointers, not a curated evidence set. The lead choosing which artifacts exist correlates every reviewer to one reading of the work — fresh context and distinct lenses do not undo that. Name where the sources are and require each reviewer to open them; a reachable source is what makes an independent check possible, and reviewers who cannot reach past your list can only audit your selection.

When source policy prohibits directory enumeration or discovery, every required source pointer must be an exact file path or an explicit resolver query. A directory alone is not a usable pointer under those constraints.

You are a cold reviewer. You did not do this work. Start from the pointers below and open the primary sources yourself.

Work assessed:
Objectives:
Constraints:
Candidate state and exact selected scope (code only):
Standards source / approved spec source (code only; unknown if absent):
Your review lens:
Primary-source pointers (a starting point, not the boundary — locate and open the sources yourself; add any the list omits):
If source policy forbids discovery, use only the exact file paths or explicit resolver queries supplied here; do not treat a directory as a sufficient pointer.
Do not modify files. Do not propose broad rewrites unless needed to fix a concrete issue.
When you check a claim, pose it as a question against the source ("Is X true, per the evidence?"), not a statement to confirm; re-open the source, do not rely on recall.

Return:
- Findings grouped by Critical, Major, Minor, Interesting
- Evidence for every finding, with file paths, commands, screenshots, or artifact references where possible
- Missing evidence or uncertainty
- Suggested score from 0-100 and rationale

Suggested lens groups:

• Backend / code: Correctness, Architecture, Security, Test Coverage, Performance reviewers.
• Frontend / UI: UX, Visual/Layout, Accessibility, Responsive States, Product Friction reviewers.
• Plan / spec: Scope, Pragmatist, Sequencing, Assumption, Executability reviewers.
• Agent skill / workflow: Trigger Auditor, Runtime Portability, Agent Runtime, Process Auditor, Failure-Mode reviewers.
• Diagnosis brief (chained after /handoff-execute): Correctness, Scope/Architecture, Hypothesis Quality reviewers. The Correctness lens checks the fix matches the named problem with no new races; Scope/Architecture verifies brief out-of-scope guards held and architecture invariants (esp. coupled-constant SEE ALSO trails) are preserved; Hypothesis Quality challenges whether the diagnosis was sound or the agent band-aided over an unidentified root cause. This triplet repeatedly catches the "missed 4th call site" / "wrong file list" / "5/5 stress isn't 10/10" class of finding.

Step 5 — Synthesize

The lead agent synthesizes reviewer reports into one final report. Do not paste raw reports unless asked.

Self-verify the synthesis (before returning). Re-open the evidence behind each load-bearing finding and confirm it against source; drop or downgrade any finding whose evidence doesn't survive a fresh read. A cold review must pass its own active re-check — a reviewer's confident finding is not exempt from the self-report unreliability it exists to catch.

Cold Review Report

Work assessed:
Objectives:
Review type: full cold review | degraded same-session review
Reviewers/lenses used:
Candidate state and exact selected scope: (code only)
Standards conformance: (code only) source or unknown; applicable findings
Spec fulfillment: (code only) approved source or unknown; applicable findings
General findings: (when applicable)

Findings
- Critical:
- Major:
- Minor:
- Interesting:

Score:
Verdict:
Recommended fixes:
Open uncertainties:

Scoring thresholds: 90-100 clean (minor notes only) · 75-89 acceptable with concerns (fix important issues before high-stakes use) · 60-74 risky (major issues need resolution) · below 60 blocked (rework or redesign). Any Critical finding caps the verdict at risky or blocked regardless of numeric score.

Rules

• MUST review concrete artifacts and evidence, not memory alone.
• MUST classify the work before choosing reviewer lenses.
• MUST use fresh reviewer agents when available and appropriate for the work size.
• MUST label degraded same-session reviews clearly.
• MUST require evidence for every finding, and MUST re-open (not recall) the evidence for each load-bearing finding at synthesis.
• MUST separate Critical, Major, Minor, and Interesting findings.
• MUST include a numeric score and threshold verdict.
• MUST NOT let reviewers modify files; this skill reviews only.
• MUST NOT confuse critique with verification: a high score does not replace tests, builds, or verify when those are required.

Human output. This skill's handler-facing output obeys the human-output contract (human-output/SKILL.md).

Self-improvement. On completion, run the Self-Improvement Protocol (self-improve/SKILL.md): apply its signal taxonomy and threshold to this run; surface any surviving proposal for handler approval. Conservative — silent otherwise. Never auto-apply.