القائمة
Log items to come back to later — bugs found mid-task, feature ideas, project feedback — as GitHub Issues. Use when the user asks to log, list, view, or work through items saved for later.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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 | later |
| description | Log items to come back to later — bugs found mid-task, feature ideas, project feedback — as GitHub Issues. Use when the user asks to log, list, view, or work through items saved for later. |
| user-invocable | true |
Use gh to manage backlog items as GitHub Issues in the current repo.
Verify there is a GitHub remote: gh repo view --json nameWithOwner. If it fails, stop and tell the user there is no GitHub remote — they need to be in a GitHub-backed repo to use this skill.
gh issue create --title "<title>" --body "<detail>"
Add labels if helpful (e.g. --label bug), but don't create labels that don't exist yet — only use labels already present in the repo.
Before creating, run gh issue list --search "<title>" to check for duplicates. If a near-match exists, show it to the user and ask whether to update that issue or create a new one.
gh issue list --state open
gh issue view <number>
Never jump straight into implementation after reading an issue. After gh issue view, always: summarise the issue in your own words, investigate the relevant code enough to explain why it happens (root cause, not just symptoms), then present your thoughts — options, tradeoffs, a recommendation if you have one — and ask the user how they'd like to proceed. Only start editing code once the user has confirmed a direction. This applies even if the fix looks small or obvious.
gh issue close <number>
gh issue list --state open to get open items.gh issue view <number> for items being actively discussed, then follow the discuss-before-implementation rule above.gh issue close <number>.If the user specifies priority, map it to labels if they exist in the repo (priority: high, priority: medium, priority: low). Otherwise note priority in the issue body.