Review panel
Quality gates for Claude Code: review-panel, focus-group pretesting, STORM research, extract-approach, and the advisor agent. The foundational skill pack behind an AI-operated multi-business setup.
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.
2 things to look at
- 14 days oldThe repository was created 14 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 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.
What its author says it does
Copied from the file, not written here
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.
SKILL.md
4.3 KB, 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