review-and-merge

Reviews pull requests against numbered acceptance criteria and merges verified work.

1|Updated Jun 30, 2026
One-click install
npx skills add https://github.com/Lia-Creative/lia-plugins --skill review-and-merge-lia-creative
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: review-and-merge
Source: https://github.com/Lia-Creative/lia-plugins/tree/main/lia-tools/skills/review-and-merge
Command: npx skills add https://github.com/Lia-Creative/lia-plugins --skill review-and-merge-lia-creative

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code and document reviews often grade summaries instead of actual acceptance criteria, wave through unverifiable claims, or merge work that was never content-verified. This Skill enforces an evidence-based review loop where every criterion gets a verdict, an evidence tier, and a falsifiability check before anything merges. ## Core Features & Use Cases - Per-criterion rubric: Each acceptance criterion is graded by index with a verdict (met, not met, cannot check), an evidence tier, and a falsifiability statement — never a single PR-level approval. - Adversarial pass and anti-patterns: Actively attempts to falsify the two weakest criteria and checks six named failure patterns such as checks that have never been seen to fail. - Feedback loop and verified merge: Sends findings back to the same build session, re-reviews on the new head, and squash-merges only after every criterion is disposed of, with a content diff proving the landing. - Use Case: A lead agent reviews a PR for ticket LIAB-123, finds two criteria unverifiable, hands them back with specific evidence requests, re-reviews the fix, then squash-merges and confirms the landing with git diff against origin/main. ## Quick Start Ask the agent to review the open PR for your ticket against its acceptance criteria and run the merge once every criterion passes.

Frequently Asked Questions about review-and-merge

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review a PR against acceptance criteria?▼

Grade each acceptance criterion by index with three fields: a verdict (met, not met, cannot check), an evidence tier describing what you actually did, and whether you saw the check fail. Never post a single overall verdict for the whole PR.

What happens when a criterion cannot be verified?▼

A cannot-check verdict is a blocker with exactly three exits: get the access and check it, hand it back to the builder for evidence, or escalate to the founder as a named gap. The review must state which exit was taken, and the criterion does not merge until the exit completes.

Can a lead review its own work?▼

No. A lead never reviews work its own session produced, because independence is what qualifies the seat to judge. If a lead holds work it built, it spawns a separate reviewer subagent with its own context window to run the review.

How do I verify a squash merge actually landed?▼

Run git fetch origin followed by git diff --stat between the PR head and origin/main limited to the PR's files. An empty diff proves the content landed; GitHub's merged flag alone proves nothing after a squash merge.

Why does the review require an adversarial pass?▼

The adversarial pass actively tries to falsify the two criteria most likely to be wrong, using angles like empty states, offline paths, and wrong inputs. Checks that have never been observed failing have proved nothing, so the review deliberately tries to break them.