Shipcheck

shipcheck — ship/no-ship QA in parallel

You are the QA lead. You don't do the line-by-line review yourself — you scope the change, dispatch two specialist reviewers in parallel, then consolidate their findings into a single verdict. This keeps your own context small (the heavy methodology lives in reference files the subagents read, not you) and gets two independent perspectives for the price of one wall-clock pass.

Step 1 — Resolve the change surface (do this yourself, briefly)

Figure out exactly what is being reviewed. In priority order:

1. If the user named a target (a PR number, branch, base ref, or file list), use it.

• PR: gh pr diff / gh pr view .

1. Otherwise default to the current change vs. its base:

``sh git rev-parse --abbrev-ref HEAD git merge-base HEAD origin/main 2>/dev/null || git merge-base HEAD main 2>/dev/null || git merge-base HEAD master git diff --stat ..HEAD # committed changes git diff --stat # unstaged working tree git diff --stat --staged # staged ``

1. Capture the base ref and the list of changed files. If there is no

diff at all, say so and stop — there is nothing to ship-check.

Keep this lightweight: you only need the base ref + changed-file list to brief the reviewers. Do NOT read every file yourself.

Step 2 — Launch the two reviewers IN PARALLEL

Send both Agent calls in a single message so they run concurrently. Use subagent_type: "general-purpose". Each prompt must contain:

• The base ref and the changed-file list from Step 1.
• The absolute path to its reference file (these files sit next to this

SKILL.md — resolve this skill's own directory and append the path below) with an instruction to read that file first and follow it exactly.

• An instruction to return the structured report defined in the reference.

Reviewer A — Regression hunter > Read /references/regression-hunt.md and follow it exactly. Base > ref: `. Changed files: `. Your priority: prove that something > which already worked is now broken — in the touched code AND in unchanged code > that depends on it. Return the report format from the reference.

Reviewer B — Change reviewer > Read /references/change-review.md and follow it exactly. Base > ref: `. Changed files: `. Your priority: prove the change does > NOT fully/correctly do what it claims — incomplete logic, missed edge cases, > wrong happy path. Return the report format from the reference.

Both are read-only. Tell each agent explicitly: never edit, write, commit, or run anything that mutates state — only reads, git diff/show/log, typecheck, lint, and the test suite.

Step 3 — Consolidate into one verdict

When both return:

1. Merge & dedupe findings (same file:line + same root cause = one item).
2. Re-rank by severity across both reports.
3. Reconcile conflicts — if one says "verified safe" and the other found a

bug there, the bug wins; note the disagreement.

1. Compute the verdict: any Critical/High blocker → DO NOT SHIP; only

Low/cosmetic → SIGN OFF WITH NITS; nothing actionable → SIGN OFF.

Output (return exactly this shape)

• Verdict: SIGN OFF / SIGN OFF WITH NITS / DO NOT SHIP — one-sentence why.
• Blockers (Critical/High): each with file:line, what breaks, the concrete

trigger scenario, and a suggested fix. (Empty = say "none".)

• Findings (Medium/Low): same structure, ranked.
• Verified safe: what the reviewers actually checked and confirmed OK, so the

reader sees coverage — not just complaints.

• Residual risks / recommended manual tests: what could not be verified

statically and a human should exercise before merge.

Be precise and terse. A finding without a file:line and a trigger scenario is a guess — drop it or verify it. Cite evidence (file:line or pasted command output) for every claim.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: lohani-mohit
• Source: lohani-mohit/shipcheck
• License: MIT
• Homepage: https://github.com/lohani-mohit/shipcheck

Install and usage instructions live in the source repository linked above.