review-workflow

An off-context workflow script for reviewing code with several review agents. It sends their findings through filtering, deduplication, verification, and aggregation before returning the final report.

In plain words
What is it for?
Use it as the workflow behind `/lets:review --workflow` when you need parallel code reviews combined into one checked and sorted result.
Why use it?
It keeps intermediate agent reports out of the conversation and organizes conflicting or repeated review findings. It also checks serious findings with additional skeptical reviewers.

Skill for Claude CodeCodex

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add skills/restarter/lets-workflow/review-workflow
Any agent
npx skills add restarter/lets-workflow --skill review-workflow
Clone the repo
git clone --depth 1 https://github.com/restarter/lets-workflow

Made for: Claude Code, Codex.

Per session 56 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 1,582 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00056 $0.01582
Opus 5 $0.00028 $0.00791
Sonnet 5 $0.00011 $0.00316
Haiku 4.5 $0.00006 $0.00158

Measured 2d ago against content hash 75b2fa4a2a1e, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

review-workflow scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

The scan reads SKILL.md. This mod also ships 1 executable file (review.workflow.js), listed below but not scanned — reading those needs a real analyzer, not pattern matching.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

plugins/lets/skills/review-workflow/SKILL.md · 62 lines

How it starts

The opening of the file, as written. The whole thing — 62 lines — stays where its author put it; the contents beside it link to each section on GitHub.

review-workflow (Dynamic Workflow asset)

This folder is the reference example of the Dynamic Workflow asset standard (see CLAUDE.md -> "Dynamic Workflow assets"). It is NOT a conversational skill: review.workflow.js is executed by the Workflow tool, invoked from /lets:review's Workflow Mode via:

Workflow({ scriptPath: "${CLAUDE_PLUGIN_ROOT}/skills/review-workflow/review.workflow.js", args })

${CLAUDE_PLUGIN_ROOT} is substituted at command-load time, so review.md carries the literal absolute path. Treat review.workflow.js as a template the command points at, not a script to reproduce inline.

What it does (off-context)

A multi-stage chain so per-agent reports never enter the conversation - only the final aggregate returns:

  1. Review - fan out the selected lets:<name> review agents in parallel (structured FINDING_SCHEMA output).
  2. Reduce - split systemic (any tier) into its own section, NIT-filter the rest (unless small diff), dedupe (keep highest tier), sort by tier.
  3. Verify - for each BLOCKER/SUGGESTION, fan out lets:skeptic agents (2, or 3 for BLOCKER) to refute it. Apply the asymmetric drop rule: SUGGESTION drops on a simple majority real=false; BLOCKER drops only on near-unanimous high-confidence refute, otherwise downgrades. Count refuted.
  4. Aggregate - verdict over the verified set, per-agent summary, counts.

args contract (built by the command, passed as a JSON value)

key type meaning
agents [{name}] selected review agents (short names, no lets: prefix; exclude actor)
mode string PR-{n} | local-review | branch-review | file
projectRoot string absolute project root (agents must not read outside it)
claudeMd string CLAUDE.md context
changedFiles string changed-file list with stats (or single path for --file)
code string the diff (or full file content for --file)
smallDiff bool true keeps NIT findings (diff < 50 lines)
systemicCheck bool false for --file (no diff baseline)
spec string task description from the tracker's show (or the PR body); empty when unavailable - never a sentinel. Drives specBlock in the review prompt, and specBlockSkeptic in the verify prompt - the latter ONLY outside PR mode, since a PR-mode spec is the PR author's own task or plan file and a skeptic's real=false is a deterministic drop. No flag: PR mode is derived from mode, so it cannot be forgotten. Normalized in the script (non-string/whitespace-only → empty, 150 lines / 8000 chars, BEGIN/END SPEC delimiters inside the value neutralized on both sides - across every Unicode dash and with format characters stripped first - so it cannot escape its own fence)
specSource string where spec came from, per the command's Step 2.5 question: task | file | none | unresolved. Only none vs unresolved changes rendering, and the difference matters: none is the user saying no spec exists, so NO spec block is emitted at all; unresolved is a failed lookup, which still gets the "none reached this review" block because something may exist that we failed to read
prBody string the PR's own description, empty outside PR mode. Sanitized by the same fenced() as spec, 150 lines / 8000 chars
prDiscussion string the PR's gathered discussion - issue comments + non-empty review bodies + inline threads - empty outside PR mode. Same fenced(), 400 lines / 20000 chars: a discussion is legitimately longer than a spec. Kept SEPARATE from prBody so the script can label each half; merging them would make "what the author says" unattributable
Both drive prContextBlock in the review prompt and nothing else. There is no skeptic counterpart by design: every word is written by the author of the code under judgement or by people commenting on it, and a skeptic's real=false is a deterministic drop. Like the spec in PR mode, there is no trusted case to carve out and therefore no flag to forget
prTree bool does the working tree hold the reviewed code? true for all non-PR modes and for PR mode after a checkout; false adds a REVIEW TREE warning to both prompts. Omitted on a PR-* mode is treated as false - failing toward "the tree may be wrong" rather than silently trusting it

Read the full file on GitHub · 62 lines

Files

What ships with it

1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 62 lines · 56 tokens per session scan A 75b2fa4a2a1e

Subscribe to this mod's changes

review-workflow is a skill published in the GitHub repository restarter/lets-workflow (17 stars, last pushed 9d ago), licensed MIT. It adds 56 tokens to every session and 1,582 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.

Related

Other skills, from other repositories

systematic-debugging

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.

obra/superpowers · 21 tokens

brainstorming

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

obra/superpowers · 37 tokens

chat-pet-sprite-creation

Use when creating or changing VS Code chat pet sprite art, sprite sheets, state animations, eye treatments, Stable/Insiders variants, or pet transitions under src/vs/workbench/contrib/chat/browser/widget/media/chatPet.

microsoft/vscode · 53 tokens

cpu-profile-analysis

Analyze V8/Chrome CPU profiles (.cpuprofile) and DevTools trace files (Trace-.json). Use when: profiling performance, investigating slow functions, comparing code paths, finding bottlenecks, analyzing timeToRequest, understanding call trees from sampling profiler data, analyzing layout/paint/rendering, investigating…

microsoft/vscode · 71 tokens

babysit-pr

Babysit a GitHub pull request after creation by continuously polling review comments, CI checks/workflow runs, and mergeability state until the PR is merged/closed or user help is required. Diagnose failures, retry likely flaky failures up to 3 times, auto-fix/push branch-related issues when appropriate, and keep…

openai/codex · 114 tokens

imagegen

Generate or edit raster images when the task benefits from AI-created bitmap visuals such as photos, illustrations, textures, sprites, mockups, or transparent-background cutouts. Use when Codex should create a brand-new image, transform an existing image, or derive visual variants from references, and the output…

openai/codex · 113 tokens