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.

verify-ds - Prompt - OpenSmartRoute

Name: verify-ds
Author: krzemienski

Prompt file imported from krzemienski/awesome-list-site (.codex/prompts/verify-ds.md). Fill in {{arguments}} before use. Copyright stays with the author.

description: Run the awesome-list-site design-system verification and report an evidence-backed verdict argument-hint: [offline|full|deep] [routes]

Verify design-system work in awesome-list-site using the awesome-ds-verify skill.

Arguments: {{arguments}} — first word is the mode (offline default, full, or deep), the optional second is a comma-separated route list for the live probe.

Read ~/.agents/skills/awesome-ds-verify/SKILL.md and follow it.
Map the mode to the runner and execute it from the repo root:
- offline → node ~/.agents/skills/awesome-ds-verify/scripts/verify-ds.mjs
- full → add --mode full (and --routes <list> if given). If the app is not reachable on :5000, start it (npm run dev, in the background, wait until it answers) — never substitute a mock or fixture.
- deep → add --mode full --deep.
Open the printed evidence directory. Read VERDICT.md and the .log of every failed gate. On a full run, view the Editorial and Brutalist screenshots under live-probe/.
Triage each failure against the matching stage of .agents/skills/verify-design-system/SKILL.md (check references/rulebook-drift.md in the skill first for stages 3, 7, 8, 9).
Report the verdict block with BLOCK / FIX / UNVERIFIED sections, each finding citing stage, gate and file:line from the log, plus the run id and evidence path.

Rules: UNVERIFIED is never PASS. An offline run cannot justify "done". Do not edit awesome-list-site-ds/, do not grow a baseline, do not fix anything unless the user asked — report first.

Install verify-ds 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.

{ "prompt": "---\ndescription: Run the awesome-list-site design-system verification and report an evidence-backed verdict\nargument-hint: [offline|full|deep] [routes]\n---\n\nVerify design-system work in awesome-list-site using the `awesome-ds-verify` skill.\n\nArguments: `{{arguments}}` — first word is the mode (`offline` default, `full`, or `deep`), the optional second is a comma-separated route list for the live probe.\n\n1. Read `~/.agents/skills/awesome-ds-verify/SKILL.md` and follow it.\n2. Map the mode to the runner and execute it from the repo root:\n - `offline` → `node ~/.agents/skills/awesome-ds-verify/scripts/verify-ds.mjs`\n - `full` → add `--mode full` (and `--routes <list>` if given). If the app is not reachable on :5000, start it (`npm run dev`, in the background, wait until it answers) — never substitute a mock or fixture.\n - `deep` → add `--mode full --deep`.\n3. Open the printed evidence directory. Read `VERDICT.md` and the `.log` of every failed gate. On a full run, view the Editorial and Brutalist screenshots under `live-probe/`.\n4. Triage each failure against the matching stage of `.agents/skills/verify-design-system/SKILL.md` (check `references/rulebook-drift.md` in the skill first for stages 3, 7, 8, 9).\n5. Report the verdict block with BLOCK / FIX / UNVERIFIED sections, each finding citing stage, gate and `file:line` from the log, plus the run id and evidence path.\n\nRules: UNVERIFIED is never PASS. An offline run cannot justify \"done\". Do not edit `awesome-list-site-ds/`, do not grow a baseline, do not fix anything unless the user asked — report first.", "variables": [ "arguments" ], "notes": "Verify design-system work in awesome-list-site using the `awesome-ds-verify` skill.", "metadata": { "source": { "provider": "github-codex-prompts", "repository": "https://github.com/krzemienski/awesome-list-site", "path": ".codex/prompts/verify-ds.md", "ref": "797c6d52ef5dc2c48c85a84354013a4fe3fc8add", "url": "https://github.com/krzemienski/awesome-list-site/blob/797c6d52ef5dc2c48c85a84354013a4fe3fc8add/.codex/prompts/verify-ds.md", "key": "krzemienski/awesome-list-site/.codex/prompts/verify-ds.md" } } }

verify-ds

About

description: Run the awesome-list-site design-system verification and report an evidence-backed verdict argument-hint: [offline|full|deep] [routes]

Use it

Install verify-ds 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

Manifest

Reviews