Menu
Use when you need to resolve an in-progress git merge/rebase conflict.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when the user requests to update, upgrade, or install the latest release of Neovim.
Write a comprehensive, no-placeholder implementation plan as a series of bite-sized tasks, each with exact file paths, real code, TDD steps, and commit instructions. Saves as a GitHub Issue with a [PLAN] prefix. Use after preflight has established what to build.
Present a plan to the user for inline annotation via the ai-review UI. Use when you have a plan ready for human review before executing it. The user will annotate it in the browser; you then revise based on their comments.
Explain the core concepts, library design patterns, system architecture, or host environment internals involved in a plan or git diff. Spawns an isolated subagent to perform the education.
Capture an Architecture Decision Record (ADR) for a significant decision made in the current project. Store in the project's adrs/ folder. Use when the user asks to record a decision, log an ADR, or capture why something was built a certain way. PROACTIVELY suggest capturing an ADR whenever a non-obvious architectural choice is made — technology selection, structural trade-offs, rejected alternatives — especially after a discussion where context and reasoning were developed. A good prompt — "Want me to capture this as an ADR?"
Manage Jack's personal technical reference library at ~/git/references. Use for searching/reading existing references, or adding new ones. Invoke with /jack-references and optional keywords to search, or when the user wants to save a new reference guide. PROACTIVELY suggest saving a new reference whenever the conversation involves figuring out how a library, API, or tool works — especially after debugging, reading docs, or solving a non-obvious integration problem. A good prompt — "Want me to save this as a reference for next time?"
| name | resolving-merge-conflicts |
| description | Use when you need to resolve an in-progress git merge/rebase conflict. |
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. If you are unsure of the correct resolution, stop and ask the user for clarification.
Verify conflict markers. Before staging any resolved file, explicitly search it to ensure all conflict markers (<<<<<<<, =======, >>>>>>>) have been removed.
Discover the project's automated checks and run them. Build the project first, then run typecheck, tests, and 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.
