verify

Independently review built GitHub pull requests against issue acceptance criteria before merge.

Updated Aug 7, 2026
One-click install
npx skills add https://github.com/ciaran-slow/MellowMaker --skill verify-ciaran-slow
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: verify
Source: https://github.com/ciaran-slow/MellowMaker/tree/main/.claude/skills/verify
Command: npx skills add https://github.com/ciaran-slow/MellowMaker --skill verify-ciaran-slow

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Built work often merges without an independent check that it actually satisfies the issue's acceptance criteria, passes CI gates, and respects the product vision. This Skill performs a rigorous, context-independent review of a MellowMaker pull request before merge. ## Core Features & Use Cases - Independent stage verification: Detects shared-context contamination between plan, build, and verify stages and validates stage provenance via a provenance-check script. - Criterion-level evidence review: Fetches the issue, plan comment, and exact PR head, runs repository CI gates locally, and maps every acceptance criterion to concrete file/line or runtime evidence. - Domain risk inspection: Checks vision drift, offline regressions, SQLite data loss, counter integrity, importer resilience, Expo compatibility, accessibility, and test quality, then posts a binary ready/not-ready verdict as a PR review. - Use Case: After a build stage opens a PR for issue #42, run this Skill in a fresh context to confirm the diff meets every acceptance criterion, CI is green, and deferred device smokes are properly logged before merging. ## Quick Start Use the verify skill to review the pull request for issue 42 against its acceptance criteria and post the verdict as a PR review.

Frequently Asked Questions about verify

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

FAQPage Schema
How do I verify a pull request against issue acceptance criteria?

Fetch the issue body, plan comment, and PR head with the GitHub CLI, check out the exact headRefOid, run the repository's CI gates locally, and map each acceptance criterion to file/line or runtime evidence before posting a binary verdict as a PR review.

Why must code review run in a fresh context?

A review sharing context with the plan or build stage loses independence and cannot objectively prove acceptance criteria. The Skill checks stage provenance and flags compromised independence, since a shared-context pass never upgrades a criterion from unproven to proven.

Can acceptance criteria pass without on-device testing?

Criteria requiring on-device behavior like app restart or hardware back are only provisionally met when a Jest/router proxy passes, a deferred-smoke entry is logged, and an owner-decision comment on the issue grants the deferral. Otherwise the criterion is unmet.

What happens when a review finds blocking issues?

The verdict becomes not ready to merge with findings listed by severity, each citing file/line, the broken contract, and a failing scenario. The reviewer reports findings without prescribing fixes, since remedies belong to the build stage.

Does this review workflow handle decision-type issues?

Issues labeled type: decision are verified as records rather than code. The review confirms the owner-decision comment exists and predates the record's first commit, and that every recorded statement traces to an answer in it.