菜单
Analyze active git merge/rebase/cherry-pick conflicts and walk the user through them with a recommended resolution for each. Read-only by default; pass `--fix` to also resolve the conflicts you're confident about. Use when the user invokes `/merge-conflict` while a conflict is in progress.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Keep the current branch's PR mergeable, unattended. Each round it shepherds CI to green, syncs with the base branch and resolves conflicts, and addresses review feedback (AI bots + human) — fixing, committing, pushing, and replying as it goes. Runs as a persistent watcher that does not self-terminate; it keeps babysitting until you stop it. Use when the user invokes `/babysit-pr` and wants the PR driven to and held in a mergeable state without supervision.
Create and set up a new git worktree as a sibling of the current repo, branched off the default branch (main/master) by default — or off a given branch, tag, or PR. Names it after the repo plus a semantic extension derived from whatever content you give it. Use when the user invokes `/worktree`, or asks to spin up / create a worktree to work on something in isolation, on a specific branch, or to check out a PR.
Monitor CI on the current branch's PR until it goes green, automatically fixing and pushing failures along the way. On each failure round it runs `/ci-failure --fix`, commits, and pushes, then keeps watching. Use when the user invokes `/babysit-ci` and wants CI shepherded to green unattended.
Stop a running babysit loop (babysit-ci, babysit-pr, or any /loop-driven watcher) in the current session. Ends the loop now — stops background monitors and does not schedule a new wake-up — and records the stop clearly in the conversation so an already-scheduled wake-up that fires later re-reads the history, sees it was stopped, and self-terminates instead of acting. Use when the user invokes `/babysit-stop` or asks to stop, halt, cancel, or end babysitting, the CI/PR babysit loop, or a self-paced loop that won't stop.
End-to-end task execution: implement, verify, review, then open a draft PR. Use when the user invokes `/go` with a task description and wants the full pipeline run without further prompts.
Triage review feedback — either pulled from the current branch's PR or passed directly as text — by verifying each point against the codebase and walking the user through them. Read-only by default; pass `--fix` to also apply the points you're confident about. Use when the user invokes `/pr-feedback` (optionally with feedback text) before deciding what to act on.
| name | merge-conflict |
| description | Analyze active git merge/rebase/cherry-pick conflicts and walk the user through them with a recommended resolution for each. Read-only by default; pass `--fix` to also resolve the conflicts you're confident about. Use when the user invokes `/merge-conflict` while a conflict is in progress. |
| argument-hint | [--fix] |
You are helping the user understand the conflicts in an in-progress git operation. By default this is read-only: do not modify files, stage, or run any state-changing git command (add, checkout --ours/--theirs, rebase --continue/--abort, merge --abort, etc.). Your job is to analyze and explain.
Identify the operation in progress (merge / rebase / cherry-pick / revert) and the two sides involved, named by branch/commit — not just "ours/theirs". If nothing is in progress, stop and tell the user.
List all conflicted paths. Note non-content conflicts separately (rename/rename, delete/modify, add/add, binary) — they need different reasoning than plain content conflicts.
For each conflicted file, read the full file and inspect every conflict hunk. Use git log / git show on the relevant ranges when you need to understand why each side changed, not just what.
Walk the user through them. For each hunk:
Look beyond the conflicts. A conflict is only where the two sides touched the same lines — but the incoming side almost always brings in changes that merged cleanly too, and those can still be semantically at odds with the work on this branch. Skim what the merge brought in overall (git diff / git log on the incoming side, focused on files this branch also touched) and ask whether it fits the direction of our work: renamed/removed APIs we still call, changed behavior or assumptions our code relies on, new patterns that make our approach redundant or wrong. Treat the conflicts as a signal that the two sides diverged here — the clean parts may need attention too. Flag anything you find as an open question for the user.
End with a summary: how many files, how many hunks, how many you'd resolve confidently vs. need user input on — plus any concerns from the clean-merge review in step 5.
--fix)If --fix was passed, after the walkthrough fix everything that doesn't need the user's input directly in the working tree:
Leave anything that needs the user's judgment (semantic conflicts, unclear intent, behavior changes, design decisions) untouched — conflict markers intact where present — and list those for the user.
Edit files only. Do not stage (git add), and do not continue or abort the operation (rebase --continue/--abort, merge --abort, cherry-pick --continue) — leave that to the user. End with a clear list of what you resolved and what you left for them.
During a rebase, "ours" is the branch being rebased onto and "theirs" is the commit being replayed — the opposite of a merge. Always refer to the actual branch/commit names in your explanation; "ours/theirs" alone is a footgun.