Agent skill

Cold Review

by Cotal-AI in Cotal-AI/Cotal

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.

Apache-2.0Auto-check passedAgent Workflows

Install Cold Review

skills CLI
$ npx skills add Cotal-AI/Cotal --skill cold-review -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install Cotal-AI/Cotal cold-review --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/Cotal-AI/Cotal.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/cold-review .claude/skills/cold-review && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
cold-review
GitHub stars
322
Token cost
~4.2k tokens
SKILL.md length
2,698 words
Files
1
Skills in repo
5
Repo updated
First seen
Licence
Apache-2.0

At a glance

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.

  • A panel has reached consensus and you want a second opinion consensus cannot anchor
  • SKILL.md covers The isolation, What the brief contains, Where the verdict goes and What the verdict says, plus 7 more sections
  • Calls git and gh
  • A change is security-sensitive

What it does

Cold Review is an agent skill from Cotal-AI/Cotal. 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…

Its SKILL.md is about 4.2k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Agent Workflows. It works with Model Context Protocol. The repository describes itself as: The open standard for agent coordination. The licence is Apache-2.0.

When your agent uses it

  • A panel has reached consensus and you want a second opinion consensus cannot anchor
  • A change is security-sensitive
  • Hard to reverse
  • You are the author and therefore the worst available reader of your own work

Example prompts

  • “/cold-review”

What it can do on your machine

Read from SKILL.md and the folder at commit a64403e. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git
    • gh

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git and gh, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Cold Review loads about 4.2k tokens when it runs. Until then it costs about 151 tokens; SKILL.md has 2,698 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~151
When it runs · the whole SKILL.md, loaded when a task matches
~4.2k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from Cotal-AI/Cotal at commit a64403e, republished under its Apache-2.0 licence (© Cotal-AI). 2,698 words, ~4,234 tokens.

