// Push a new Slang release. Triggers CI, determines the version from the sprint board, generates release notes, creates an annotated tag, and pushes it to upstream.
| name | slang-release-process |
| description | Push a new Slang release. Triggers CI, determines the version from the sprint board, generates release notes, creates an annotated tag, and pushes it to upstream. |
| allowed-tools | ["Bash","Read","Grep","Glob"] |
gh): Install from https://cli.github.comgh token must include read:project (for querying sprint info from the project board). Run gh auth refresh --scopes read:project to add it.Manually trigger the Release workflow on the master branch from:
https://github.com/shader-slang/slang/actions/workflows/release.yml
Using GitHub CLI:
gh workflow run release.yml --ref master
The workflow takes approximately 30 minutes. Monitor it with:
gh run list --workflow=release.yml --limit 1 --json status,conclusion,databaseId
Wait until the run completes successfully before proceeding.
Tag nomenclature: vYYYY.N where YYYY is the year and N is the sprint number within that year.
read:project scope):gh api graphql -f query='{
organization(login: "shader-slang") {
projectV2(number: 10) {
fields(first: 20) {
nodes {
... on ProjectV2IterationField {
name
configuration {
iterations { title startDate duration }
completedIterations { title startDate duration }
}
}
}
}
}
}
}'
N = current_sprint - 45.52 - 45 = 7 → version v2026.7Hotfix nomenclature: vYYYY.N.H where H increments from 1. The next sprint release note continues from the latest hotfix, not the previous sprint release.
Respin nomenclature (rare): vYYYY.N.H.R where R is the respin number, for re-spinning an old release with minimal changes.
# Auto-detects previous release tag and generates notes
# Requires GitHub CLI (gh) for PR label lookup; takes ~1-2 minutes
bash docs/scripts/release-note.sh
The script prints breaking changes (PRs labeled "pr: breaking change") followed by all changes.
Create an annotated tag on upstream/master with the release notes as the message:
# Make sure local master is up to date
git fetch upstream && git checkout master && git merge --ff-only upstream/master
# Create the annotated tag (paste the release-note.sh output as the message body)
git tag -a vYYYY.N -m "<tag message with release notes>"
# Push to upstream — this triggers the Release CI which creates the release packages
git push upstream vYYYY.N
The tag message format:
vYYYY.N
=== Breaking changes ===
<one-line git log entries for breaking PRs>
=== All changes for this release ===
<one-line git log entries for all PRs, with [BREAKING] prefix on breaking ones>
gh is installed and has read:project scope (gh auth status)gh workflow run release.yml --ref master)docs/scripts/release-note.sh to generate release notesupstream/master with the release notesupstream to trigger release packagingReview Slang changes for high-level clarity. Use whenever reviewing PRs or diffs for code quality or correctness. Produces candidate review comments in a markdown file.
Run the full Slang clarity review workflow: generate high-level and fine-grained candidates, consolidate overlap, filter for PR-author scope, and optionally post one GitHub PR review. Use when asked to perform an end-to-end clarity-focused review.
Merge Slang clarity review candidate files and resolve overlapping, duplicate, or superseded comments. Use after high-level and fine-grained clarity review passes and before scope filtering or GitHub posting. Produces or updates one canonical candidate markdown file.
Review Slang changes for fine-grained clarity. Use whenever reviewing PRs or diffs for code quality or correctness. Produces candidate review comments in a markdown file.
Post filtered Slang clarity review candidates as one proper GitHub PR review. Use after candidate consolidation and scope filtering. Uses the bundled stdlib Python script to validate candidate formatting, map comments to PR diff lines, and submit a GitHub review through gh.
Resolve Slang clarity review candidates marked as needing a judgment call. Use after consolidation and scope filtering, before posting, to perform focused follow-up analysis and decide whether uncertain candidates should be kept, revised, or dropped.