agentleFS
ai-dynamoai-dynamo/aiperf/.agents/skills/bump-version/SKILL.md

bump-version

Skill839 starsChanged 51 days agoApache-2.0View on GitHub

Bump the AIPerf package version (e.g. 0.10.0 -> 0.11.0) across pyproject.toml, the mock server, and the version strings shown in docs, then open a PR to main

  • Commits and pushes

We split this skill into the rules it gives an agent

9 rules. 0 are common, 3 are distinctive, and 6 are very specific to this project.

  • 0

    Common

    Most of the 37 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Only proceed if the working tree is clean (ignore untracked files that are not part of the bump).

    line 32
  2. Very specific:

    Read the version field under [project] in pyproject.toml.

    line 36
  3. Very specific:

    Use the <username>/chore-update-version-<NEW_VERSION> convention, e.g.

    line 40
  4. Distinctive:

    If the grep surfaces a NEW occurrence not in this list, update it too and add it to this skill's canonical list in the same PR.

    line 66
  5. Very specific:

    If gh is unavailable, print the manual compare URL: …

    line 149
  6. Very specific:

    NEVER manually add a Signed-off-by line — git commit -s adds it.

    line 156
  7. Very specific:

    NEVER use --no-verify or git commit -n.

    line 157
  8. Distinctive:

    NEVER git add -A / git add ..

    line 158
  9. Very specific:

    NEVER hand-edit uv.lock (regenerate it with uv lock) or touch non-AIPerf version-like strings.

    line 160

“Common” is measured: kept by at least 6 in 10 of the 37 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Bump AIPerf Version

Bump the AIPerf package version everywhere it is hard-coded, then open a PR to main.

The runtime version is read dynamically from package metadata (importlib.metadata.version("aiperf") in src/aiperf/__init__.py), so pyproject.toml is the single source of truth. Every other occurrence is a copy in a doc example or in the mock-server package and must be updated by hand to stay in sync.

Inputs

  • Target version (e.g. 0.11.0). If the user did not provide one, read the current version from pyproject.toml and use AskUserQuestion to confirm the target (default: next minor).

Steps

  1. Confirm you are starting from an up-to-date main:
    git fetch origin
    git checkout main
    git status
    Only proceed if the working tree is clean (ignore untracked files that are not part of the bump).
  2. Find the current version: Read the version field under [project] in pyproject.toml. Call this OLD_VERSION and the requested version NEW_VERSION.
  3. Create the branch: Use the <username>/chore-update-version-<NEW_VERSION> convention, e.g.
    git checkout -b harrison/chore-update-version-0.11.0
  4. Find every hard-coded occurrence of OLD_VERSION:

    grep -rn --include="*.py" --include="*.toml" --include="*.md" \
      "<OLD_VERSION>" . | grep -v "/.git/"

    Review each hit. Update only strings that mean "the AIPerf version". Do NOT touch unrelated version-like strings (dependency pins, schema_version, sample UUIDs, etc.). uv.lock is deliberately outside this grep: other packages may share the version string, and step 5 regenerates it instead.

    The canonical set of files (as of 0.10.0 -> 0.11.0) is:

    • pyproject.toml — version = "..." under [project]
    • tests/aiperf_mock_server/pyproject.toml — version = "..." under [project]
    • docs/plugins/creating-your-first-plugin.md — the Version: ... line in the pip show example output
    • docs/server-metrics/server-metrics-json-schema.md — every "aiperf_version": "..." JSON example and the (e.g., "...") description (3 occurrences)
    • uv.lock — the root [[package]] name = "aiperf" entry, regenerated by uv lock in step 5 (never hand-edited)

    If the grep surfaces a NEW occurrence not in this list, update it too and add it to this skill's canonical list in the same PR.

  5. Regenerate uv.lock:
    uv lock
    uv.lock is tracked and records the root aiperf version, so it must move with pyproject.toml. The PR checks uv sync --locked in run-unit-tests.yml and helm-chart.yml fail on a stale lock, and after merge the nightly's uv lock --check does too. Tests that need the version import aiperf.__version__; leave those alone.
  6. Verify nothing stale remains:
    grep -rn "<OLD_VERSION>" pyproject.toml tests/aiperf_mock_server/pyproject.toml \
      docs/plugins/creating-your-first-plugin.md \
      docs/server-metrics/server-metrics-json-schema.md
    This must return no matches. Then confirm NEW_VERSION is present in each, and confirm the lockfile agrees:
    uv lock --check
    git diff uv.lock
    Expect the root aiperf version = line to change. uv lock may also refresh metadata of already-locked packages (for example add an sdist = line published after the lock was generated); that is fine to commit. Investigate if any other package's version = line changes.
  7. Run pre-commit on the staged files:
    pre-commit run
    Fix anything it flags before committing.
  8. Commit the version bump (commit 1): Stage only the version files explicitly (never git add -A — the working tree may hold unrelated untracked files):
    git add pyproject.toml uv.lock tests/aiperf_mock_server/pyproject.toml \
      docs/plugins/creating-your-first-plugin.md \
      docs/server-metrics/server-metrics-json-schema.md
    git commit -s -F - <<'EOF'
    chore: bump aiperf version to <NEW_VERSION>
    
    Updates the package and mock-server pyproject.toml versions, regenerates
    uv.lock, and refreshes the version strings shown in the plugin tutorial
    example and the server-metrics JSON schema example output.
    
    Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
    EOF
  9. Push the branch:
    git push -u origin HEAD
  10. Open the PR to main:
    gh pr create \
      --repo ai-dynamo/aiperf \
      --base main \
      --head harrison/chore-update-version-<NEW_VERSION> \
      --title "chore: bump aiperf version to <NEW_VERSION>" \
      --body "$(cat <<'EOF'
    ## Summary
    - Bump AIPerf package version from `<OLD_VERSION>` to `<NEW_VERSION>`.
    - Updates `pyproject.toml`, regenerates `uv.lock`, and updates the mock-server
      `pyproject.toml` and the version strings in the plugin tutorial and
      server-metrics JSON schema docs.
    
    The runtime version is read dynamically from package metadata, so
    `pyproject.toml` is the source of truth; the other files are doc/example copies.
    
    ## Test plan
    - `grep` confirms no `<OLD_VERSION>` strings remain in the bumped files.
    - `uv lock --check` passes.
    - Pre-commit hooks pass.
    EOF
    )"
    If gh is unavailable, print the manual compare URL: https://github.com/ai-dynamo/aiperf/compare/main...harrison/chore-update-version-<NEW_VERSION>
  11. Print a summary with the old/new version and the PR link.