Download SKILL.mdSave it as .claude/skills/cold-review/SKILL.md (or your agent's skills folder).
name
cold-review
description
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.

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.
Show full SKILL.md (994 more words)Show less

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.

© Cotal-AI, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .claude/skills/cold-review of Cotal-AI/Cotal.

Open the folder on GitHubat commit a64403e

Compare with similar skills

Cold Review next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Cold Review compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Cold Review this skillCotal-AI/Cotal322—~4.2kAutomated safety check: PassApache-2.0
MCP Server Builderanthropics/skills180k63 repos~2.3kAutomated safety check: PassApache-2.0
MCP Server BuildershareAI-lab/learn-claude-code78k4 repos~1.2kAutomated safety check: PassMIT
MCP Integration for Pluginsanthropics/claude-plugins-official38k11 repos~3.1kAutomated safety check: PassApache-2.0
MemPalace Memory SearchMemPalace/mempalace60k—~1.4kAutomated safety check: PassMIT
Crush Configurationcharmbracelet/crush29k—~3.7kAutomated safety check: PassCustom licence

Similar skills

  • MCP Server Builder

    anthropics/skills

    Official

    Guides the design and implementation of Model Context Protocol servers in TypeScript or Python, from tool naming and error messages to evaluation.

    180k GitHub starsUsed in 63 repos~2.3k tokens
    Agent WorkflowsAuto-check passed
  • MCP Server Builder

    shareAI-lab/learn-claude-code

    Walks through building MCP servers in Python or TypeScript that expose tools, resources and prompts to Claude, with templates, registration and testing.

    78k GitHub starsUsed in 4 repos~1.2k tokens
    Agent WorkflowsAuto-check passed
  • MCP Integration for Plugins

    anthropics/claude-plugins-official

    Official

    Explains how to bundle Model Context Protocol servers in a Claude Code plugin, covering config files, stdio, SSE, HTTP and WebSocket server types, and authentication.

    38k GitHub starsUsed in 11 repos~3.1k tokens
    Agent WorkflowsAuto-check passed
  • MemPalace Memory Search

    MemPalace/mempalace

    Mines project files and conversation exports into a local, searchable memory palace and recalls past work by semantic search through the mempalace CLI.

    60k GitHub stars~1.4k tokensUpdated today
    Agent WorkflowsAuto-check passed
  • Crush Configuration

    charmbracelet/crush

    Explains how to configure the Crush coding agent with crushrc or crush.json, covering providers, models, LSPs, MCP servers, hooks, permissions and config precedence.

    29k GitHub stars~3.7k tokensUpdated today
    Agent WorkflowsAuto-check passed
  • Context Mode Output Sandbox

    mksglu/context-mode

    Routes large command, file, API and browser output through context-mode tools so only the needed result enters the agent's context, instead of dumping it via Bash.

    26k GitHub stars~4.1k tokensUpdated today
    Agent WorkflowsAuto-check passed

More from Cotal-AI/Cotal

  • Cotal Setup

    Cotal-AI/Cotal

    Set up Cotal on this machine: install it, start a local agent mesh (NATS + JetStream), verify it, and put an agent on it.

    322 GitHub stars~442 tokensUpdated today
    Auto-check passed
  • Pixel Face

    Cotal-AI/Cotal

    Create or improve a 32×32 pixel-art persona face for the Frontier Faces demo (examples/04-frontier-faces/personas.mjs) — the animated agent avatars rendered by face-term.mjs / the browser…

    322 GitHub stars~1.5k tokensUpdated today
    Auto-check passed
  • Team Topology

    Cotal-AI/Cotal

    Define a multi-agent team for ANY task on ANY system as an explicit deployment topology - pick the shape from the task's dominant risk, specify the runtime/communication/trust layers, place model…

    322 GitHub stars~2.9k tokensUpdated today
    Auto-check passed
  • Run several independent Cotal features concurrently by creating one Git worktree and one spawn-capable mesh manager per feature; each manager staffs a review panel in a dedicated channel, adds one…

    322 GitHub stars~5.3k tokensUpdated today
    Auto-check passed

Categories

Questions about Cold Review

What does Cold Review do?

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. Cold Review is an agent skill from Cotal-AI/Cotal. 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.

When should I use Cold Review?

Cold Review fits situations like: A panel has reached consensus and you want a second opinion consensus cannot anchor; A change is security-sensitive; hard to reverse; you are the author and therefore the worst available reader of your own work.

How do I install Cold Review in Claude Code?

Run `npx skills add Cotal-AI/Cotal --skill cold-review -a claude-code`. Or copy the skill folder (.claude/skills/cold-review in Cotal-AI/Cotal) into .claude/skills/cold-review in your project. Claude Code loads it when a task matches its description.

How do I install Cold Review in Codex?

Run `npx skills add Cotal-AI/Cotal --skill cold-review -a codex`. Or copy the skill folder (.claude/skills/cold-review in Cotal-AI/Cotal) into .agents/skills/cold-review in your project. Codex loads it when a task matches its description.

Can I use Cold Review in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add Cotal-AI/Cotal --skill cold-review -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/cold-review, .gemini/skills/cold-review, .github/skills/cold-review and .opencode/skills/cold-review in your project.

What does Cold Review need to run?

Going by SKILL.md and its folder, Cold Review needs the command-line tools its instructions call (git and gh).

Does Cold Review access the network?

SKILL.md contains no URLs. Its commands use git and gh, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Cold Review safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Cold Review use?

Cold Review is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Cold Review use?

About 4.2k tokens (SKILL.md is roughly 17k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Cold Review?

Skills that share tags, products or a category with Cold Review: MCP Server Builder (anthropics/skills, 180k stars), MCP Server Builder (shareAI-lab/learn-claude-code, 78k stars), MCP Integration for Plugins (anthropics/claude-plugins-official, 38k stars) and MemPalace Memory Search (MemPalace/mempalace, 60k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Cold Review?

Cotal-AI (a GitHub organization) maintains it in Cotal-AI/Cotal, which has 322 GitHub stars. The repository holds 5 skills in this directory. The repository was last updated on October 11, 2026.

Source: Cotal-AI/Cotal on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.