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.

ci - Prompt - OpenSmartRoute

Name: ci
Author: PMDevSolutions

Prompt file imported from PMDevSolutions/Aurelius (.claude/commands/ci.md). Fill in {{arguments}} before use. Copyright stays with the author.

/ci — CI-Optimized Verification

Runs the same checks as /verify-all but in non-interactive, machine-readable mode. Designed for CI pipelines, pre-merge gates, and automation: no prompts, JSON output, exit code reflects overall pass/fail.

Usage

/ci
/ci --skip dead-code,security
/ci --include lint-and-format,types,tests

The slash command wraps ./scripts/verify-all.sh --ci. The --ci flag implies --json and sets non-interactive behavior. Pass --skip or --include to filter checks.

What runs

Same eight checks as /verify-all, in the same order:

lint-and-format → types → tests → accessibility → tokens → dead-code → security → bundle-size

bundle-size is automatically skipped when no build artifact (dist/, .next/, build/, out/) is present. No other check requires a dev server, so all of them run in CI without extra setup.

Output

JSON written to stdout:

{
  "ok": false,
  "summary": { "pass": 6, "fail": 1, "skip": 1, "total": 8 },
  "checks": [
    { "name": "lint-and-format", "status": "pass", "exitCode": 0, "durationMs": 2618, "reason": "" },
    { "name": "types",           "status": "fail", "exitCode": 1, "durationMs": 1843, "reason": "exit 1" },
    { "name": "tests",           "status": "pass", "exitCode": 0, "durationMs": 4205, "reason": "" },
    ...
    { "name": "bundle-size",     "status": "skip", "exitCode": 0, "durationMs": 0,    "reason": "no build artifact (dist/.next/build/out)" }
  ]
}

Field	Meaning
`ok`	`true` only when every check passed or was skipped intentionally
`summary.pass` / `fail` / `skip` / `total`	Counts across all checks
`checks[].status`	`pass` \| `fail` \| `skip`
`checks[].exitCode`	The exit code returned by the underlying check script
`checks[].durationMs`	Wall-clock duration
`checks[].reason`	Empty on pass; short reason on fail/skip

Steps

1. Run the orchestrator in CI mode

./scripts/verify-all.sh --ci {{arguments}}

2. Surface results to the user

Parse the JSON and report the summary in plain text:

6 passed, 1 failed, 1 skipped
Failing: types (exit 1, 1843ms)

When invoked from a CI pipeline, pipe the JSON straight to a downstream step or store it as a build artifact.

Exit codes

0 — every check passed or was skipped
1 — one or more checks failed

The exit code is what CI runners pivot on, so do not swallow it.

Differences vs `/verify-all`

Aspect	`/verify-all`	`/ci`
Output	Human-readable summary table	JSON to stdout
Interactivity	Allowed (no prompts today, but reserved)	Forbidden
Use case	Local development	CI pipelines, automation, scripts
Exit code on failure	1	1

/verify-all — human-readable version of the same checks
./scripts/verify-all.sh --help — full flag documentation

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

# /ci — CI-Optimized Verification Runs the same checks as `/verify-all` but in non-interactive, machine-readable mode. Designed for CI pipelines, pre-merge gates, and automation: no prompts, JSON output, exit code reflects overall pass/fail. ## Usage ``` /ci /ci --skip dead-code,security /ci --include lint-and-format,types,tests ``` The slash command wraps `./scripts/verify-all.sh --ci`. The `--ci` flag implies `--json` and sets non-interactive behavior. Pass `--skip` or `--include` to filter checks. ## What runs Same eight checks as `/verify-all`, in the same order: ``` lint-and-format → types → tests → accessibility → tokens → dead-code → security → bundle-size ``` `bundle-size` is automatically skipped when no build artifact (`dist/`, `.next/`, `build/`, `out/`) is present. No other check requires a dev server, so all of them run in CI without extra setup. ## Output JSON written to stdout: ```json { "ok": false, "summary": { "pass": 6, "fail": 1, "skip": 1, "total": 8 }, "checks": [ { "name": "lint-and-format", "status": "pass", "exitCode": 0, "durationMs": 2618, "reason": "" }, { "name": "types", "status": "fail", "exitCode": 1, "durationMs": 1843, "reason": "exit 1" }, { "name": "tests", "status": "pass", "exitCode": 0, "durationMs": 4205, "reason": "" }, ... { "name": "bundle-size", "status": "skip", "exitCode": 0, "durationMs": 0, "reason": "no build artifact (dist/.next/build/out)" } ] } ``` | Field | Meaning | |-------|---------| | `ok` | `true` only when every check passed or was skipped intentionally | | `summary.pass` / `fail` / `skip` / `total` | Counts across all checks | | `checks[].status` | `pass` \| `fail` \| `skip` | | `checks[].exitCode` | The exit code returned by the underlying check script | | `checks[].durationMs` | Wall-clock duration | | `checks[].reason` | Empty on pass; short reason on fail/skip | ## Steps ### 1. Run the orchestrator in CI mode ```bash ./scripts/verify-all.sh --ci {{arguments}} ``` ### 2. Surface results to the user Parse the JSON and report the summary in plain text: ``` 6 passed, 1 failed, 1 skipped Failing: types (exit 1, 1843ms) ``` When invoked from a CI pipeline, pipe the JSON straight to a downstream step or store it as a build artifact. ## Exit codes - `0` — every check passed or was skipped - `1` — one or more checks failed The exit code is what CI runners pivot on, so do not swallow it. ## Differences vs `/verify-all` | Aspect | `/verify-all` | `/ci` | |--------|---------------|-------| | Output | Human-readable summary table | JSON to stdout | | Interactivity | Allowed (no prompts today, but reserved) | Forbidden | | Use case | Local development | CI pipelines, automation, scripts | | Exit code on failure | 1 | 1 | ## Related - `/verify-all` — human-readable version of the same checks - `./scripts/verify-all.sh --help` — full flag documentation

