# Review Before Merge

> Use when a completed change, milestone, branch, commit, or working-tree diff must be reviewed before merge or acceptance. Perform a read-only, defect-first review and do not fix findings automatically.

- Skill: `lead21pc/review-before-merge` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add lead21pc/review-before-merge`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lead21pc/review-before-merge/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: lead21pc (https://skillmd.com/u/lead21pc)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/lead21pc/review-before-merge

---


# Review Before Merge

Review the actual change set. Do not modify code.

## When to use

Use this skill when asked to:
- review before merge;
- audit a completed milestone;
- inspect a branch, commit, pull request, or working-tree diff;
- decide whether a change is ready for acceptance.

This skill is read-only.

## Inputs and context

1. Read applicable `AGENTS.md`.
2. Determine the exact review target:
   - uncommitted diff;
   - staged diff;
   - commit;
   - branch against its merge base;
   - another user-specified range.
3. Read the task or milestone requirements that the change is supposed to satisfy.
4. Inspect relevant tests and call sites, not only changed lines.

## Procedure

1. Inspect the complete target diff.
2. Map changed behavior to the stated requirements.
3. Search for concrete regressions involving:
   - correctness;
   - state handling;
   - edge cases;
   - error paths;
   - data loss;
   - lifecycle/resource handling;
   - concurrency/timing when relevant;
   - security when relevant;
   - performance only when impact is meaningful;
   - violation of project invariants.
4. Validate each candidate finding against surrounding code, call sites, tests, or a reproducible scenario.
5. Continue through the entire diff after finding an issue.
6. Do not flag:
   - style preferences;
   - speculative future concerns;
   - pre-existing defects not introduced by the reviewed change;
   - intentional behavior required by the task;
   - broad refactoring opportunities unrelated to acceptance.
7. Do not edit files, commit, merge, push, or automatically fix findings.

## Finding priorities

- P0: critical blocker; catastrophic or universally breaking behavior.
- P1: serious regression or high-impact defect that should block acceptance.
- P2: ordinary actionable defect introduced by the change.
- P3: lower-impact but concrete defect worth fixing.

## Efficiency plan

- Start with the diff and requirements.
- Read surrounding code only where needed to validate behavior.
- Prefer concrete execution paths over repository-wide static speculation.
- Do not perform a general code-quality audit unless requested.

## Verification checklist

Before reporting a finding, verify:
- it was introduced by the reviewed change;
- the affected scenario is concrete;
- the impact is meaningful;
- the finding is actionable;
- evidence supports the claim.

## Output

Present findings first, ordered by severity.

Use:
`[P1] Imperative title — path/to/file:line`

Then briefly explain:
- the triggering scenario;
- why the changed code is wrong;
- the resulting impact.

If there are no qualifying findings, write:
`No findings.`

After findings, include:
- overall readiness assessment;
- test gaps or residual risks;
- whether acceptance/merge appears safe based on available evidence.

Do not fix anything. End after the review.