菜单
Land an open PR on this repo — wait for CI to finish, then merge with a merge commit using admin bypass. Use whenever the user says "merge this PR", "/merge-pr", "ship the PR", "land the PR", or asks to merge a specific PR number. Defaults to the PR opened from the current branch.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | merge-pr |
| description | Land an open PR on this repo — wait for CI to finish, then merge with a merge commit using admin bypass. Use whenever the user says "merge this PR", "/merge-pr", "ship the PR", "land the PR", or asks to merge a specific PR number. Defaults to the PR opened from the current branch. |
| when_to_use | After a PR is opened and CI is running (or done) and the user wants it landed. Also used as the merge step inside the `release` skill. Skip when the PR isn't open yet — open it first. |
| allowed-tools | Bash |
Standard end-of-PR landing flow for lukas-grigis/ralphctl.
Repo + branch-protection facts that shape this flow (verified via gh repo view /
gh api .../branches/main/protection):
gh pr merge --squash would 422.deleteBranchOnMerge: true — branches auto-delete after merge. Do not pass --delete-branch.main requires 1 approving review. Solo maintainer can't self-approve, so admin bypass is the standard tool here.
enforce_admins is false, so the bypass is honored by the API.<pr-number> (optional) — when omitted, derive from the current branch via gh pr view --json number,....Resolve the PR. If no number given:
gh pr view --json number,title,state,headRefName,baseRefName,mergeable
Bail if state != OPEN or baseRefName != main. Show the user title + headRefName so they see what they're
about to land.
Watch CI. Block until checks finish:
gh pr checks <num> --watch --fail-fast
On failure: surface the failing check name + URL. Do not retry, do not merge. Hand back to the user — they decide whether to push a fix or close the PR.
Merge with admin bypass.
gh pr merge <num> --merge --admin
--admin is the load-bearing flag — it tells the GitHub API to use the caller's admin permissions to merge through
the required-review rule.
Confirm. Print the merge commit SHA:
gh pr view <num> --json mergeCommit -q .mergeCommit.oid
Clean up the trailing branch. The remote branch is gone (deleteBranchOnMerge: true handled it), but the local
copy and stale remote-tracking ref still linger. Switch back to main and delete them:
BRANCH="$(gh pr view <num> --json headRefName -q .headRefName)"
git checkout main
git pull --ff-only origin main # fast-forward to the new merge commit
git fetch --prune # drop the stale `origin/<branch>` ref
git branch -D "$BRANCH" 2>/dev/null || true # ok if it was never checked out locally
If the local checkout has unpushed work that isn't on the merged PR (rare, but possible if the user kept committing
after pushing), git branch -d would refuse — -D is intentional here because the canonical history is now on
main via the merge commit. Surface a warning if the deleted branch had commits not reachable from main.
--merge, not --squash / --rebase — repo policy. The existing chore(release): X.Y.Z (#NN) commit subjects
on main are merge-commit subjects; preserving that shape keeps tags aligned with PR history.--admin — the required-review rule exists for safety on multi-contributor PRs but blocks solo workflows. Admin
bypass is the explicit "I am the reviewer" escape hatch. Use it knowingly, not silently.--auto — --watch then merge is faster than the auto-merge queue and surfaces CI failures synchronously.merge-pr per stack tip.main — admin bypass is configured for main's protection rules; other
branches may have different rules and silently failing reviews shouldn't be papered over.--admin will merge through them. Address first;
don't bury them under the merge commit.Cross-phase skill — question every piece of AI-workflow scaffolding on every model upgrade; remove non-load-bearing pieces one at a time with measurement. Complexity drifts upward by default; subtraction requires discipline. Governs scaffolding built around AI usage (prompts, wrapper scripts, guardrails, validation steps), not the task's application code — for code-level minimalism defer to the ralphctl-ponytail, ralphctl-surgical-simplicity, and ralphctl-karpathy-guidelines skills when installed in this session.
Model software around the business domain using bounded contexts, aggregates, and ubiquitous language. Use when the user mentions "domain modeling", "bounded context", "aggregate root", "ubiquitous language", "anti-corruption layer", "context mapping", "domain events", "strategic design", "the code doesnt match the business", or "how do we split this big system". Also trigger when breaking a monolith into services, defining service boundaries, or aligning code structure with business processes. Covers entities vs value objects, domain events, and context mapping strategies. For architecture layers, see clean-architecture. For complexity, see software-design-philosophy.
Refines raw ideas into sharp, actionable concepts through structured divergent and convergent thinking. Use when an idea is still vague, when you need to stress-test assumptions before committing to a plan, or when you want to expand options before converging on one. Triggers on "ideate", "refine this idea", or "stress-test my plan".
Cross-phase skill — establish a shared understanding of what will and will not be done before producing output: restate the input back to the user, surface assumptions, name non-goals, and agree before you write. For an input that is still a raw, unshaped idea needing multiple candidate directions before one is chosen, run the ralphctl-idea-refinement skill first when it is installed in this session; alignment then confirms whichever direction comes out of it.
Session-discipline skill — settle the plan before touching code, work in small verified increments with a feedback loop that proves each change works, and record corrections so the same mistake is not repeated. Use when executing multi-step coding tasks where batching unverified work would compound risk; bundles plan-first sequencing and learning capture on top of the narrower per-change habits in ralphctl-iterative-review and (when installed) ralphctl-karpathy-guidelines.
Behavioural guardrails against four empirical LLM coding failure modes — silent assumptions, over-complication, orthogonal damage to code you don't fully understand, and declaring done without verification. Use when writing, reviewing, or refactoring code to surface assumptions early, keep changes proportionate to the task, and loop until explicit success criteria pass; broader than the implementation-choice ladder in ralphctl-ponytail or the scope checklist in ralphctl-surgical-simplicity (when those are installed), which it complements rather than duplicates.