# Teamwork Review

> Use when the user asks to review, audit, critique, or validate a stable code, document, plan, artifact, or claim; do not use to diagnose an unknown failure or create the initial candidate.

- Skill: `jinplu/teamwork-review` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add jinplu/teamwork-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jinplu/teamwork-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: JinPLu (https://skillmd.com/u/jinplu)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jinplu/teamwork-review

---


# Teamwork Review

Review judges one stable candidate against supplied requirements and direct
evidence. Prefer an independent Reviewer when the host can provide one. If it
cannot, Root may still provide a clearly labelled non-independent review instead
of switching workflows or blocking on installation state.

## Method

1. Identify the actual candidate, requirements, scope, settled constraints, and
   direct evidence needed for a verdict.
   Criteria include standing constraints from the project's always-read
   instruction surface and the global policy, not only the requirements supplied
   with the request. A violation of a standing constraint is a finding with
   severity, even when the supplied requirements do not mention it.
2. Read the candidate and applicable primary evidence. Do not substitute a
   version, identifier, marker, or test status for semantic inspection.
3. Always judge outcome fit. Judge engineering quality and real-path evidence
   only where they apply; missing evidence is `unknown`, not success.
4. Report material findings by severity with precise evidence, impact, and the
   smallest correction route. Keep unrelated debt separate.
5. Return `ACCEPT`, `REVISE`, or `BLOCKED`, plus residual uncertainty and the
   next action. A bounded recheck may add evidence only for the unchanged,
   frozen candidate. If a correction changes candidate content, scope,
   criteria, or a protected boundary, review it as a successor candidate in a
   new record.

A protected boundary is a requirement, criterion, candidate identity, or
behavior that must remain unchanged for this review record to stay valid.
Example: the public API contract or the frozen acceptance criteria. Keep one
review record per stable candidate identity. Any correction that changes
candidate content, scope, criteria, or a protected boundary creates a
successor candidate and a new document rather than overwriting the verdict
basis of the old candidate. The old record may receive only an
owner-certified successor link; its findings and verdict remain unchanged.
Preserve the candidate identity, criteria and protected boundaries, direct
evidence, findings and severity, status of each criterion, verdict, residual
uncertainty, and evidence-only bounded recheck scope.

A Reviewer handoff names the frozen candidate, requirements, and requested
verdict. Reviewer remains read-only and never implements the repair.

## Persistence

When a listed checkpoint fires, write in the same response cycle. If separate
stable identities each cross a checkpoint, write each to its own path.

Cross-chat memory lives in one Markdown document from `references/review.md`
at `docs/teamwork/reviews/<slug>.md`. Same identity means the same
candidate; reuse that path and name the document you read. A different subject
gets a new path.

Checkpoints: a verdict is returned; a bounded recheck adds evidence only for
the unchanged frozen candidate; or a successor candidate is opened after a
protected-boundary change. Changed content, scope, criteria, or protected
boundaries belong to a successor candidate in a new review document.