القائمة
Use when you need to resolve an in-progress git merge/rebase conflict.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Automated browser testing of UI flows via Playwright MCP + agent-browser. Use when user says "browser qa", "test the flow", "verify the UI", "test this page", "check if it works", "end-to-end check", or after completing code changes that affect UI and need manual verification replaced by automation. NOT for conversational bug-reporting sessions — that's /qa.
Use when a GitHub ticket/issue bundles multiple sub-tasks or fixes that will take hours, span context compactions, and ship as one reviewed PR — or when the user asks for subagent-driven execution, "the 4875 workflow", or proper progress tracking in the ticket.
Pre-code quality gate that runs /review-pr's anti-slop lens against a written plan BEFORE any code is written. Grounds the plan against the real codebase, runs 11 category checks (security, concurrency, round-trip, control-flow, error-handling, pattern-consistency, plus /review-pr's Q1-Q6), then grills the user one question at a time until the plan is hardened. Use when the user says "harden my plan", "check my plan", "grill my plan before I code", "lint this plan", or invokes `/harden-plan` explicitly. Also invoke proactively after `/grill-me` or `/grilling` completes with a written plan and before any implementation begins. Do NOT invoke after coding has started — redirect to `/review-pr` / `/fix-pr-review` in that case.
The disciplined root-cause loop to follow once you are already IN a debugging session — four phases (root-cause investigation, pattern analysis, hypothesis testing, implementation), no fix without an understood cause, evidence discipline at every component boundary, and a hard stop after repeated failed fixes. Use when about to propose or apply a fix for a bug or test failure, when a previous fix didn't work, when tempted to patch a symptom (add a null check, wrap in try-catch, bump a timeout, add a retry), or when you catch yourself guessing instead of tracing. Pairs with /diagnosing-bugs (repro + feedback-loop construction) — this skill governs fix discipline once the session is underway.
Execute git commit with conventional commit message analysis, intelligent staging, and message generation. Use when user asks to commit changes, create a git commit, or mentions "/commit". Supports: (1) Auto-detecting type and scope from changes, (2) Generating conventional commit messages from diff, (3) Interactive commit with optional type/scope/description overrides, (4) Intelligent file staging for logical grouping
Audit a stale GitHub issue/ticket against the current codebase — what's done, what's left, is it still needed? Then update or sunset it. Use when user says "audit this ticket", "is this ticket still needed", "update this old ticket", "what's done and what's left on this issue", or "should we sunset this issue".
| name | resolving-merge-conflicts |
| description | Use when you need to resolve an in-progress git merge/rebase conflict. |
Guiding principles
See the current state of the merge/rebase. Check git history, and the conflicting files.
Find the primary sources for each conflict. Understand deeply why each change was made, and what the original intent was. Read the commit messages, check the PRs, check original issues/tickets.
Resolve each hunk. Preserve both intents where possible. Where incompatible, pick the one matching the merge's stated goal and note the trade-off. Do not invent new behaviour. Always resolve; never --abort.
Discover the project's automated checks and run them — typically typecheck, then tests, then format. Fix anything the merge broke.
Finish the merge/rebase. Stage everything and commit. If rebasing, continue the rebase process until all commits are rebased.
