agentleFS
Sign inStart free
NVIDIAKnown publisherNVIDIA/NeMo-Relay/.agents/skills/update-project-version/SKILL.md

update-project-version

Skill238 starsChanged 2 months agoApache-2.0View on GitHub

Perform a NeMo Relay project release-version change across project-owned manifests, dependencies, lockfiles, and generated attribution surfaces while keeping just set-version coverage complete. Do not use for dependency-only updates or adding a package when no project version bump is requested.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 3 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill for project release-version changes, including prerelease and build-metadata variants.

    line 9
  2. Distinctive:

    Every new package or plugin that participates in the unified NeMo Relay release, plus its project-version dependencies and lockfile …

    line 17
  3. Very specific:

    Read the current version from Cargo.toml and choose the exact target.

    line 28
  4. Very specific:

    If a project-owned release surface remains on the old version, update the appropriate helper and rerun just set-version <version>.

    line 38
  5. Distinctive:

    Use focused checks for edited helper code and targeted packaging or generated output checks only for surfaces affected by the bump.

    line 54

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

Update Project Version

Use this skill for project release-version changes, including prerelease and build-metadata variants.

Invariants

  • Cargo.toml [workspace.package].version is the Rust source of truth.
  • just set-version <version> is the single repository entrypoint for updating normal project-version surfaces. Do not hand-edit its existing targets.
  • Every new package or plugin that participates in the unified NeMo Relay release, plus its project-version dependencies and lockfile entries, must be covered by the version automation. If a value does not derive automatically, update the automation in the same change that introduces it.
  • Python surfaces use PEP 440 translations where required; Cargo, npm, and plugin manifests use the repository SemVer form.

Workflow

Use this sequence:

  1. Read the current version from Cargo.toml and choose the exact target.
  2. Compare project-owned package/workspace members and plugin manifests with the helpers called by set_project_version, paying particular attention to recent or in-scope additions. A new manifest, publishable package, internal dependency pinned to the project version, or lockfile package entry is a signal that just set-version may need to change.
  3. Run just set-version <version>.
  4. Review the diff, then search tracked Cargo, Python, npm, lockfile, and plugin manifests for the exact old version. Classify matches rather than replacing them blindly: third-party pins and examples can legitimately match.
  5. If a project-owned release surface remains on the old version, update the appropriate helper and rerun just set-version <version>. Read references/version-automation.md only when the version topology or helper implementation changes.
  6. Refresh lockfiles or attribution files only when their versioned inputs changed. Do not run language suites for a metadata-only bump.

Verification

Before handoff, verify:

  • Confirm every project-owned manifest version and internal dependency resolves to the target SemVer or its expected PEP 440 translation, and that unrelated versions did not change.
  • Rerun just set-version <version> when automation changed; it should be idempotent and report no missing expected fields.
  • Use focused checks for edited helper code and targeted packaging or generated output checks only for surfaces affected by the bump.

Temporary versions produced by packaging recipes are not the canonical project version unless the release workflow explicitly requires that exact suffix.

References

  • Cargo.toml
  • justfile
  • references/version-automation.md — only for adding, removing, or debugging a versioned surface or version helper

Download now (ZIP)

Does it work?

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

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

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.

Check your setup, free