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.

changelog - Prompt - OpenSmartRoute

Name: changelog
Author: SerZhyAle

Prompt file imported from SerZhyAle/doc-html-translate (.claude/commands/changelog.md). Copyright stays with the author.

Changelog - record "What's new"

GLOBAL DIRECTIVES:

Dry, factual, evidence-rich prose - no filler, no marketing.

Typography: short hyphens (no long dashes), Russian ё where applicable, .. not ... (CLAUDE.md).

You author only the Description. Timestamp, Path and (optionally) Target are filled by the script.

Local + free. This never pushes or publishes.

Append one row to DEV/CHANGELOG.md for the change that is done (or staged). The changelog is the build-granularity record; at release time it feeds the version's "What's new".

Usage

/changelog [short hint about the change, optional]

Run it after the code/content edit is complete - ideally with the change staged (git add -A), because the script reads the changed-file list from git.

The format (do not retype it by hand)

Timestamp - now.
Path - the changed files, taken from git diff --cached --name-only (staged), else the unstaged diff.
Target - the commit subject you pass as -Target.

You write only Description.

Process

Step 1 - Make sure the change is staged. git add -A (or stage the relevant files) so the Path column is accurate. If you deliberately want a different Path, pass -Path "a.go, b.js".

Step 2 - Pick the Target (commit subject). A conventional, user-readable subject - the same one the build/commit will use: feat: ... · fix: ... · perf: ... · docs: ... · refactor: ... · chore: .... GitHub Release notes are generated from commit subjects, so this line becomes part of the next version's "What's new".

Step 3 - Write the Description. Match the house style of the existing entries:

State what was wrong and what changed, with measured evidence, not adjectives (e.g. "a 128x104 postage stamp", "Images: 2 -> 1", "3x scale duplicate collapsed").
When behaviour was checked in a browser, say so concretely: Chrome-checked: total=1 render=1 broken=0, <embed application/pdf> present. (/verify-view produces exactly these lines - paste them in.)
Cross-edition changes: note both the Go and the JS side, and whether docs/PARITY.md moved.
One physical line is fine - inline bold/code is fine; do not use a raw | (the script escapes it, but avoid it). Keep project typography.

Step 4 - Append the row:

./scripts/add_to_dev_log.ps1 -Target "<commit subject>" -Description @'
<your Description prose>
'@

(a log -Target "..." -Description "..." is the short alias.)

Step 5 - Report the one line appended. Do not commit here unless asked - /build commits, and it calls this same script at its Step 3.

When NOT to use

You are running /build - it already records the changelog at Step 3 (this skill is what it uses).
Nothing changed yet - make the change first.

Install changelog 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.

# Changelog - record "What's new" > **GLOBAL DIRECTIVES:** > 1. Dry, factual, evidence-rich prose - no filler, no marketing. > 2. Typography: short hyphens (no long dashes), Russian **ё** where applicable, `..` not `...` (CLAUDE.md). > 3. You author **only the Description**. Timestamp, Path and (optionally) Target are filled by the script. > 4. Local + free. This never pushes or publishes. Append one row to [DEV/CHANGELOG.md](../../DEV/CHANGELOG.md) for the change that is done (or staged). The changelog is the build-granularity record; at release time it feeds the version's "What's new". ## Usage ```text /changelog [short hint about the change, optional] ``` Run it after the code/content edit is complete - ideally with the change **staged** (`git add -A`), because the script reads the changed-file list from git. ## The format (do not retype it by hand) The file is a fixed 4-column Markdown table: `| Timestamp | Path | Target | Description |`. Three columns are mechanical and the script fills them: - **Timestamp** - now. - **Path** - the changed files, taken from `git diff --cached --name-only` (staged), else the unstaged diff. - **Target** - the commit subject you pass as `-Target`. You write only **Description**. ## Process **Step 1 - Make sure the change is staged.** `git add -A` (or stage the relevant files) so the Path column is accurate. If you deliberately want a different Path, pass `-Path "a.go, b.js"`. **Step 2 - Pick the Target (commit subject).** A conventional, user-readable subject - the same one the build/commit will use: `feat: ...` · `fix: ...` · `perf: ...` · `docs: ...` · `refactor: ...` · `chore: ...`. GitHub Release notes are generated from commit subjects, so this line becomes part of the next version's "What's new". **Step 3 - Write the Description.** Match the house style of the existing entries: - State what was wrong and what changed, with **measured** evidence, not adjectives (e.g. "a 128x104 postage stamp", "Images: 2 -> 1", "3x scale duplicate collapsed"). - When behaviour was checked in a browser, say so concretely: `Chrome-checked: total=1 render=1 broken=0`, `<embed application/pdf> present`. (`/verify-view` produces exactly these lines - paste them in.) - Cross-edition changes: note both the Go and the JS side, and whether docs/PARITY.md moved. - One physical line is fine - inline **bold**/`code` is fine; do **not** use a raw `|` (the script escapes it, but avoid it). Keep project typography. **Step 4 - Append the row:** ```powershell ./scripts/add_to_dev_log.ps1 -Target "<commit subject>" -Description @' <your Description prose> '@ ``` (`a log -Target "..." -Description "..."` is the short alias.) **Step 5 - Report** the one line appended. Do not commit here unless asked - `/build` commits, and it calls this same script at its Step 3. ## When NOT to use - You are running `/build` - it already records the changelog at Step 3 (this skill is what it uses). - Nothing changed yet - make the change first.

