Menu
Use when ship-verify needs a reviewer panel fallback, external reviewer, silent failure reviewer, domain expert, or file:line findings lens.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when writing a ship-flow plan for a shaped entity, especially implementation tasks, TDD needs, runtime commands, or scope anchoring. Layer A delegation: superpowers:writing-plans owns plan authoring; ship-flow:test-driven-development owns fallback TDD contracts.
Use when shaping vague, complex, or ambiguous ship-flow requests into a Shape Up pitch, including `/shape`, discussion, or skill-authoring work.
Use when shape finds UI, domain, contract, interface, visual ambiguity, affects_ui, design_required, or no design reference before plan.
Use when ship-flow needs execute-stage implementation from an approved plan, including wave tasks, blocked work, or PR feedback re-entry. Layer A delegation: superpowers:subagent-driven-development owns wave dispatch discipline.
Use when `/ship` should run ship-flow for an entity id or good-enough raw requirement; vague inputs need shape clarification.
Use when verify passed and ship-flow needs review, PR readiness, PR body drafting, or canonical docs sync. Layer A delegation: pr-review-toolkit:review-pr owns PR review persona philosophy.
| name | verify-reviewer-panel |
| description | Use when ship-verify needs a reviewer panel fallback, external reviewer, silent failure reviewer, domain expert, or file:line findings lens. |
| user-invocable | false |
Use this utility skill from ship-flow:ship-verify. It is not a stage skill and must not advance workflow state by itself.
pr-review-toolkit is optional. When pr-review-toolkit:code-reviewer and pr-review-toolkit:silent-failure-hunter are installed, ship-verify may delegate to them for the concrete reviewer persona work. When they are absent, this skill is the ship-flow-owned fallback contract.
Every reviewer lens receives the same immutable input bundle:
reviewer_questions and domain_acceptance_checklist rows when presentcontext-routing-manifest rows when present; reviewers must not
accept prose-only routing as a substitute for extracted manifest inputskills_needed, adopter file signals, or touched files### Science Officer (EM) Stewardship Contract, rendered by:
bash "${CLAUDE_PLUGIN_ROOT:-plugins/ship-flow}/lib/render-science-officer-em-stewardship-contract.sh"
The block carries results, guidelines, resources, accountability,
consequences. FO owns workflow clock, state, worktrees, dispatch mechanics,
PR lifecycle, and stage advancement. EM owns engineering judgment, delegation
quality, worker stewardship quality, risk/scope challenge, and technical
recommendations. EM does not mutate entity state, own worktrees, dispatch
workers, create or merge PRs, or advance stages. Verification is output-shape
evidence, not worker self-attestation.Reviewers are read-only and findings-only. The prompt must say: do not edit files, do not stage files, do not commit, and do not rewrite the plan.
Before reviewing, each lens must echo its self-check:
self_check:
repo_path: <absolute path>
branch: <branch>
base_head: <base>..<head>
changed_files_count: <number>
status: pass|fail
If repo path, branch, base/head, or changed files do not match the verifier's bundle, discard the output. If findings do not cite file:line, discard the finding. In structured YAML, use the key file_line and put the citation in <path:line> format.
Purpose: review the execute diff as an independent external reviewer, not the author.
Questions:
plan.md, design.md, and execute hand-off?Purpose: find places where the flow could pass while behavior is broken or unverified.
Questions:
WARNING or NIT findings actually blocking because they hide a broken user journey?Purpose: specialize the review by domain lens. Ship-verify derives these lenses from domain registry, skills_needed, adopter file signals, and touched files.
Examples:
project-db: migrations, RLS, seed/validation, rollback and generated typesfmodel: aggregate boundaries, commands/events, decider/view/saga contractsrefine-expert: ProCRUD usage, refine hooks, cache invalidation, URL/drawer stateapi-design: route contracts, error semantics, auth, paginationDomain reviewers must load the required skills or knowledge modules named by the verifier bundle, then review only through that lens.
When the input bundle includes reviewer_questions or
domain_acceptance_checklist, use those concrete prompts instead of the canned
questions above. Preserve these fields in the reviewer output so the verifier
can audit the plan-to-verify handoff:
reviewer_question: <question from plan>
affected_path_family: <path family from plan>
required_skills: <skills required by plan/checklist>
evidence_required: <command/snippet/artifact required by plan>
Concrete prompts augment domain-expert-reviewer lenses; they do not replace the baseline reviewer lenses. The general-external-reviewer and silent-failure-reviewer still run their baseline questions even when the input bundle includes reviewer_questions or domain_acceptance_checklist rows.
For each domain_acceptance_checklist row, emit one reviewer_output_matrix item
that preserves the row's concrete lens, reviewer question, affected path family,
required skills, and evidence requirement. Example: a project-db row scoped to
apps/supabase/migrations/** stays lens: project-db; it does not collapse into
the generic domain-expert-reviewer label.
Concrete lens names such as project-db, fmodel, refine-gotchas, and
api-design are valid domain-expert lenses. Treat them as
domain-expert-reviewer kind with the concrete lens preserved in lens.
Return YAML or a markdown table that can be pasted under ### Review Findings:
reviewer_output_matrix:
- lens: general-external-reviewer
source: baseline|reviewer_questions|domain_acceptance_checklist|context-routing-manifest|scope-detection|inline-critical-pass
scope: <reviewed diff/checklist/surface>
reviewer_question: <question from plan, if any>
affected_path_family: <path family from plan, if any>
manifest_required_skill: <skill from context-routing-manifest required_skills, if any>
required_skills: <skills required by plan/checklist, if any>
dimension_key: type_design|silent_failure|test_adequacy|security|api_contract|ui_design|domain_intent|null
primary_owner: <reviewer lane or verifier|null>
verdict: PASS|BLOCKING|WARNING|NIT|NO_FINDINGS|INVALID_CONTEXT|DEGRADED
confidence: 1-10|null
finding: <short finding>
file_line: <path:line|null>
route_to: execute|plan|design|review|follow-up|captain|none
evidence_required: <command/snippet/artifact required by plan, if any>
evidence: <command/snippet/reference>
disposition: pending|accepted|bounced|deferred|discarded|not-applicable
disposition_reason: <verifier-owned reason before PASS>
NO_FINDINGS is not a blank pass: every NO_FINDINGS row must name lens, source, scope, route_to: none, and evidence identifying the reviewed diff, checklist, or surface. file_line may be null only for NO_FINDINGS, INVALID_CONTEXT, and DEGRADED rows; verdict-bearing BLOCKING, WARNING, and NIT rows require file_line: <path:line>.
Return INVALID_CONTEXT when the self-check repo path, branch, base/head, or changed files mismatch the verifier bundle; INVALID_CONTEXT rows are discarded by ship-verify and cannot count as coverage. Return DEGRADED only when a required reviewer could not run and the row names the attempted reviewer, reason, substitute evidence, and risk acceptance.
Verifier owns final aggregation. Critical and Important domain findings map to BLOCKING unless the verifier records a concrete deferral reason. Minor findings map to NIT or WARNING depending on user impact.
Reviewer rows must be easy for ship-verify to merge into the verifier-owned aggregation
and semantic review packet. Include dimension_key and
primary_owner when the lens maps to a pass ownership row:
general-external-reviewer -> type_designsilent-failure-reviewer -> silent_failuretest_adequacysecurityapi_contractui_designdomain_intentReviewers may report findings, but they do not own the stage verdict. Use
primary_owner to name the owning reviewer lane or verifier for local-only
runtime/UAT rows. The verifier keeps final disposition authority and records the
Panel Coverage verdict.