Use when adding a new model (or model family) to the llm-calc database (calc/src/data/models.ts). Walks through sourcing fields from HuggingFace config.json, reading papers for novel attention variants, writing tests first, and registering the entry. Invoke this whenever a model is being added or updated — even for a single SKU, since the failure modes (wrong KV bytes, mis-sized attention, silently broken roofline) all look fine until someone runs the calc against a real workload.
Use when adding a new accelerator (GPU/TPU/Trainium/Gaudi), interconnect fabric, or multi-accelerator system to the llm-calc database (calc/src/data/{accelerators,interconnects,systems}.ts). Routes to the right sub-procedure based on whether the SKU is a new chip, a new fabric, or a new product composition. Invoke whenever hardware is being added — the failure modes (sparsity-inflated TFLOPS, confused per-direction vs aggregate BW, wrong variant in a system) all produce plausible-looking perf numbers that are silently wrong.
Create a feature branch, commit changes, push, and open a PR against iopsystems/llm-perf
| name | release |
| description | Create a release PR with version bump and changelog update |
Create a release PR that bumps the version and updates the changelog. After the PR is merged, a GitHub workflow will automatically tag the release and bump to the next development version.
The skill accepts a version level argument:
patch - 0.1.0 -> 0.1.1minor - 0.1.0 -> 0.2.0major - 0.1.0 -> 1.0.00.2.0Example: /release minor
Verify prerequisites:
main branchgit fetch origin
if [ "$(git branch --show-current)" != "main" ]; then
echo "Error: Must be on main branch"
exit 1
fi
if [ -n "$(git status --porcelain)" ]; then
echo "Error: Working directory not clean"
exit 1
fi
if [ "$(git rev-parse HEAD)" != "$(git rev-parse origin/main)" ]; then
echo "Error: Not up to date with origin/main"
exit 1
fi
Run local checks:
cargo clippy --all-targets --all-features -- -D warnings
cargo test --lib
If checks fail, stop and report the errors.
Determine the new version:
# Get current version from Cargo.toml
CURRENT=$(grep '^version = ' Cargo.toml | head -1 | sed 's/version = "\(.*\)"/\1/')
echo "Current version: $CURRENT"
# Use cargo-release to calculate new version
cargo release version <LEVEL> --dry-run 2>&1 | grep -o '[0-9]\+\.[0-9]\+\.[0-9]\+'
Create release branch:
NEW_VERSION="X.Y.Z" # from step 3
git checkout -b release/v${NEW_VERSION}
Bump versions using cargo-release:
cargo release version <LEVEL> --execute --no-confirm
Update CHANGELOG.md:
The changelog should follow Keep a Changelog format. Ask the user if they want to review/edit the changelog before proceeding.
Commit changes:
CRITICAL: The commit message MUST start with release: v (no other words before the version).
The tag-release.yml workflow matches startsWith(message, 'release: v') on the merge commit.
When GitHub squash-merges a single-commit PR, the commit message becomes the merge commit message.
git add -A
git commit -m "release: v${NEW_VERSION}"
Push and create PR:
iopsystems/llm-perforigin (determine the owner from git remote -v)git push -u origin release/v${NEW_VERSION}
gh pr create \
--repo iopsystems/llm-perf \
--head <fork-owner>:release/v${NEW_VERSION} \
--title "release: v${NEW_VERSION}" \
--body "$(cat <<'EOF'
## Release v${NEW_VERSION}
This PR prepares the release of v${NEW_VERSION}.
### Changes
- Version bump
- Changelog update
### After Merge
The release workflow will automatically:
1. Create git tag `v${NEW_VERSION}`
2. Build and publish release artifacts (deb/rpm for amd64/arm64)
3. Bump to next development version (`-alpha.0`)
---
See CHANGELOG.md for details.
EOF
)"
Report the PR URL to the user.
When the PR is merged to main, the tag-release.yml workflow will:
vX.Y.Zrelease.yml workflow then builds deb/rpm packages and creates a GitHub Release0.2.1-alpha.0)cargo install cargo-releasebrew install gh or see https://cli.github.com/gh auth login