How long does the integration take?

Change one base URL in an OpenAI-compatible client, or install the Python or TypeScript SDK; the quickstart routes a first request in a few minutes.

Will this lock us into another vendor?

No. The router is Apache-2.0 open source, your provider keys stay yours, and the API is OpenAI-compatible, so leaving is a change of base URL.

What happens when a provider fails?

The router falls back to the next model your policy allows and records the fallback in the trace, so an outage costs a retry, not an incident.

release - Prompt - OpenSmartRoute

Name: release
Author: utensils

Prompt file imported from utensils/nxv (.claude/commands/release.md). Copyright stays with the author.

Release

Releases are driven by release-plz (release-plz.toml + .github/workflows/release-plz.yml). On every push to main it maintains a chore: release vX.Y.Z PR with the version bump and CHANGELOG update derived from conventional commits. Merging that PR ships the release — release-plz pushes the vX.Y.Z tag, which triggers release.yml (static binaries, GitHub release, crates.io, Docker) and flakehub-publish-tagged.yml.

This command walks that flow safely. Never merge the release PR without explicit user confirmation — it is an outward-facing, hard-to-reverse action.

Phase 1: Locate the release PR

gh pr list --repo utensils/nxv --search "chore: release in:title" --state open

If none exists, check whether main has unreleased conventional commits since the last tag (git log $(git describe --tags --abbrev=0)..origin/main --oneline). If there are releasable commits but no PR, check the latest Release-plz workflow run for errors (gh run list --workflow release-plz.yml).

Phase 2: Review what will ship

Show the PR's version bump (Cargo.toml diff) and CHANGELOG addition.
Verify the version follows the project convention: feat: commits bump the 0.x minor (features_always_increment_minor = true), fixes bump patch.
If the version or changelog is wrong, edit the release PR directly (it is a normal editable PR) — release-plz preserves manual edits unless new commits land on main.

Phase 3: Pre-flight

All CI checks on the release PR must be green. If checks show "Expected / Waiting", the App token is misconfigured — see release-plz.yml comments.
Confirm no other PR is about to land that should be in this release.

Phase 4: Confirm and merge

Present a summary (version, commit list, changelog) and require the user to confirm with the explicit version number (AskUserQuestion). Then:

gh pr merge <PR> --repo utensils/nxv --squash

Phase 5: Monitor

The Release-plz workflow on main pushes the tag.
The Release workflow builds binaries and publishes — monitor with gh run list --workflow release.yml / gh run watch.
Verify the GitHub release has all four binaries + SHA256SUMS.txt, crates.io has the new version, and ghcr.io has the version tag.

Manual escape hatches

Tagging failed after the release PR merged: re-run the Release-plz workflow on main (it is idempotent — existing tags are the gate).
The old fully-manual flow (bump Cargo.toml, edit CHANGELOG, tag by hand) still works in emergencies but must match release-plz's expectations (tag vX.Y.Z, CHANGELOG section ## [X.Y.Z] - YYYY-MM-DD).

Install release and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

# Release Releases are driven by **release-plz** (`release-plz.toml` + `.github/workflows/release-plz.yml`). On every push to main it maintains a `chore: release vX.Y.Z` PR with the version bump and CHANGELOG update derived from conventional commits. **Merging that PR ships the release** — release-plz pushes the `vX.Y.Z` tag, which triggers `release.yml` (static binaries, GitHub release, crates.io, Docker) and `flakehub-publish-tagged.yml`. This command walks that flow safely. Never merge the release PR without explicit user confirmation — it is an outward-facing, hard-to-reverse action. ## Phase 1: Locate the release PR ```bash gh pr list --repo utensils/nxv --search "chore: release in:title" --state open ``` If none exists, check whether main has unreleased conventional commits since the last tag (`git log $(git describe --tags --abbrev=0)..origin/main --oneline`). If there are releasable commits but no PR, check the latest `Release-plz` workflow run for errors (`gh run list --workflow release-plz.yml`). ## Phase 2: Review what will ship 1. Show the PR's version bump (Cargo.toml diff) and CHANGELOG addition. 2. Verify the version follows the project convention: `feat:` commits bump the 0.x minor (`features_always_increment_minor = true`), fixes bump patch. 3. If the version or changelog is wrong, edit the release PR directly (it is a normal editable PR) — release-plz preserves manual edits unless new commits land on main. ## Phase 3: Pre-flight 1. All CI checks on the release PR must be green. If checks show "Expected / Waiting", the App token is misconfigured — see `release-plz.yml` comments. 2. Confirm no other PR is about to land that should be in this release. ## Phase 4: Confirm and merge Present a summary (version, commit list, changelog) and require the user to confirm with the explicit version number (AskUserQuestion). Then: ```bash gh pr merge <PR> --repo utensils/nxv --squash ``` ## Phase 5: Monitor 1. The `Release-plz` workflow on main pushes the tag. 2. The `Release` workflow builds binaries and publishes — monitor with `gh run list --workflow release.yml` / `gh run watch`. 3. Verify the GitHub release has all four binaries + SHA256SUMS.txt, crates.io has the new version, and ghcr.io has the version tag. ## Manual escape hatches - Tagging failed after the release PR merged: re-run the `Release-plz` workflow on main (it is idempotent — existing tags are the gate). - The old fully-manual flow (bump Cargo.toml, edit CHANGELOG, tag by hand) still works in emergencies but must match release-plz's expectations (tag `vX.Y.Z`, CHANGELOG section `## [X.Y.Z] - YYYY-MM-DD`).

