Menu
Use when getting a pull request ready to merge by addressing review threads, CI failures, or conflicts, without performing the merge.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when ingesting, refreshing, listing, searching, or deleting a local corpus with Blackbird code search and `gh blackbird search --fileset`.
Use when reaching for `gh blackbird` (Blackbird code search) for cross-repo lexical, symbol, or semantic search on GitHub — finding callers, ownership, or how systems work without cloning.
Use when creating a GitHub pull request, or when updating an existing PR's title or body so it matches what the code actually does.
Use when authoring or substantially editing a design doc, architecture doc, or subsystem explanation — the "here's what's there and why" companion to an ADR's terse decision record.
Use when creating a repo-tracked multi-agent planning PR for a large project, especially when phases, living docs, parallel agent prompts, and cross-PR coordination are needed.
Use when about to call a library, crate, or framework API you haven't verified, when a dependency's behavior is surprising, when training-data memory might be stale, or when investigating how a dependency actually behaves.
| name | pr-merge-readiness |
| disabled | true |
| description | Use when getting a pull request ready to merge by addressing review threads, CI failures, or conflicts, without performing the merge. |
Drive a PR through every requirement until it is ready to merge, then stop. This skill does the work; it does not press the green button. The user owns the merge.
This is a user-level personal workflow. Do not mirror it into repo-local skills, and do not treat it as a fallback for repo-level auto-merge orchestrations such as agent-merge; those run unsupervised and may drive all the way through merge.
Do not use this skill to merge. End the turn at "ready to merge."
A PR is ready to merge when all three are satisfied simultaneously:
| Condition | What it means |
|---|---|
| Reviews handled | Every unresolved review thread was addressed on its merits, replied to on GitHub, and resolved. A code change alone does not satisfy this. |
| CI green | Required checks passed on the current HEAD. Optional or unrequested checks are informational. |
| Mergeable | GitHub reports no conflicts, and the branch is current if branch protection requires it. |
Top-level PR comments and review bodies cannot be resolved on GitHub and are not strict gates. Read them, act on substance, ignore boilerplate.
Work the three conditions concurrently, not sequentially. Push code changes early so CI runs against the final state.
You are doing the work, not gatekeeping. Address feedback on its merits; handling-review-feedback covers review triage and replies. For conflicts and base drift, see merging-base-into-pr. For CI failures, see debugging-systematically and fixing-root-causes. This skill coordinates those workflows and adds the hard stop-before-merge rule.
gh pr merge, the GitHub MCP merge tool, or any equivalent. When all three conditions are green, summarize the state and end the turn. The user merges.sleep, do not gh run watch, do not gh pr checks --watch. Blocking inside a tool call locks the user out of interrupting you.gh commands: GH_PAGER="" or pipe to cat. Otherwise commands hang in non-interactive shells.GH_PAGER="" gh pr view <number> --repo <owner>/<repo> \
--json state,isDraft,reviewDecision,mergeStateStatus,mergeable,statusCheckRollup
GH_PAGER="" gh pr checks <number> --repo <owner>/<repo>
If the PR is already merged or closed, report and stop. Otherwise note which conditions are satisfied and which need work. That is your checklist.
Work all unsatisfied conditions before entering any wait loop so CI runs against the final state.
mergeable: CONFLICTING, resolve and push. Use merging-base-into-pr for stacked-PR conflict handling against the PR's actual base ref.mergeStateStatus: BEHIND, merge base into the PR branch and push.reviewThreads query, then act on each per handling-review-feedback. For each thread: make the code change (if any), commit, push, reply on the thread, and resolve. A thread isn't done until reply + resolve succeed.gh run view <run_id> --repo <repo> --log-failed), identify root cause, and fix at the source per debugging-systematically and fixing-root-causes.After the first pass, CI is running against the latest push. Don't block on it.
gh pr checks to confirm the new run was picked up. Then end the turn.If the same CI fix has failed twice, or the failure is outside your control, stop and ask the user.
When all three conditions are green, verify once and summarize:
GH_PAGER="" gh pr view <number> --repo <owner>/<repo> \
--json mergeStateStatus,mergeable,reviewDecision,statusCheckRollup
Report:
mergeStateStatus: CLEAN (or BLOCKED if waiting on a human approval).Tell the user the PR is ready to merge. Stop. Do not merge.
If mergeStateStatus is BLOCKED because approval is missing, say so plainly and stop. That is a wait on a human, not something to work around.
reviewDecision: REVIEW_REQUIRED as defeat. That's an approval gate; surface it and stop. You don't bypass it.