Menu
Resolve merge or rebase conflicts with minimal, correctness-first edits, regenerate lockfiles with tooling, validate the build, and stage the result. Use when the user asks to "fix merge conflicts", "resolve conflicts", or after a merge/rebase leaves the tree conflicted.
Mark the current uncommitted state as reviewed by updating the review sentinel. Use when you've manually reviewed the substance of your changes and want to commit without running the full /review-cycle:review cycle. Per-state escape hatch, lighter than the project-wide .claude/.no-review-gate opt-out marker.
Run the full automated code review cycle on uncommitted changes. First brings the tree to the project's canonical state (its own format/lint/typecheck). Fans out Codex and the auto-fix reviewers (code quality, tests, error handling, type design) in parallel, applies fixes inline per the embedded policies, and loops up to 4 iterations until clean. Then, once against the final state, runs the report-only reviewers (structural maintainability and spec conformance) and a de-slopify cleanup pass. Updates the review sentinel on completion. Does NOT commit.
Drive a pull request's CI checks to green — watch the check set, diagnose the root failure, apply the smallest fix, route it through review, then commit and push; repeat until green. Use when the user asks to "fix CI", "get the checks green", "loop on CI", or "the PR build is failing".
Fetch and summarize review feedback on the active pull request into one prioritized action list. Use when the user asks to "get PR comments", "what did reviewers say", "summarize PR feedback", or "what do I still need to address on this PR".
Make a pull request easy to review without changing its behavior — a TL;DR that matches the diff, core files separated from generated ones, risks called out, and (only with approval) cleaner commit history. Use when the user asks to "make this easy to review", "tidy this PR", "clean up the commits", or "annotate the diff".
One-time setup for review-cycle. Verifies Codex CLI and multi_agent config, optionally appends comment + fix-vs-defer policies to CLAUDE.md (global or project), and updates .gitignore to exclude per-project sentinel files. Idempotent — safe to run multiple times.
| name | fix-merge-conflicts |
| description | Resolve merge or rebase conflicts with minimal, correctness-first edits, regenerate lockfiles with tooling, validate the build, and stage the result. Use when the user asks to "fix merge conflicts", "resolve conflicts", or after a merge/rebase leaves the tree conflicted. |
| argument-hint | [against <ref>] |
Get a conflicted tree back to a buildable, staged state. This skill stages the resolution; it never commits, pushes, or tags — you (and your review/commit gate) own that step.
git status --porcelain
git diff --name-only --diff-filter=U
$ARGUMENTS is natural language. against <ref> (or a bare ref) tells you what is being merged in, which helps you reason about which side is "theirs"; with no argument, resolve whatever conflict markers exist in the working tree.
Work file by file, minimally and correctness-first:
Never hand-edit a conflicted lockfile or other generated artifact. Resolve the source of truth, then regenerate:
# examples — use whatever the repo uses
npm install # package-lock.json
pnpm install # pnpm-lock.yaml
bun install # bun.lock
cargo build # Cargo.lock
For other generated files (codegen, snapshots), re-run the generator rather than merging the output by hand.
Before declaring done, confirm the tree actually builds and behaves:
# use the repo's real commands
<build> # compile / typecheck
<lint>
<test> # the tests relevant to the conflicted areas
If validation fails, the resolution is wrong — fix it, don't paper over it.
git add <resolved files>
git diff --cached --check # fails if any conflict markers remain
Confirm no <<<<<<<, =======, or >>>>>>> markers survive anywhere. Then report.
Conflicts resolved: N files
- path — how it was resolved (kept both / took <side> because …)
Lockfiles regenerated: <yes/no — which>
Build / lint / tests: <result>
Staged and ready for your review. Not committed.
--continue to a commit, or tag — stage and stop.--no-verify).