Use pre-merge-review

Gate an existing change for merge

Gate an existing change for merge — run one skill that fires the whole production-readiness pass. First a deterministic mechanical gate (lint + typecheck + tests, via a script whose exit code decides), then the three-reviewer panel dispatched in parallel — devils-advocate (correctness), security-reviewer (exploitability), code-quality (craft) — then a single READY / NOT READY verdict. Use before opening a PR or merging, when you want the full review fleet run on a diff you already have. Do NOT use to implement a feature from a spec (that's feature-implement-loop) or to review a document (that's doc-critique).

Install it

npx skilldrop-cli install pre-merge-review                 # Claude Code, your user folder
npx skilldrop-cli install pre-merge-review --project       # Claude Code, this repo
npx skilldrop-cli install pre-merge-review --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the Dev team pack: --pack dev-team installs it with its neighbours.

It ships scripts, so it needs Python 3 (standard library only, nothing to install). What they may touch is declared in its manifest.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

"is this change ready to merge?"
"run all the reviewers on my branch before I open the PR"
"production-readiness review of this diff"
"gate my PR — lint, tests, and a full review"
"review this branch and tell me if it's safe to ship"

Requests like these belong to a different skill, so it shouldn't answer them:

"implement this feature from the ticket's acceptance criteria"
"just find the bugs in this function"
"critique this design doc"

If another skill answers instead, ask for this one by name: "use pre-merge-review".

Check what you get

A good result:

The mechanical gate is run, not assumed. A verdict with no real gate result is invalid — you ran the script (or reported BLOCKED), you didn't eyeball the tests.
The gate is un-bypassable. A RED gate is NOT READY regardless of how good the review looks. The review can add blockers; it can never clear a failing gate.
Findings are merged and de-duped across the three lenses — the same line is not reported three times.
The verdict is one word plus the blocking reasons, not a hedged paragraph. A reader sees READY/NOT READY and exactly what stands in the way.
Design disagreements go to council-review, not adjudicated here — this skill gates a change, it doesn't decide an architecture.

See a worked example

pre merge verdict

Use something else when

Implementing a feature from a spec — that's feature-implement-loop, which generates and loops; this skill only judges an existing change.
One lens is enough — a pure bug pass is devils-advocate standalone; a pure doc pass is doc-critique.
An open design decision ("Postgres or Dynamo?") — that's council-review.

Where a loop runs it

Stage verify of the build loop, where gate G2 decides

SKILL.md, the instructions the agent reads
Its page on the site
Related: feature-implement-loop, devils-advocate, council-review, doc-critique

Edit this page on GitHub · View source