triaging-merge-queue-failures

Classify Trunk merge queue kicks and apply the matching verdict action per PR.

713|118|Updated Aug 11, 2020
One-click install
npx skills add https://github.com/PostHog/posthog-foss --skill triaging-merge-queue-failures
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: triaging-merge-queue-failures
Source: https://github.com/PostHog/posthog-foss/tree/main/.agents/skills/triaging-merge-queue-failures
Command: npx skills add https://github.com/PostHog/posthog-foss --skill triaging-merge-queue-failures

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve?

When a PR is kicked from the Trunk merge queue, developers waste time guessing whether the failure was real, a flake, a conflict, or a repo-wide issue, and often spam-retry the queue. This Skill provides a deterministic decision chart that classifies each kick and prescribes exactly one action: wait, hold and fix, requeue once, or escalate.

Core Features & Use Cases

  • Queue state classification: Reads Trunk's sticky bot comments and shadow PRs via helper scripts to determine states like superseded, conflict, kicked_failed, or blocked, since Trunk publishes no check runs in this repository.
  • Six-verdict decision chart: Walks an ordered chart covering superseded commits, non-mergeable PRs, real failures, one-off flakes, repo-wide flaky/infra issues, and unknown cases, each with a defined next step.
  • Unattended scheduled sweeps: Supports a cron-driven triage routine with marker-based deduplication, a 10-verdict cap, and a gated requeue switch (MQ_TRIAGE_ALLOW_REQUEUE) so kicks get verdicts without anyone asking.
  • Use Case: A developer asks why their PR was removed from the merge queue; the Skill reads the queue state, identifies a known flaky test as the cause, and requeues once instead of letting them retry blindly.

Quick Start

Ask the agent to triage why PR 12345 was kicked from the merge queue and follow the decision chart to report the verdict and next step.

Frequently Asked Questions about triaging-merge-queue-failures

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

FAQPage Schema
How do I find out why my PR was removed from the merge queue?

Run the mq-queue-state.sh helper with the state command against the PR to read Trunk's sticky comment classification, such as superseded, conflict, or kicked_failed. Then walk the decision chart to get the verdict and its prescribed action.

Should I requeue a PR that failed in the Trunk merge queue?

Requeue only when the failure is a one-off flake or non-deterministic blip, and only once per head OID. Count attempts on the current head first; if a retry already happened or the same head fails again, escalate instead of retrying.

Why does the Trunk merge queue show no check runs in GitHub?

Trunk publishes no check runs in this repository; the trunk-io app posts zero check runs on PR heads or queue branches. Queue state is exposed only through a sticky trunk-io[bot] comment per PR and draft shadow PRs with trunk-merge/pr-<n> head refs.

Can the merge queue triage sweep run unattended on a schedule?

Yes, it runs as a scheduled cloud routine that discovers kicked PRs from shadow PRs, classifies them, and posts one sticky verdict comment per PR. Requeueing requires MQ_TRIAGE_ALLOW_REQUEUE=1 in the environment; otherwise every verdict is report-only.

What are the limitations of unattended merge queue triage?

Unattended sweeps never check out or execute PR code, never merge, approve, or close PRs, and cap output at 10 verdicts per run. The sandbox lacks gh and GraphQL access, so all reads go through REST with manual pagination via the helper scripts.