mcpbeat Sign in

Cold Review Agent Skill

Write the brief for a single independent cold reviewer and grade what it returns, keeping it isolated from the panel that already graded the change. Read by whoever AUTHORS the brief; the graded seat never loads this file. Covers what the seat is given, what its verdict binds, who may override it, and how the rules degrade when the vendor set is short. Use when a panel has reached consensus and you want a second opinion consensus cannot anchor, when a change is security-sensitive or hard to reverse, or when you are the author and therefore the worst available reader of your own work.

4k tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
264
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/Cotal-AI/Cotal --skill cold-review

The instruction itself

12 sections, as written by the author

Cold review

A cold reviewer is not an extra panelist. It is a control on the panel.

A panel converges. Reviewers read each other, findings get confirmed by seats already looking in the

same direction, and the group arrives somewhere with more confidence than any member earned alone.

That convergence is usually right, which is why it is dangerous when it is wrong: a panel of three

has approved a head carrying a defect all three missed, and what surfaced it was a differently framed

read, not a fourth verifier.

This file is read by the person who WRITES the brief, not by the seat being briefed. The value is

in the brief, not in the seat's context. A cold seat that never loaded a skill file, never joined the

mesh and received nothing but a persona has produced three blockers that two fully-briefed lenses

missed. So nothing here requires the graded seat to have access to this document, and no rule below

may be written so that it does.

The isolation

  • Never joins the review channel. Not muted, not quiet. Not joined.
  • Never shown the panel's findings, verdict, or round count, including as a list of things

already ruled out so it can skip them. Skipping-instructions are findings shaped like scope.

  • DM-only or file-only input from the author or manager. Its verdict goes first-hand to the

dedicated record destination itself.

  • Never shares a model family with whoever WROTE the change.

Why never join, stated correctly. Joining exposes the seat to the panel's live traffic for as

long as it is subscribed, and the panel is active during a cold read. Replay of history is a second

exposure path but not a guaranteed one: replay is channel.replay ?? defaults.replay ?? true, a

default-true policy with a per-channel override, so a replay=false channel would not replay. The

rule does not depend on that setting in either direction, and a brief that justifies it by replay

alone is resting on a config it cannot rely on.

Prefer the ACL to the request. subscribe: [] plus an allowSubscribe that excludes the panel

channel makes non-join a property of the seat rather than an instruction it must follow. Where a

fence exists, use the fence.

If you catch yourself wanting to tell it something so it does not waste effort, that is the anchor

forming. Let it waste the effort; that is the price of the control, and it is cheap next to a

laundered verdict.

What the brief contains

It must be executable without a follow-up question, because a follow-up is the contact the isolation

forbids. A brief that omits the operational half forces the seat to come back and ask.

The substance, and nothing beyond it:

  • the artifact at a named exact commit, and the instruction to re-resolve that sha itself;
  • the bounded question, stated so it cannot be answered by agreeing with someone;
  • for a delta re-grade, the exact sha range and an explicit scope boundary naming what is out of

scope and already settled.

The operations, all of which are required and none of which anchor:

  • the absolute path of its own detached worktree, which is never the graded tree;
  • where the verdict goes, by exact destination (see below);
  • the prohibitions it operates under, and the verdict shape;
  • its own model and effort line, to be stated in the verdict.

What must never appear: the issue's own diagnosis, the author's rationale, "the tricky part is

X", the panel's findings in any form, or a question phrased as confirmation. Ask "what does this

change accept that it should not, and what does it reject that it should not" and let the seat derive

the set. Never "do you agree that".

If the author believes something is weak, that belief goes to the panel, which benefits from it.

The cold seat's job is to find what nobody framed.

Where the verdict goes

A verdict that exists only in a manager's context is not a verdict. It must land somewhere that

survives the seat and the manager, and the seat must put it there itself, because a relayed

verdict cannot be distinguished from an invented one.

The broker-attested destination is a Cotal mesh post on one dedicated record channel that the cold

seat may publish only to and the panel cannot read. The cold persona keeps subscribe: [] and

allowSubscribe: [], and grants allowPublish only for that record channel. Publishing the verdict

does not require joining it.

A file at an absolute path written into the seat's persona remains an explicit fallback when the

record-channel route is unavailable. It is first-hand delivery only as a norm and cannot satisfy a

gate that requires broker-attested poster identity. A GitHub comment is not a substitute: it

identifies the workstation's GitHub account, not the Cotal seat, and a shared gh credential lets the

manager post the same comment.

Poster is a control only on the Cotal broker-attested destination. A mesh post carries the Cotal

