canary-ship

Canary Ship

The last mile of a change is where quality is won or lost: a plausible-looking diff merges, and the bug nobody looked for ships with it. This skill is the ship gate — the disciplined path from "the code is written and tests pass" to "it's merged on main with CI green." Its spine is a real adversarial review before the merge button, not after, because the cheapest place to catch a defect is the one before it reaches main.

It is not a code generator. It assumes the change already exists on a feature branch and passes the suite locally. Its job is to pressure-test that change, resolve what the pressure surfaces, and integrate it under this repo's conventions without you having to re-remember them each time.

When this fires vs. when it doesn't

Use it when the work is done and green and the remaining verb is "ship", "merge", "PR it", "take it home". Do not use it to do the implementation, to merge something whose tests you haven't run, or to force a merge past a failing gate. If the change isn't on a branch yet, make the branch first (see AGENTS.md branch hygiene) — never ship from main.

Preconditions (verify before starting)

• On a feature branch, not main (git branch --show-current).
• The change is implemented and the relevant suite + lint pass locally. If you can't confirm that, stop and run them — the gate reviews a finished change.
• git fetch origin first, then know your diff base (origin/main...). Other sessions may be active on this repo; trust the remote, not stale local state.

The pipeline

Five phases. Do them in order; each depends on the last. Track them as todos so none is silently skipped.

1 · Review — two independent reviewers, in parallel, on the diff

Spawn two review subagents in the same turn so they run concurrently, each scoped to the actual change (not the whole repo):

• a correctness/design pass — harness-code-reviewer — hunting real bugs, broken contracts, and inconsistencies;
• an adversarial pass — harness-adversarial-reviewer — constructing failure scenarios: assumption violations, composition failures across all callers of anything you changed, and blind spots in new guards or tests.