agentsclimarketplace

Role reviewer

Skill BechsteinDigital/claude-shiploop/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.

Install
npx -y skills add BechsteinDigital/claude-shiploop --skill role-reviewer

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

  1. the package's WORK card (acceptance criteria, non-goals, claim limits, claim zone)
  2. 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 from project/PROFILE.md
  3. project/PROFILE.md — quality rules, architecture overview
  4. 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

  1. Acceptance check: which diff parts prove which criterion? Unproven criteria are findings, not a pass.
  2. Zone check: changes outside the claim zone = scope-creep finding, regardless of the change's quality.
  3. Claim audit: for DONE, finished, complete, compliant in 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.
  4. 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?
  5. Architecture & rules: against project/PROFILE.md. Works but violates guardrails → finding.
  6. 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)

  1. SCOPE — package, reviewed area, whether status claims are included
  2. VERDICTAPPROVED | APPROVED WITH FOLLOW-UPS | BLOCKED
  3. FINDINGS — only substantiated ones, by Blocker/High/Medium/Low; per finding: file, problem, risk, minimal rework; max. 5 unless several blockers
  4. CLAIM-AUDIT — checked / proven / overstated / to downgrade
  5. ACCEPTANCE-CHECK — met / partial / not proven
  6. RECOMMENDATION — 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

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.