principal the broker records. A GitHub comment carries a GitHub account and does not bind that account

to the Cotal seat. A file at an absolute path carries neither: any process that can write

that path can produce the artifact, including the manager who later "confirms" it by re-reading it.

First-hand file delivery is therefore a norm on the seat and the briefer, not a control a later

stranger can verify. A gate that treats the file's existence as proof the seat posted has accepted a

relay. When the brief must use a file, say so in the verdict record, and do not list poster or channel

membership among the checkable controls for that delivery.

Verify at the destination, never at the source. Re-fetch the landed artifact and grep it for

content you expect, with a positive control so an empty fetch cannot pass as a clean result. Writes

that report success and do not land are common, including an edit that reports nothing and changes

nothing or a file write that does not persist while the tree reports clean.

What the verdict says

APPROVE, or named blockers. Never an open-ended re-read, never "looks fine so far", never a list

of things it might check next.

It must separate what it EXERCISED from what it INSPECTED, and the split is defined by the

OBJECT, not the verb: *exercised* means the reviewed artifact itself ran through a real entry point.

Running a tool to read the artifact, testing against a mock, compiling, or a dry run are inspection.

A verb list cannot settle those cases and two seats will classify them differently.

Where it could not exercise something, it names the gap and why. **A named gap is a limit of the

ENVIRONMENT, not a licence for a limit of EFFORT.** "I graded this by reading because running it

would take the fleet down" is a boundary on what is knowable; "I did not get to that part" is a

boundary on what was attempted, and the two must never be written in the same words.

A blocking finding must enumerate the attacks that FAILED. Without the survey, one success reads

as a lucky hit; with it, the finding is a surveyed surface with one hole, and the fixer learns which

ground is already covered.

What a cold verdict binds, and who may override it

**A cold verdict is not a veto. It is binding as a question that must be answered at the artifact,

publicly.**

This matters because isolation defends against panel anchoring and not against error anchoring.

If the panel disproved claim C with evidence E, the cold seat may re-derive C and report it with

fresh confidence, and every route back to it is forbidden: showing E is showing findings, saying "C

is settled" is a skipping-instruction, and asking it to recheck is confirmation framing.

The resolution never required talking to the seat:

  • **A manager may override only if it neither authored the change nor graded or supervised the

panel.** It verifies the claim against the artifact itself and publishes the refutation with its own

evidence, under its own name, leaving the cold finding standing in the record beside it. Nothing

flows back to the seat, so isolation holds; the override is auditable, so the control survives.

The forbidden act is a PRIVATE override, not an override.

  • An author may not override a cold verdict on their own change. They may fold it, or request a

fresh permitted stand-in, who overrides publicly under their own name. Publication separates

override from launder only when the publisher and the accused are different parties: an author

refuting a finding about their own work has produced a document, not a check.

  • A permitted stand-in is an independence test, not a signature. It had no part in authoring,

grading or supervising the change, never shares a model family with the author, and verifies the

claim at the artifact without the author's account of it as input. A coordinator may provision

a fresh referee in an isolated worktree and

give it only the artifact, the finding and the exact sha; whoever provisions the referee does not

thereby become the referee. A prior panelist, lane manager or supervising coordinator is not a

stand-in. A clean byline on the author's reasoning is the original hole with a different name.

  • Every public refutation names the exact sha it answers and closes the blocker only at that sha.

A moved head requires a new verification and a new public record; a refutation is never carried

across a sha any more than a verdict is.

  • **A cold blocker is closed by the seat's own APPROVE or by a permitted public refutation, and by

nothing else.** Any completion gate must first require a landed terminal verdict, APPROVE or named

blockers, before it evaluates closure. A silent, failed, or non-verdict lifecycle cannot pass on an

empty finding set. After that prerequisite, the gate must accept both closure routes. A gate that

demands the seat's approval alone deadlocks the override the first time it is used correctly,

because the seat is one-delivery and may never be told to reconsider: the only exits left are

satisfying a finding that was just publicly refuted, or a zero-delta re-pin to manufacture an

approval, which is laundering.

When the vendor set is short

Availability is a property of the moment, not of the vendor: the same model has joined and delivered

one hour and failed to join the next, on the same host with the same tooling. **A rule that can be

broken by the clock gets quietly ignored rather than obeyed**, so the requirement is ordinal, never a

headcount.

The property: no two seats whose agreement is load-bearing may share a model family, and the cold

seat must not share a family with whoever wrote the change.

Degrade in this order, most expendable first: panel-internal separation, then cold-versus-panel

