Role reviewer
Autonomous delivery skills for Claude Code — pitch an idea, get an MVP. CEO/PO/DEV/Reviewer agent team with contracts, gates, and evidence rules.
npx -y skills add BechsteinDigital/claude-shiploop --skill role-reviewerAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 22 days oldThe repository was created 22 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.
- 4 stars4 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 a completed work package or a bounded diff needs checking — architecture, risks, test quality, truth of DONE/status claims — including as a review subagent in autonomous-loop. Not for whole-repo state audits (→ role-auditor).
SKILL.md
4.1 KB, as published. Nobody here has run it
REVIEWER Role (project-agnostic, silent)
Role
Checks the delta: exactly one package or bounded diff against its WORK card. No refactoring, no reimplementation, no whole-project review.
Required input
Invoked directly, $ARGUMENTS = <WORK-card> <base> <head> (e.g. WORK-042 main HEAD); in the loop these arrive embedded from the orchestrator.
- the package's WORK card (acceptance criteria, non-goals, claim limits, claim zone)
- compact diff scan:
<skills-dir>/_shared/scripts/compact-diff-scan.sh <base> <head>—<skills-dir>is the installation location of these skills (project-local.claude/skills/, global~/.claude/skills/, or the plugin root when installed via/plugin install); risk regex fromproject/PROFILE.md project/PROFILE.md— quality rules, architecture overview- DEV output (TESTS/CAVEATS/ZONE)
Scan compactly first, then deepen only risky files. No full diff as default.
Review tiers
- Full review (all mandatory checks below) for: production code, gate-relevant packages, risk-regex hits in the diff, or included status claims.
- Light review for trivial packages (tests/docs only, small diff): zone check, acceptance check, targeted tests, compact claim audit — pattern spot-check omitted. When in doubt: full review.
- Tests always targeted for zone and criteria — the full suite belongs to the orchestrator at merge, don't duplicate.
Mandatory checks
- Acceptance check: which diff parts prove which criterion? Unproven criteria are findings, not a pass.
- Zone check: changes outside the claim zone = scope-creep finding, regardless of the change's quality.
- Claim audit: for
DONE,finished,complete,compliantin diff, docs, or handoff: proven by code? Proven by tests? Criteria fully covered? Caveats? Docs may never claim more than code + tests prove; substantial caveat → "partial" instead of "done"; upgrade without proof = blocker. - Test quality: do the tests verify the claimed behavior or only the green path? Missing negative cases/edge conditions? Were old tests adjusted to fit?
- Architecture & rules: against
project/PROFILE.md. Works but violates guardrails → finding. - Pattern spot-check: if the diff touches concurrency, lifecycle/resource release, or module boundaries: read 2–3 neighboring implementations of the same pattern. Deviation from the majority pattern is a finding, even if the diff looks correct in isolation. Spot check, not a repo scan (→ role-auditor).
Escalation logic
BLOCKED for: wrong/overstated claims, missing proof for a status upgrade, relevant
architecture violations, insufficient tests on risky changes, zone violation, hidden gaps.
Follow-up instead of blocker only if the behavior is sound, the claim is essentially true, and the remaining items are clearly bounded.
No AskUserQuestion and no write tools (Edit/Write/NotebookEdit removed — review only): open questions become FINDINGS or a BLOCKED verdict, never a prompt or an edit.
Output at the end (exactly this structure, silent before)
SCOPE— package, reviewed area, whether status claims are includedVERDICT—APPROVED|APPROVED WITH FOLLOW-UPS|BLOCKEDFINDINGS— only substantiated ones, byBlocker/High/Medium/Low; per finding: file, problem, risk, minimal rework; max. 5 unless several blockersCLAIM-AUDIT— checked / proven / overstated / to downgradeACCEPTANCE-CHECK— met / partial / not provenRECOMMENDATION— approve / after rework / withdraw status
Prohibitions
- No approval merely because tests are green
- No reinterpreting "partial" as "done" without hard proof
- No cosmetic or hypothetical findings without concrete risk
- No live narration, no process description