{ "prompt": "# /ci — CI-Optimized Verification\n\nRuns the same checks as `/verify-all` but in non-interactive, machine-readable mode. Designed for CI pipelines, pre-merge gates, and automation: no prompts, JSON output, exit code reflects overall pass/fail.\n\n## Usage\n\n```\n/ci\n/ci --skip dead-code,security\n/ci --include lint-and-format,types,tests\n```\n\nThe slash command wraps `./scripts/verify-all.sh --ci`. The `--ci` flag implies `--json` and sets non-interactive behavior. Pass `--skip` or `--include` to filter checks.\n\n## What runs\n\nSame eight checks as `/verify-all`, in the same order:\n\n```\nlint-and-format → types → tests → accessibility → tokens → dead-code → security → bundle-size\n```\n\n`bundle-size` is automatically skipped when no build artifact (`dist/`, `.next/`, `build/`, `out/`) is present. No other check requires a dev server, so all of them run in CI without extra setup.\n\n## Output\n\nJSON written to stdout:\n\n```json\n{\n \"ok\": false,\n \"summary\": { \"pass\": 6, \"fail\": 1, \"skip\": 1, \"total\": 8 },\n \"checks\": [\n { \"name\": \"lint-and-format\", \"status\": \"pass\", \"exitCode\": 0, \"durationMs\": 2618, \"reason\": \"\" },\n { \"name\": \"types\", \"status\": \"fail\", \"exitCode\": 1, \"durationMs\": 1843, \"reason\": \"exit 1\" },\n { \"name\": \"tests\", \"status\": \"pass\", \"exitCode\": 0, \"durationMs\": 4205, \"reason\": \"\" },\n ...\n { \"name\": \"bundle-size\", \"status\": \"skip\", \"exitCode\": 0, \"durationMs\": 0, \"reason\": \"no build artifact (dist/.next/build/out)\" }\n ]\n}\n```\n\n| Field | Meaning |\n|-------|---------|\n| `ok` | `true` only when every check passed or was skipped intentionally |\n| `summary.pass` / `fail` / `skip` / `total` | Counts across all checks |\n| `checks[].status` | `pass` \\| `fail` \\| `skip` |\n| `checks[].exitCode` | The exit code returned by the underlying check script |\n| `checks[].durationMs` | Wall-clock duration |\n| `checks[].reason` | Empty on pass; short reason on fail/skip |\n\n## Steps\n\n### 1. Run the orchestrator in CI mode\n\n```bash\n./scripts/verify-all.sh --ci {{arguments}}\n```\n\n### 2. Surface results to the user\n\nParse the JSON and report the summary in plain text:\n\n```\n6 passed, 1 failed, 1 skipped\nFailing: types (exit 1, 1843ms)\n```\n\nWhen invoked from a CI pipeline, pipe the JSON straight to a downstream step or store it as a build artifact.\n\n## Exit codes\n\n- `0` — every check passed or was skipped\n- `1` — one or more checks failed\n\nThe exit code is what CI runners pivot on, so do not swallow it.\n\n## Differences vs `/verify-all`\n\n| Aspect | `/verify-all` | `/ci` |\n|--------|---------------|-------|\n| Output | Human-readable summary table | JSON to stdout |\n| Interactivity | Allowed (no prompts today, but reserved) | Forbidden |\n| Use case | Local development | CI pipelines, automation, scripts |\n| Exit code on failure | 1 | 1 |\n\n## Related\n\n- `/verify-all` — human-readable version of the same checks\n- `./scripts/verify-all.sh --help` — full flag documentation", "variables": [ "arguments" ], "notes": "Runs the same checks as `/verify-all` but in non-interactive, machine-readable mode. Designed for CI pipelines, pre-merge gates, and automation: no prompts, JSON output, exit code reflects overall pass/fail. Tools: Bash, Read.", "metadata": { "source": { "provider": "github-claude-commands", "repository": "https://github.com/PMDevSolutions/Aurelius", "path": ".claude/commands/ci.md", "ref": "de4a0ba7dd34650cef844cd7d1fbafaa50d5bbd8", "url": "https://github.com/PMDevSolutions/Aurelius/blob/de4a0ba7dd34650cef844cd7d1fbafaa50d5bbd8/.claude/commands/ci.md", "key": "PMDevSolutions/Aurelius/.claude/commands/ci.md" } } }

ci

About

/ci — CI-Optimized Verification

Usage

What runs

Output

Steps

1. Run the orchestrator in CI mode

2. Surface results to the user

Exit codes

Differences vs `/verify-all`

Related

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

About

/ci — CI-Optimized Verification

Usage

What runs

Output

Steps

1. Run the orchestrator in CI mode

2. Surface results to the user

Exit codes

Differences vs /verify-all

Related

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

Differences vs `/verify-all`