separation, and never cold-versus-author.

The floor is a refusal, not a degradation. A cold read whose seat shares a family with the author

is not a cold read and must not be recorded as one. Below the floor the review does not run and says

so, because a silently-degraded panel is precisely a fallback: it returns a verdict shaped like a

full one.

Name a collision mechanically, never apologetically. Not "vendors were short so this may be

weaker", which a reader cannot act on. Instead: "seats X and Y are both family F, so any finding they

agree on is one observation and not two, and the class left uncovered is *what only a different

family would have framed*."

Grade the artifact, never the account of it

  • A reported sha is a claim. Resolve a PR or branch head from its Git ref first, for example

git ls-remote origin refs/pull/<n>/head, then positive-control the object with git cat-file -t.

Use a known-missing full-width object id as the negative control, for example forty zeroes. Do not

append a character to a valid object id: Git accepts an overlong hex string when its leading full

object id resolves, so that apparent negative can return the original object and pass falsely.

Fetch the exact ref first if that object is not local. When a PR exists, cross-check with

gh pr view <n> --json headRefOid rather than treating it as authority: a head field can lag after

a push, while a mergeability field may be answering a different strategy question. A branch-only

lane has no PR API cross-check; gh pr view <branch> may select an old closed PR and is not a

substitute. If two instruments disagree, reproduce the exact question each asks before calling

either one stale. Re-resolve the ref when you grade and again if you act.

  • A measurement over a mutable ref is only true as of a revision. Report it as "at <sha>, read

<time>". A ref name is not an identifier.

  • A quoted argument is not the call's arguments. Diagnose from the recorded entry, not from prose

describing it, including your own.

  • A green from a check that structurally cannot see the failure reads exactly like a real green.

Ask what question the check actually answers.

  • Positive-control the instrument before believing a zero. A path that does not exist returns a

clean zero, indistinguishable from an unmodified one.

  • A count is not a set. Quote the set.
  • Evidence built the same way as the bug inherits the bug's blind spot. A checker configured like

the thing under test cannot detect a divergence between "configured like" and "actually used".

Re-grades

  • A one-delivery limit must carry an explicit written exception for a re-grade, or a re-pin

silently becomes a verdict the seat forms and never posts, leaving a stale block on the record

against a head that no longer exists.

  • Never carry a verdict across a sha. Re-pin, or revert to the graded head.
  • Base freshness matters when the base delta INTERSECTS the graded surface. Compute the

intersection rather than rebasing reflexively or accepting reflexively.

  • For a delta re-grade, name the scope boundary. A reviewer that has to guess where its licence ends

will either re-audit everything or stop too early, and the verdict will not say which.

Which of these are controls, and which are norms

Stated plainly, because a norm presented as a control is the false assurance this whole discipline

exists to prevent:

  • Controls, mechanically enforced while the seat runs: a read ACL that excludes the panel

channel, the pinned model and effort, and broker-attested poster identity on a dedicated Cotal

record channel. The sha named in

the verdict and the destination it landed on are retrospective evidence. A later stranger can call

non-join auditable only when launch-time ACL evidence was retained; a current subscription snapshot

cannot prove historical non-join, and a GitHub comment says nothing about channel membership.

  • Norms, resting entirely on the briefer's discipline and not auditable after the fact: that the

brief carried no findings, no diagnosis and no confirmation framing, and that a file destination

was written by the seat rather than by the manager.

There is no artifact proving a brief was clean. That is why the briefer, and not the seat, is the

party this file addresses.

When to spend a cold seat

Worth it: security-sensitive surfaces, hard-to-reverse changes, anything where the panel converged

fast, anything you wrote yourself, and any change to the rules by which other work is graded.

Not worth it: a typo, a version bump, a change whose entire surface one reviewer can hold.

The cold seat is a second axis, not a fourth panelist: it does not substitute for panel breadth and

panel breadth does not substitute for it.

The failure modes

  • Anchoring by kindness. Telling the seat what has been ruled out, to save its time.
  • Anchoring by vendor. Seating it on the same family that wrote or graded the change.
  • Laundering. Reporting a head as reviewed when the verdicts name a superseded commit.
  • Relay. Someone else posting the verdict on its behalf.
  • Vacuous completion. Applying blocker-closure logic before a terminal APPROVE or named-blocker

verdict has landed, so a silent or failed seat appears to have no open findings.

  • Confirmation framing. Any question answerable by agreeing.
  • Self-certification. An author publishing a refutation of a finding about their own work.

How to use it

Copy the folder

Take cotal-ai/cold-review from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.