Rules

  • NEVER manually add a Signed-off-by line — git commit -s adds it.
  • NEVER use --no-verify or git commit -n.
  • NEVER git add -A / git add .; stage the version files by explicit path so unrelated untracked files stay out of the commit.
  • NEVER hand-edit uv.lock (regenerate it with uv lock) or touch non-AIPerf version-like strings.
  • Branch from an up-to-date main; one PR = one concern (just the bump).

Download now (ZIP)

  • Other versions40 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 40

    1. iOfficeAI/AionUi★ 34ksame name
    2. Skyvern-AI/skyvern★ 23ksame name
    3. humanlayer/humanlayer★ 13ksame name
    4. modelcontextprotocol/csharp-sdk★ 4.6ksame name
    5. cuthbertLab/music21★ 2.6ksame name
    6. wandb/weave★ 1.1ksame name
    7. wesbos/JSON-Alexander★ 944same name
    8. opentabs-dev/opentabs★ 926same name
    9. termio-sh/termio★ 751same name
    10. use-novamira/novamira★ 751same name

    30 more not listed

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use oss-pr, pr-automation and 7 more.

    Other files people use alongside this one.

    Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
    • CES-LtdSkill

      oss-pr

      Use when creating a pull request, after committing changes, or when user invokes /oss-pr. Covers branch management, quality checks, commit, push, and PR creation.

      Also in 3 projects that use this

    • CES-LtdSkill

      pr-automation

      PR Automation Orchestrator: poll open PRs, check CI, run review, fix, and merge eligible PRs. Use when: (1) Invoked by daemon via scripts/pr-automation.sh, (2) User says "/pr-automation".

      Also in 3 projects that use this

    • volovelySkill

      pr-fix

      This skill should be used when the user asks to "fix PR comments", "address PR feedback", "resolve PR comments", provides a GitHub PR URL with intent to fix, or says "pr-fix". It reads all review comments on a PR, decides which need code fixes vs. replies, makes the fixes, and posts replies — all with explicit user approval before any GitHub action.

      Also in 3 projects that use this

    • lbednerSkill

      i18n

      Use when a code or template change introduces a new translation message key, in either the framework CLI (aegis/i18n/locales/) or a generated project's CLI (the app/i18n/locales/ template tree). Covers adding the real English string, stubbing the same key into every other locale for parity, and the separate translation PR that later replaces placeholders with reviewed native text.

      Also in 4 projects that use this

    • AnthropicSkill

      architecture

      Create or evaluate an architecture decision record (ADR). Use when choosing between technologies (e.g., Kafka vs SQS), documenting a design decision with trade-offs and consequences, reviewing a system design proposal, or designing a new component from requirements and constraints.

      Also in 4 projects that use this

    • NVIDIASkill

      testing

      Run Python and Rust tests for physicsnemo-curator using uv + pytest with coverage reporting via pytest-cov, and cargo-nextest for Rust tests. Includes benchmark workflows with pytest-benchmark and criterion.

      Also in 5 projects that use this

    • +2 more from CES-Ltd
  • In this repository13 other files it gives its agents.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.