メニュー
Inspect GitHub issues and pull requests before a NanoLang release, scope them to the release in progress, and close stale work only with an explicit, auditable annotation.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/jordanhubbard/nanolang --skill release-readinessコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Regenerate and refresh the NanoLang developer presentation and narrative from current language, compiler, NanoISA, NanoVM, and release evidence.
Diagnose NanoVM opcode, stack, value, and FFI failures with the optional NANO_VM_TRACE instrumentation.
Plan and execute repository product work through docs/ROADMAP.md. Use this before starting features, refactors, optimization programs, or other work with multiple deliverables. Add ordered checkboxes first, execute from top to bottom, and mark only verified work complete.
SKILL.md を表示中
| name | release-readiness |
| description | Inspect GitHub issues and pull requests before a NanoLang release, scope them to the release in progress, and close stale work only with an explicit, auditable annotation. |
I do not release while work scoped to the release is still open. This check uses the GitHub CLI and requires an authenticated account with permission to read the repository and close issues or pull requests.
gh repo view --json nameWithOwner.RELEASE_VERSION to the version being prepared.release/v$RELEASE_VERSION
label, the v$RELEASE_VERSION milestone, or explicitly names the release
in its title or body.The release gate reports all open items, but only release-scoped items block the release. Unscoped work remains visible and must not be closed merely to make the gate green.
For each release-scoped open item:
Before closing a stale issue or pull request, add a comment using this form:
Stale for release vX.Y.Z: closing because <specific reason>.
Evidence: <commit, replacement issue/PR, decision, or reproduction result>.
Reopen or reference <link> if this is still relevant.
Apply the stale label when the repository has one. Do not close a pull
request solely because it is old: record why the proposed change is no longer
wanted or has been superseded.
Run:
gh issue list --state open --limit 1000 --json number,title,body,url,labels,milestone
gh pr list --state open --limit 1000 --json number,title,body,url,labels,milestone
The gate passes only when no release-scoped issue or pull request remains open. Save the query output and the triage comments in the release evidence; the absence of an item from a list is not evidence that it was reviewed.
This skill requires an LLM coding CLI. Human-only release handling is not a supported path because the review requires repository context, roadmap linking, and precise stale annotations.