菜单
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.