Review panel
Use when any substantive work product has been generated — copy, emails, documents, proposals, plans, code, designs, skills, newsletters — and is about to be delivered, shipped, marked done, or given a quality verdict. Also use when the user asks for a review or critique of existing work. Trigger BEFORE declaring anything ready or presenting it as finished.From its SKILL.md
npx -y skills add josherau/claude-operating-core --skill review-panelAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
4.3 KB, 888 tokens by cl100k_base, as published. Nobody here has run it
Review Panel
Overview
The maker never grades its own homework. The agent that produced work never decides it's ready — a panel of independent, hard-to-please reviewer subagents grades it against documented standards first. A model reviewing its own output is structurally compromised: it reuses the same reasoning that produced the work, forgives the gaps it already knows about, and mixes maker-knowledge into the verdict ("I couldn't verify X, so I left it out" is the maker lobbying, not a review). Self-reflection inside the maker plus independent graders outside it stack; neither replaces the other.
The Iron Rule
No READY / done / ship verdict on self-generated work without independent panel verdicts. Not for small artifacts, not under time pressure, not because the self-review "already found the issues."
Process
- Fix the standards first. Find the documented standards the work must meet (project docs, skill checklists, brand voice, user requirements). None written? Extract a checklist from the user's request before empaneling — reviewers grade against a checklist, not vibes.
- Empanel 2–4 reviewers with distinct lenses. Each is a fresh subagent that receives ONLY: the task brief, the artifact, the standards, and its reviewer charge. Never the maker's reasoning, self-evaluation, or "known limitations."
- Reviewer charge (include verbatim): "You are a hard-to-please reviewer. Your job is to find reasons this fails the standards, not to appreciate it. Grade each standard PASS/FAIL with evidence. Uncertain → FAIL. End with verdict: SHIP or REVISE, plus your top 3 specific objections."
- Iterate. REVISE verdicts go back to the maker with the objections; revise; re-run the failed reviewers on the new version. Max 3 rounds — then deliver to the human with unresolved objections attached. Run reviewers in the foreground and collect every verdict before proceeding — never end your turn while reviewers are still running.
- Report. Deliver the work with panel verdicts and what changed per round. Never present panel-less work as finished.
Default panels by work type
| Work | Lenses |
|---|---|
| Copy / emails / marketing | standards checker · target-reader skeptic (would THIS person reply?) · AI-tell hunter |
| Docs / proposals / reports | requirements-compliance checker · hostile evaluator scoring as the recipient · clarity editor |
| Plans / strategies | feasibility engineer · value skeptic (why does this matter?) · risk finder |
| Code | correctness · simplicity/maintainability · edge cases + security — or route to your code-review tooling (/review, /code-review, or a second-model reviewer) |
| Research | source verifier · missing-perspective finder (storm-research Phase 4 is self-critique — still empanel) |
Scaling: 1 reviewer minimum for small-stakes artifacts; the full panel is the default; high-stakes work adds a second-model reviewer (a different vendor's model, if you have one wired up).
Rationalization table
| Excuse | Reality |
|---|---|
| "I already critiqued it myself, honestly" | The baseline failure. Self-review reuses the maker's blind spots and forgives known gaps. |
| "It's small / just a draft" | Small artifacts get 1 reviewer, not zero. Anything shown to the human is a deliverable. |
| "User is waiting / time pressure" | A reviewer round takes 1–2 minutes. Shipping unvetted work costs more. |
| "The model self-validates at high effort" | Self-validation makes the maker honest inside its role; the independent grader sits outside it. Stack both. |
| "Reviewers will just agree with me" | Then the charge is too soft — a reviewer that never FAILs anything is broken; re-charge it. |
Red flags — stop and empanel
- About to type "READY", "done", "ship it", or a self-assigned quality score
- Writing a "quality evaluation" section about your own output
- Passing your own caveats or justifications along to a reviewer
- Skipping re-review after revising
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most review quality skills give in 888 tokens
Counted across 1,273 of the 2,403 authors here whose files we hold, read 2026-09-06
- Ask one question at a timein 63 of 1273, across 62 files
- Provide a recommended answer for each questionin 47 of 1273, across 45 files
- Rank findings by severityin 44 of 1273
- Use parameterized queries for database accessin 38 of 1273, across 20 files
- Validate all user input with schemasin 33 of 1273, across 15 files
- Store secrets in environment variablesin 32 of 1273, across 14 files
- Explore the codebase to answer questionsin 31 of 1273, across 29 files
- Store tokens in httpOnly cookiesin 30 of 1273, across 12 files
- Implement rate limiting on API endpointsin 30 of 1273, across 12 files
- Sanitize user-provided HTMLin 29 of 1273, across 11 files
- Return generic error messages to usersin 28 of 1273, across 10 files
- Cite file and line for every findingin 28 of 1273, across 25 files
Said here and by no other author read
- extract a checklist from user requirements before reviewing
- empanel two to four reviewers with distinct lenses
- provide reviewers only the brief, artifact, and standards
- use the mandatory reviewer charge verbatim
- grade each standard as pass or fail with evidence
- treat uncertainty as a fail
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.