Menü
Resolve merge conflicts on a pull request by rebasing onto the base branch. Use when a PR is not mergeable, has merge conflicts, or the user asks to fix conflicts on a PR.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | fix-pr-conflict |
| description | Resolve merge conflicts on a pull request by rebasing onto the base branch. Use when a PR is not mergeable, has merge conflicts, or the user asks to fix conflicts on a PR. |
Resolve merge conflicts on a pull request so it becomes mergeable.
Determine the PR number using these sources, in order of priority:
gh pr create output or PR URLs).gh pr view.# Try the current branch first
gh pr view --json number,headRefName,baseRefName,mergeable,mergeStateStatus 2>/dev/null
# Or by explicit number
gh pr view <number> --json headRefName,baseRefName,mergeable,mergeStateStatus
If the PR is already mergeable, report that and stop.
git fetch origin <baseRefName> <headRefName>
git checkout <headRefName>
Verify the working tree is clean before proceeding.
git rebase origin/<baseRefName>
If the rebase completes with no conflicts, skip to step 5.
When the rebase stops on a conflict:
git diff --name-only --diff-filter=U// Code generated ... DO NOT EDIT. headers, or paths matching known generator outputs like *.pb.go, *_gen.go, sqlc/openapi output dirs), do not attempt to merge the conflict markers. Instead:
git checkout --theirs <file> or git checkout --ours <file>), git add <file>, and continue.buf generate, go generate, sqlc generate, etc.) and amend or add a follow-up commit with the regenerated output.git log --oneline origin/<baseRefName> -- <file> and read the relevant commits.git log --oneline -1 REBASE_HEAD).Explore subagents (model: sonnet, per subagent-model-routing — semantic intent matters; classification requires understanding both sides' design) per parallelize-subagents and delegate-investigation. Each subagent reads one file's conflict markers + the relevant base/PR commits, returns a classification (mechanical / semantic / ambiguous) plus a resolution proposal in ≤80 words, prefixed with Status: ... per subagent-prompt-contract. Main agent applies resolutions sequentially via Edit (Explore is read-only; it analyzes, you apply).git rebase --abort), and escalate to the user with a description of the conflict and what options exist.git add <file>git rebase --continueRun verification per verify-when-complete. If failures stem from a bad conflict resolution, fix and amend the relevant commit. If errors are unrelated, report them.
git push --force-with-lease
Then verify the PR is now mergeable:
gh pr view <number> --json mergeable,mergeStateStatus
Report the result. If GitHub still reports conflicts (can take a few seconds to recompute), wait and re-check once.
If any conflict resolutions were semantic (changed logic, adapted APIs, reconciled incompatible changes) rather than purely mechanical:
gh pr comment <number> --body "..."
If all resolutions were mechanical (adjacent-line merges, independent additions), skip this step.
Use when asked to rewrite or format text in the user's voice, "make this sound like me", "match my voice", "de-stiffen this", when text "reads too corporate / businessy / stiff", to "strip the em-dashes / agent typography", or to draft a Slack announcement, PR body, or doc in the user's voice. Also /match-voice.
Use when writing or rewriting reader-facing technical text — documentation, READMEs, runbooks, procedures, error messages, release notes, incident reports, API guides, agent/system prompts — or when asked to "de-slop", "make this readable", "simplify this doc", "write for non-native readers", "apply STE", "Simplified Technical English", or "ASD-STE100", or to prepare text for translation. Also use to CHECK such text for clarity violations. Do NOT use for chat replies, PR/review comments, or commit messages (that is terse-output), nor for marketing, brand, or personal-voice writing (that is match-voice) — this skill deletes persuasion by design.
Use when the user asks for a deep review, full review, comprehensive review, production readiness assessment, full audit, multi-domain audit, "security and reliability and code review", or "review everything". Also use when the user explicitly requests performance review alongside the comprehensive request (e.g. "include perf", "review including performance", "deep review with perf"); without that explicit phrasing, performance is excluded. Do NOT use for narrow single-domain reviews (use the matching review-* skill directly).
Review code architecture (SOLID, design patterns, package design, coupling, testability), Go best practices, and protobuf/API design using manual analysis and static analysis tools (gocyclo, staticcheck, buf). Use when the user asks for a code review, architecture review, Go review, protobuf review, SOLID review, or design pattern review.
Use when the user wants to execute an approved implementation plan and says any of "do it" (with a plan in scope), "lets do it" / "let's do it", "confirmed" (as approval to proceed on a plan), "implement the plan", "implement this", "execute the plan", "start implementing", "work through the plan", "implement the next phase", "build it out", "knock out the plan", or "/implement-plan PATH". Also use when a plan file (`./.plans/PLAN.md`, any `./.plans/*.md`, or legacy `./PLAN.md` / `./docs/plans/*.md`) is present and the user signals readiness to begin coding. Do NOT use when the user is still discussing, refining, or asking questions about the plan, nor when no plan exists — short imperatives like "do it" or "confirmed" alone are ambiguous; verify a plan is in scope before activating.
Use when the user asks to review the plan, sanity-check the plan, vet the plan, evaluate the plan, "is this plan ready", feasibility check on a plan, "review-plan PATH", or when another skill (like implement-plan) requests pre-flight plan evaluation before execution. Do NOT use when no plan file is in scope (the user is likely asking for a summary — use Read instead), nor when the user is asking about source code (use review-code), nor when the user wants documentation review (use review-documentation).