OM Merge Buddy by @openmercato

OM Merge Buddy by @openmercato · Skillet

QA_GATE

labels.pipeline

labels.meta

labels.enabled

false

Collect gate status for each PR. For every non-draft PR, tracker operation get-pr-checks with {number} → check runs with name, state, and link. Evaluate these gates:

review decision must be APPROVED
required CI checks must be green
mergeable must not be CONFLICTING
mergeStateStatus must not be DIRTY or BLOCKED
the PR must not carry changes-requested, qa-failed, blocked, or do-not-merge — these are hard blocks, regardless of every other signal
the PR must not carry in-progress (an automated skill is still working on it)
QA-approval gate (enforced when qaGate is true in the config): if needs-qa is present, the PR must already carry qa-approved (manual QA signed off) — otherwise the QA-approval gate blocks the merge. needs-qa PRs legitimately sit in merge-queue before QA, so the pipeline label alone is not proof of QA; the qa pipeline label means QA is still in progress and is itself a blocker. skip-qa is the explicit opt-out: a PR carrying skip-qa does not require qa-approved. When qaGate is false, treat needs-qa without qa-approved as advisory — mention it in the report, but do not classify the PR as blocked on it alone.
QA head check (when qa-approved is present): fetch this PR through get-pr requesting number,headRefOid, then read its comments through list-issue-comments. Use the last qualifying QA grant or scope-reconfirmation comment returned by that operation; never let an older matching line override newer evidence. If ordering cannot be established, treat freshness as unverified and classify the PR as almost ready. When the selected QA head: <sha> differs from headRefOid, the sign-off is stale — not a hard block, but the row's "why" says "QA evidence older than head (tested <sha>, head <sha>)" and the PR classifies as almost ready at best until a QA reviewer re-tests or confirms the scope on the PR.

A PR whose check list is short is not a PR whose CI passed: the check-run surface reports jobs, and a workflow run the tracker has created contributes no rows until its jobs register, so a recently pushed head can read as entirely green while its run is still queued. Before scoring the CI gate, take list-runs on the PR's head branch, keep the runs whose headSha matches the PR head, and count any run that is not completed as PENDING — this skill's whole output is a list of PRs a human is about to merge, and "green" derived from an empty reading is the most expensive row it can print.

Treat PENDING CI as a blocker, but classify it as "almost ready" rather than "blocked" when it is the only missing gate. This is the one place pending CI genuinely blocks: other skills report and label the moment their work is done, whatever CI is doing, but merging is different from reporting — a PR merges only on genuinely green required checks, and no local validation run substitutes for them.

ci-monitoring on a PR is not a merge gate and not a claim. It means an earlier run finished and reported its work and still owes a CI-result comment; note it in the row's explanation when CI is the only outstanding gate, and classify on the checks themselves.

OM Merge Buddy

Merge Buddy

Workflow

Rules

Security boundaries