PR Triage Gate

Purpose: Before touching CI logs or fixing test failures on any PR, answer: "Does the target branch already have this?"

Why this exists: A PR whose stated features are already on the target branch is a no-op; every minute spent debugging its CI is wasted. A two-command check at the start catches this before the debugging loop starts.

Announce at start: "I'm using the pr-triage-gate skill to verify this PR is still needed before debugging CI."

When to Use

• Before debugging CI failures on any MR or PR — verifies the work isn't already on the target branch
• When a PR appears stuck in CI and you're not sure if its changes are still needed
• Before spending time cherry-picking or rebasing an MR that may be obsolete

NOT when: you created the branch yourself in the current session and know it contains fresh work.

MANDATORY -- Run before any CI debug work

Step 0: Check out the PR branch so HEAD is the PR tip (10 seconds)

Every subsequent step compares HEAD against the target. If HEAD is on an unrelated branch, Step 2 silently produces a false verdict. Pin HEAD first:

# GitHub (substitute the PR number):
gh pr checkout "$PR_NUMBER"
# GitLab (substitute the MR internal ID):
glab mr checkout "$MR_IID"

Step 1: Read the PR description (30 seconds)

Both branches emit the same JSON schema so downstream steps do not fork on remote type.

GitHub via gh:

gh pr view "$PR_NUMBER" --json title,baseRefName,body \
  --jq '{title,target:.baseRefName,description:.body}'

If your remote is GitLab, use glab instead. The project path must be URL-encoded even when it contains nested groups (group/subgroup/repo):

PROJECT="$(git remote get-url origin \
  | sed -E 's#^(git@[^:]+:|https?://[^/]+/)##; s#\.git$##' \
  | sed 's#/#%2F#g')"
glab api "projects/${PROJECT}/merge_requests/${MR_IID}" \
  --jq '{title,target:.target_branch,description}'

If the API call fails or returns an error, STOP and report -- do not guess at PR goals.

Extract the stated goals: what functions, flags, or behaviors does this PR claim to add or change?

Step 2: Check if the target branch already has each stated goal (60 seconds)

Fetch the target once, then run the single most relevant check per stated goal:

git fetch origin <target-branch>

# For each stated goal:
git show origin/<target-branch>:<file> | grep -n "<function-name>"        # does the function exist on target?
git show origin/<target-branch>:<file> | grep -n "<flag-or-default>"      # is the flag or default present?
git diff origin/<target-branch>..HEAD -- <file> | wc -l                   # how much does the file actually differ?

If git show fails (file does not exist on the target), that stated goal is genuinely new -- note it and continue.

Step 3: Verdict

FORBIDDEN

• Do NOT open CI logs before completing Steps 1-3
• Do NOT retry pipelines before completing Steps 1-3
• Do NOT fix test failures before verifying the PR is still needed
• Do NOT rebase or squash before verifying the PR is still needed

Failure modes