一键导入
issue-next
Fresh session pickup using the most recent checkpoint comment and git log — reconstructs working context for active issue work
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Fresh session pickup using the most recent checkpoint comment and git log — reconstructs working context for active issue work
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Draft, polish, and create a well-formed GitHub issue with required structure
Post a structured checkpoint comment to the relevant issue and commit current code state
Close out issue work - ensure PR exists, run the full CodeRabbit + /code-review gate, merge, close all issues in the working set, clean branches, and update PROGRESS.md
Recommend juggling pairs, user decides, create correctly-named branch for issue work
Update the active issue with a design decision and cascade impact to all open issues and PRDs
Complete PRD implementation workflow - create branch, push changes, create PR, merge, and close issue
| name | issue-next |
| description | Fresh session pickup using the most recent checkpoint comment and git log — reconstructs working context for active issue work |
| category | project-management |
git branch --show-current
Extract issue numbers from the branch name. Branch format: feature/<numbers>-<description> where <numbers> is a hyphen-separated list of issue numbers (e.g., feature/98-101-autonomous-issue-execution → issues 98 and 101, feature/42-fix-auth-token-handling → issue 42).
For each issue number, fetch the title:
gh issue view <number> --json title,state
If the current branch does not match the feature/<numbers>-<description> format, tell the user: "This branch doesn't follow the issue branch naming convention. Please run /issue-start to create a correctly-named branch, or specify the issue number manually."
For each issue number extracted from the branch name, fetch all comments:
gh issue view <number> --comments --json comments
Find the most recent comment whose body begins with the exact string ## Progress Checkpoint. Use the issue with the most recent such comment as the context source for the brief.
If no checkpoint comment exists on any issue in the working set, note this: "No checkpoint comment found on this issue. Using git log only for context." Then proceed with Step 3.
Checkpoint comment format (the sentinel is ## Progress Checkpoint — match on this exact string, nothing else):
## Progress Checkpoint
**Branch**: `feature/<numbers>-<description>`
**Done**:
- [bullet per completed item since last checkpoint]
**Next step**: [one concrete next action]
**Open questions** (optional):
- [question if any]
git log --oneline -10
Use recent commits as supplemental context — they show what code landed after the checkpoint was posted.
Present a structured context summary in this format:
## Active Issue(s)
- #<number>: <title>
[repeat for each issue in working set]
## What Was Done
[Bullets from the checkpoint's Done section, or derived from git log if no checkpoint]
## Next Step
[The concrete next action from the checkpoint's "Next step" field, or the most recent commit context if no checkpoint]
## Open Questions
[Bullets from the checkpoint's Open questions section, or "None recorded" if absent]
## Recent Commits
[The git log --oneline -10 output]
If the checkpoint was posted from a different session, note this: "Last checkpoint was posted [relative time if available from comment timestamp]. Recent commits since then: [list any commits after the checkpoint was posted]."
Read the active issue body:
gh issue view <number> --json body
Parse all unchecked checklist items (- [ ] ...). For each unchecked item, call TaskCreate with:
subject: the checklist item text (strip the - [ ] prefix)description: "From issue #: [item text]"Skip already-checked items (- [x] ...). If no checklist items exist, skip this step.
Begin working on the "Next Step" from the checkpoint — or, if there is no checkpoint, the first unchecked checklist item. Mark the corresponding task in_progress before starting, completed when done.
If the next step is ambiguous or contradicts the issue's acceptance criteria, surface the ambiguity before acting. Otherwise, proceed without pausing for permission.
## Progress CheckpointWhen the user completes a task or reaches a natural stopping point, prompt them:
Session complete.
To save progress and prepare for the next session, run /issue-update-progress.