{ "prompt": "# Release\n\nReleases are driven by **release-plz** (`release-plz.toml` +\n`.github/workflows/release-plz.yml`). On every push to main it maintains a\n`chore: release vX.Y.Z` PR with the version bump and CHANGELOG update derived\nfrom conventional commits. **Merging that PR ships the release** — release-plz\npushes the `vX.Y.Z` tag, which triggers `release.yml` (static binaries, GitHub\nrelease, crates.io, Docker) and `flakehub-publish-tagged.yml`.\n\nThis command walks that flow safely. Never merge the release PR without\nexplicit user confirmation — it is an outward-facing, hard-to-reverse action.\n\n## Phase 1: Locate the release PR\n\n```bash\ngh pr list --repo utensils/nxv --search \"chore: release in:title\" --state open\n```\n\nIf none exists, check whether main has unreleased conventional commits since\nthe last tag (`git log $(git describe --tags --abbrev=0)..origin/main --oneline`).\nIf there are releasable commits but no PR, check the latest `Release-plz`\nworkflow run for errors (`gh run list --workflow release-plz.yml`).\n\n## Phase 2: Review what will ship\n\n1. Show the PR's version bump (Cargo.toml diff) and CHANGELOG addition.\n2. Verify the version follows the project convention: `feat:` commits bump\n the 0.x minor (`features_always_increment_minor = true`), fixes bump patch.\n3. If the version or changelog is wrong, edit the release PR directly\n (it is a normal editable PR) — release-plz preserves manual edits unless\n new commits land on main.\n\n## Phase 3: Pre-flight\n\n1. All CI checks on the release PR must be green. If checks show \"Expected /\n Waiting\", the App token is misconfigured — see `release-plz.yml` comments.\n2. Confirm no other PR is about to land that should be in this release.\n\n## Phase 4: Confirm and merge\n\nPresent a summary (version, commit list, changelog) and require the user to\nconfirm with the explicit version number (AskUserQuestion). Then:\n\n```bash\ngh pr merge <PR> --repo utensils/nxv --squash\n```\n\n## Phase 5: Monitor\n\n1. The `Release-plz` workflow on main pushes the tag.\n2. The `Release` workflow builds binaries and publishes — monitor with\n `gh run list --workflow release.yml` / `gh run watch`.\n3. Verify the GitHub release has all four binaries + SHA256SUMS.txt,\n crates.io has the new version, and ghcr.io has the version tag.\n\n## Manual escape hatches\n\n- Tagging failed after the release PR merged: re-run the `Release-plz`\n workflow on main (it is idempotent — existing tags are the gate).\n- The old fully-manual flow (bump Cargo.toml, edit CHANGELOG, tag by hand)\n still works in emergencies but must match release-plz's expectations\n (tag `vX.Y.Z`, CHANGELOG section `## [X.Y.Z] - YYYY-MM-DD`).", "variables": [], "notes": "Review and merge the release-plz release PR with explicit user confirmation Tools: Bash, Read, Grep, Edit, AskUserQuestion.", "metadata": { "source": { "provider": "github-claude-commands", "repository": "https://github.com/utensils/nxv", "path": ".claude/commands/release.md", "ref": "82413f05712fd67069e45f82e8256feaf546271d", "url": "https://github.com/utensils/nxv/blob/82413f05712fd67069e45f82e8256feaf546271d/.claude/commands/release.md", "key": "utensils/nxv/.claude/commands/release.md" } } }

release

About

Release

Phase 1: Locate the release PR

Phase 2: Review what will ship

Phase 3: Pre-flight

Phase 4: Confirm and merge

Phase 5: Monitor

Manual escape hatches

Install release and it becomes one more candidate the router can pick - when it fits.

What it costs to adopt - in engineering time.

One base URL

No vendor lock-in

Failover built in

Use it

Manifest

Reviews