Claude Skill

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.

LLM Mart · 0 points · 0 0 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download jinplu-teamwork-skills_teamwork-review-8f23dcd.zip · 2 KB

jinplu/teamwork 12 0 forks MIT Updated 9d ago

Part of jinplu/teamwork — 8 skills

Install

skills CLI npx skills add https://github.com/JinPLu/Teamwork/tree/main/skills/teamwork-review

Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install jinplu-teamwork@llmmart

Git git clone https://github.com/JinPLu/Teamwork.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole jinplu/teamwork collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

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

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.
Read the candidate and applicable primary evidence. Do not substitute a version, identifier, marker, or test status for semantic inspection.
Always judge outcome fit. Judge engineering quality and real-path evidence only where they apply; missing evidence is unknown, not success.
Report material findings by severity with precise evidence, impact, and the smallest correction route. Keep unrelated debt separate.
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.

Files (teamwork)

agents

openai.yaml 229 B

interface:
  display_name: "Teamwork Review"
  short_description: "Evaluate code, documents, plans, and claims"
  default_prompt: "Use $teamwork-review to independently evaluate this candidate against its evidence and criteria."

references

review.md 1.5 KB

---
status: active
superseded-by:
created: <YYYY-MM-DD>
updated: <YYYY-MM-DD>
---

# Review: <candidate>

## Current synthesis

<frozen candidate, scoped verdict, decisive basis, and unresolved items>

## Candidate identity and review contract

- Frozen candidate: <version/content identity>
- Authoritative owner and independence: <review owner; independent or labelled non-independent>
- Scope and exclusions: <reviewed and excluded surfaces>
- Successor: <owner-certified link, or none>

## Criteria and protected boundaries

<requirements, criteria, standing constraints with their source, candidate identity, and behavior that must not change>

## Direct evidence

<actual candidate evidence and observed verification>

## Findings

| Severity | Finding | Precise evidence | Impact / failed criterion | Smallest correction |
| --- | --- | --- | --- | --- |
| <severity> | <finding> | <direct evidence> | <impact> | <route> |

## Criterion status

| Criterion | Status | Evidence |
| --- | --- | --- |
| <criterion> | <met/not met/unknown> | <direct evidence or gap> |

## Verdict

<ACCEPT, REVISE, or BLOCKED, scoped to this frozen candidate>

## Residual uncertainty and bounded recheck

<unknowns and the smallest additional evidence for this unchanged frozen
candidate>

## History

<Append only. Never rewrite or remove; a correction is a new dated entry.>

### <date/time — semantic change>

<finding, criterion, verdict, evidence-only recheck, or owner-certified
successor-link delta; never rewrite the old verdict for a changed candidate>

SKILL.md 3.3 KB

---
name: teamwork-review
description: 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.
---

# 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.