{ "prompt": "# Changelog - record \"What's new\"\n\n> **GLOBAL DIRECTIVES:**\n> 1. Dry, factual, evidence-rich prose - no filler, no marketing.\n> 2. Typography: short hyphens (no long dashes), Russian **ё** where applicable, `..` not `...` (CLAUDE.md).\n> 3. You author **only the Description**. Timestamp, Path and (optionally) Target are filled by the script.\n> 4. Local + free. This never pushes or publishes.\n\nAppend one row to [DEV/CHANGELOG.md](../../DEV/CHANGELOG.md) for the change that is done (or staged).\nThe changelog is the build-granularity record; at release time it feeds the version's \"What's new\".\n\n## Usage\n\n```text\n/changelog [short hint about the change, optional]\n```\n\nRun it after the code/content edit is complete - ideally with the change **staged** (`git add -A`),\nbecause the script reads the changed-file list from git.\n\n## The format (do not retype it by hand)\n\nThe file is a fixed 4-column Markdown table: `| Timestamp | Path | Target | Description |`.\nThree columns are mechanical and the script fills them:\n\n- **Timestamp** - now.\n- **Path** - the changed files, taken from `git diff --cached --name-only` (staged), else the unstaged diff.\n- **Target** - the commit subject you pass as `-Target`.\n\nYou write only **Description**.\n\n## Process\n\n**Step 1 - Make sure the change is staged.** `git add -A` (or stage the relevant files) so the Path column\nis accurate. If you deliberately want a different Path, pass `-Path \"a.go, b.js\"`.\n\n**Step 2 - Pick the Target (commit subject).** A conventional, user-readable subject - the same one the\nbuild/commit will use: `feat: ...` · `fix: ...` · `perf: ...` · `docs: ...` · `refactor: ...` · `chore: ...`.\nGitHub Release notes are generated from commit subjects, so this line becomes part of the next version's\n\"What's new\".\n\n**Step 3 - Write the Description.** Match the house style of the existing entries:\n- State what was wrong and what changed, with **measured** evidence, not adjectives\n (e.g. \"a 128x104 postage stamp\", \"Images: 2 -> 1\", \"3x scale duplicate collapsed\").\n- When behaviour was checked in a browser, say so concretely: `Chrome-checked: total=1 render=1 broken=0`,\n `<embed application/pdf> present`. (`/verify-view` produces exactly these lines - paste them in.)\n- Cross-edition changes: note both the Go and the JS side, and whether docs/PARITY.md moved.\n- One physical line is fine - inline **bold**/`code` is fine; do **not** use a raw `|` (the script escapes it,\n but avoid it). Keep project typography.\n\n**Step 4 - Append the row:**\n\n```powershell\n./scripts/add_to_dev_log.ps1 -Target \"<commit subject>\" -Description @'\n<your Description prose>\n'@\n```\n\n(`a log -Target \"...\" -Description \"...\"` is the short alias.)\n\n**Step 5 - Report** the one line appended. Do not commit here unless asked - `/build` commits, and it calls\nthis same script at its Step 3.\n\n## When NOT to use\n\n- You are running `/build` - it already records the changelog at Step 3 (this skill is what it uses).\n- Nothing changed yet - make the change first.", "variables": [], "notes": "Append one row to [DEV/CHANGELOG.md](../../DEV/CHANGELOG.md) for the change that is done (or staged). The changelog is the build-granularity record; at release time it feeds the version's \"What's new\".", "metadata": { "source": { "provider": "github-claude-commands", "repository": "https://github.com/SerZhyAle/doc-html-translate", "path": ".claude/commands/changelog.md", "ref": "bdbcf943e9fbad90853fd7faec292dd41a707a62", "url": "https://github.com/SerZhyAle/doc-html-translate/blob/bdbcf943e9fbad90853fd7faec292dd41a707a62/.claude/commands/changelog.md", "key": "SerZhyAle/doc-html-translate/.claude/commands/changelog.md" } } }

changelog

About

Changelog - record "What's new"

Usage

The format (do not retype it by hand)

Process

When NOT to use

Install changelog 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