Menu
Create a release-tracking issue that organizes open issues into a phased roadmap. Pass a target version (e.g., `0.5.0`) to scope the plan.
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
Deep analysis of current changes before committing. Goes beyond lint — catches logic bugs, architectural violations, security, and performance issues.
Create a pull request from the current branch, matching the repo's PR conventions (What/Why/Testing for features, Summary/Test-plan for small PRs).
Review staged or unstaged changes before committing. Catches bugs, style drift, and missing coverage.
Cut a release — promote Unreleased → versioned in CHANGELOG, bump version, commit. CI auto-tags and publishes from the version-bump commit.
Run the full quality gate — format, lint, tests, types. Use after changes to verify nothing is broken.
Check GitHub Actions CI status. Shows recent runs, and if there are failures, reads the logs and suggests fixes.
| name | roadmap |
| description | Create a release-tracking issue that organizes open issues into a phased roadmap. Pass a target version (e.g., `0.5.0`) to scope the plan. |
Create a release-tracking issue (a "roadmap") that organizes open issues into a phased implementation plan. Matches the pattern of #133 (0.5.0 roadmap).
$ARGUMENTS is the target version (e.g., 0.5.0, 1.0.0). If missing, ask.
For minor or major releases with coordinated scope — multiple issues with interdependencies, parallelization decisions worth communicating, or deferred items that need to be explicitly listed so they're not forgotten. Skip for patch releases (hotfixes, small cleanups); those ship directly from the Unreleased CHANGELOG section via /release.
Scope conversation — ask:
Inventory — run gh issue list --state open --limit 200 --json number,title,labels. Read bodies of non-trivial issues to understand cross-refs. Flag closed issues still referenced in open work.
Phase structure — organize issues by:
Typical shape:
Draft — follow the body format of #133:
### Description with scope drivers and version-jump justification### How to use this issue explaining the task-list convention## Phase N — <title> per phase with rationale, task list of - [ ] #NNN …, parallelization notes## Cross-phase dependency map in ASCII## What is deliberately not in <version> with deferred issues grouped by category## What <version> unlocks with 3–5 concrete outcomes## Issue inventory table with per-phase counts## Notes — living document caveatGitHub renders - [ ] #NNN as tracked tasks; use that syntax for every child reference.
Formatting constraints:
->, |, +) in dependency maps, not unicode arrows.ship <version>: <short description> — brief, lowercase imperative.Confirm — show the full draft. Iterate on phase membership, deferred items, outcomes before creating.
Create — gh issue create --title "ship <version>: …" --body-file /tmp/roadmap.md --label "release,enhancement". Return the issue URL.
/release references this issue for pre-flight validation: all referenced sub-tasks must be closed (or explicitly demoted from scope) before cutting the release.