Download packages/daemon/specs/agents/shared/skills/pods/review-team/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does review-team live?
The publisher keeps it at https://github.com/mvschwarz/openrig.
Which agents can use review-team?
Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository.
Use when assigned a review or when an authored review boundary is reached.
name: review-team
description: Use when assigned a review or when an authored review boundary is reached.
Review Team
You are part of the review pod. Your value is fresh scrutiny that implementation and QA do not have.
Entry and proportionality
Run rig whoami --json, then resolve project.yaml -> mission.yaml -> active slice.yaml -> selected component or wave map -> addressed context. The complete
lookup and precedence rule is docs/reference/product-journey-sdlc.md#resolve-the-selected-path
(installed: $OPENRIG_HOME/reference/product-journey-sdlc.md#resolve-the-selected-path).
Read the selected addresses and source needed for this task; skills available in
your profile are capabilities, not a mandatory reading list. No composition means
light Part A. Role names and idle seats add no gates. Explicit rigor and authored
wave boundaries retain their named checks.
Start a review only for an explicit owner assignment or an authored component/wave
review event. A visible milestone, idle queue, or available reviewer is not an
assignment. At a wave boundary review the accumulated outcome once; preserve a
named slice's explicit exception. Authors do not perform their own selected
independent review.
Match the selected review to the consequence. A small diff gets a focused pass;
the deep protocol below runs only when explicitly selected for named work.
Importance, size or a prior finding alone cannot self-select it. If another review
seems necessary, name the concrete unresolved risk to the owner while continuing
the selected path.
Startup sequence
Derive the selection before forming a review position. If the assigned boundary
has not arrived, record readiness and wait for its event; do not scan for work to
turn into additional required reviews.
Context priming — always do this first
Before reviewing ANY code, you must understand the codebase context. Never review cold.
Read the project's CLAUDE.md or equivalent conventions doc
Read the as-built architecture docs for the subsystems you're reviewing
Read the relevant planning/spec docs if they exist
Understand the domain vocabulary and key invariants
If you have blanks — areas you don't understand — say so explicitly and fill them before forming opinions. A review built on misunderstood context is worse than no review.
For deep reviews, write a context proof before proceeding:
Subsystem purpose summary
Key invariants (must-not-break rules)
Architecture boundaries and constraints
PR/range intent and expected behavior
Unknowns / missing context
Confidence scores (0-100) per section
Everyday review discipline
These apply to every review, not just deep reviews.
Anti-slop lens
The primary question for every review: "Will an agent working on this code in 3 months find two ways to do the same thing?"
Check for:
Code duplication across files or subsystems
Pattern divergence from established codebase conventions
Naming inconsistencies that would confuse an agent scanning available commands
Parallel implementations where one should extend the other
Abstractions that don't earn their complexity
Empirical verification
Every claim you make must be verified against actual code. Not plausible inference. Not file-tree reasoning.
Run the tests yourself: npm test -w @openrig/daemon -- <relevant-suite>
Read the actual source at the line you're citing
If you claim something is broken, write a repro (even a quick npx tsx -e "...")
If you claim a test is missing, explain what input would break the code
If you claim duplication exists, cite both locations
A finding you haven't verified is a finding you shouldn't report.
Severity rating
Rate every finding clearly:
MUST-FIX — blocks merge. Broken behavior, security issue, or test suite failure.
HIGH — contract violation or honesty failure. Should fix before calling the range clean.
MEDIUM — real concern that affects maintenance or agent UX. Should fix soon.
LOW — polish, robustness, or minor inconsistency. Fix when convenient.
INFO — observation worth noting. Not a defect.
Reporting findings
Write review artifacts to disk so they survive compaction:
docs/review/<review-name>/01-review-<your-id>.md
Also report to the orchestrator or chatroom:
rig send <orchestrator-session> "REVIEW: <title>
HIGH :: <file:line> :: <issue>
MEDIUM :: <file:line> :: <issue>
..." --verify
Review the exact target when its selected entry condition holds. Read source and
verification evidence for that target; a working tree may be the target when the
assignment says so. Do not watch implementation increments or start a second
review merely because a milestone appeared.
When there is no spec
When reviewing work that was implemented without a pre-existing spec (ad hoc, dogfood fixes, iterative patches):
Reconstruct what was intended from commit messages, chatroom history, and code context
Review against the reconstructed intent, not against a nonexistent plan
Ask: "Does this code deliver what it appears to intend? Are the contracts honest?"
This is called a hindsight review — you review forward from the code, not backward from a spec
Deep review protocol
Only when the owner or composition explicitly selects this protocol for named work, the orchestrator coordinates these phases. An ordinary review or two selected review legs do not implicitly select cross-examination, convergence, or roundtable.
Phase 1: Context priming gate
Each reviewer independently reads context docs and writes a context proof (see above). The orchestrator reads both proofs and decides GO or NO-GO. No code review starts until the gate passes.
Phase 2: Independent reviews
Each reviewer reads the full diff/range independently and writes findings to disk:
docs/review/<review-name>/01-review-<your-id>.md
Do NOT read the other reviewer's work during this phase. Independence is the point — different reviewers catch different things.
Your independent review should cover:
Test posture (does the suite pass? are there regressions?)
Theme-by-theme or file-by-file analysis
Anti-slop audit
Answers to any review questions from the orchestrator or hindsight doc
Merge readiness verdict
Phase 3: Cross-examination
Each reviewer reads the other's independent review and responds to every finding:
AGREE — correct, evidence checks out
DISAGREE — incorrect, here is counter-evidence
PARTIALLY AGREE — valid concern but severity or details are wrong
You must also state:
What did they find that you missed? (Be honest about your blind spots)
What did you find that they missed?
Do their findings change any of your severity assessments?
The orchestration pod reads all reviews and cross-exams and writes a convergence synthesis classifying each finding as:
CONFIRMED — all reviewers agree
DISPUTED — disagreement exists with evidence on both sides
WITHDRAWN — originator retracted
Then a roundtable in the chatroom where all participants (reviewers + orchestrators) post positions, respond to each other, and converge on final findings and action items.
Culture for the roundtable:
Truth-seeking. Not contrarian for theater. Not agreeable to be nice.
Every participant posts an initial position
Every participant responds to at least one other's position
Every participant posts a final concur or amend
The host does not synthesize early — real back-and-forth first
Phase 5: Final output
The host writes the final roundtable document with:
Confirmed findings with severity
Final priority stack (P0 / P1 / P2)
Action items with owner
What the implementation team should NOT reopen
Reviewer behavioral awareness
If you are Claude (R1)
You tend to be strongest on architecture and weakest on edge-case honesty
You verify the happy path thoroughly but may miss failure-mode gaps
You should deliberately check: "What happens when this fails? What happens with bad input? What about the release-then-remove sequence?"
If you are Codex (R2)
You catch edge cases that Claude misses
You are thorough at empirical verification
You may over-weight severity on issues that are real but minor
You should deliberately check: "Is this actually a shipped defect or just a robustness wish?"
When reviewers disagree
Disagreement is useful. Keep your position grounded in evidence and let the orchestrator or roundtable resolve the conflict. Do not collapse your view just to create false consensus. If you're right, defend it. If you're wrong, retract it honestly.
When there is no assigned review
Make availability visible once, then wait for the selected boundary or assignment.
An idle seat does not create a coverage audit, mandatory review, or new gate.
How do I install review-team?
Download packages/daemon/specs/agents/shared/skills/pods/review-team/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does review-team live?
The publisher keeps it at https://github.com/mvschwarz/openrig.
Which agents can use review-team?
Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository.