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.

sc-implement - Prompt - OpenSmartRoute

Name: sc-implement
Author: Lordpluha

Prompt file imported from Lordpluha/supply-chain-admin-panel (.claude/commands/sc-implement.md). Fill in {{arguments}} before use. Copyright stays with the author.

description: Implement a change in this panel end to end — clarify, plan if needed, build, verify, report. argument-hint: "" [--session] [--plan] [--review] allowed-tools: Read, Write, Edit, Glob, Bash, Agent, AskUserQuestion, Skill

Implement: {{arguments}}

Routing

By default this dispatches a specialist rather than working in the current session.

Flag	Effect
(none)	Dispatch `sc-frontend-developer` for `src/`, `sc-devops` for everything else.
`--plan`	Dispatch `sc-manager` first; show the plan and confirm before any code.
`--review`	Dispatch `sc-reviewer` after the change, regardless of diff size.
`--session`	Stay in this session. Use only when the change is small enough that dispatch is pure overhead.

Defect? Route to sc-debugger instead. Visual or token work? sc-designer produces the spec, then sc-frontend-developer builds it.

Steps

Read CLAUDE.md, then the rules whose globs: match the files this will touch. Do not work from memory of the conventions.
Is the task specified? If two readings would lead to materially different work, grill first — decision tree, whole settled frontier in one round, numbered questions each with a recommended answer, then wait. Look facts up yourself; only decisions go to the developer.
Plan when the task spans more than ~3 files or touches a boundary (a new permission, a new slice, a new endpoint). sc-manager owns this.
Build. Load the fsd skill for any new slice. Reuse before creating.
Verify — actually run them:
```
pnpm verify && pnpm test
```
Review. sc-reviewer on a diff over ~100 lines or ~5 files, or on --review.
Report: what changed, which files, which gates ran and their real outcome, and anything deliberately left out with the reason.

Rules

Never report done with a red gate.
Never describe a gate you did not run.
Never push, commit, or open a PR unless the developer asked for it in this session.

Install sc-implement 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.

--- description: Implement a change in this panel end to end — clarify, plan if needed, build, verify, report. argument-hint: "<task>" [--session] [--plan] [--review] allowed-tools: Read, Write, Edit, Glob, Bash, Agent, AskUserQuestion, Skill --- Implement: **{{arguments}}** ## Routing By default this dispatches a specialist rather than working in the current session. | Flag | Effect | |---|---| | *(none)* | Dispatch `sc-frontend-developer` for `src/`, `sc-devops` for everything else. | | `--plan` | Dispatch `sc-manager` first; show the plan and confirm before any code. | | `--review` | Dispatch `sc-reviewer` after the change, regardless of diff size. | | `--session` | Stay in this session. Use only when the change is small enough that dispatch is pure overhead. | Defect? Route to `sc-debugger` instead. Visual or token work? `sc-designer` produces the spec, then `sc-frontend-developer` builds it. ## Steps 1. **Read `CLAUDE.md`**, then the rules whose `globs:` match the files this will touch. Do not work from memory of the conventions. 2. **Is the task specified?** If two readings would lead to materially different work, grill first — decision tree, whole settled frontier in one round, numbered questions each with a recommended answer, then wait. Look facts up yourself; only decisions go to the developer. 3. **Plan** when the task spans more than ~3 files or touches a boundary (a new permission, a new slice, a new endpoint). `sc-manager` owns this. 4. **Build.** Load the `fsd` skill for any new slice. Reuse before creating. 5. **Verify** — actually run them: ```bash pnpm verify && pnpm test ``` 6. **Review.** `sc-reviewer` on a diff over ~100 lines or ~5 files, or on `--review`. 7. **Report**: what changed, which files, which gates ran and their real outcome, and anything deliberately left out with the reason. ## Rules - Never report done with a red gate. - Never describe a gate you did not run. - Never push, commit, or open a PR unless the developer asked for it in this session.

{ "prompt": "---\ndescription: Implement a change in this panel end to end — clarify, plan if needed, build, verify, report.\nargument-hint: \"<task>\" [--session] [--plan] [--review]\nallowed-tools: Read, Write, Edit, Glob, Bash, Agent, AskUserQuestion, Skill\n---\n\nImplement: **{{arguments}}**\n\n## Routing\n\nBy default this dispatches a specialist rather than working in the current session.\n\n| Flag | Effect |\n|---|---|\n| *(none)* | Dispatch `sc-frontend-developer` for `src/`, `sc-devops` for everything else. |\n| `--plan` | Dispatch `sc-manager` first; show the plan and confirm before any code. |\n| `--review` | Dispatch `sc-reviewer` after the change, regardless of diff size. |\n| `--session` | Stay in this session. Use only when the change is small enough that dispatch is pure overhead. |\n\nDefect? Route to `sc-debugger` instead. Visual or token work? `sc-designer` produces the spec,\nthen `sc-frontend-developer` builds it.\n\n## Steps\n\n1. **Read `CLAUDE.md`**, then the rules whose `globs:` match the files this will touch. Do not\n work from memory of the conventions.\n\n2. **Is the task specified?** If two readings would lead to materially different work, grill\n first — decision tree, whole settled frontier in one round, numbered questions each with a\n recommended answer, then wait. Look facts up yourself; only decisions go to the developer.\n\n3. **Plan** when the task spans more than ~3 files or touches a boundary (a new permission, a\n new slice, a new endpoint). `sc-manager` owns this.\n\n4. **Build.** Load the `fsd` skill for any new slice. Reuse before creating.\n\n5. **Verify** — actually run them:\n\n ```bash\n pnpm verify && pnpm test\n ```\n\n6. **Review.** `sc-reviewer` on a diff over ~100 lines or ~5 files, or on `--review`.\n\n7. **Report**: what changed, which files, which gates ran and their real outcome, and anything\n deliberately left out with the reason.\n\n## Rules\n\n- Never report done with a red gate.\n- Never describe a gate you did not run.\n- Never push, commit, or open a PR unless the developer asked for it in this session.", "variables": [ "arguments" ], "notes": "Implement: **${arguments}**", "metadata": { "source": { "provider": "github-claude-commands", "repository": "https://github.com/Lordpluha/supply-chain-admin-panel", "path": ".claude/commands/sc-implement.md", "ref": "e7a574cbb44f6e468f055e71e4121935f404837a", "url": "https://github.com/Lordpluha/supply-chain-admin-panel/blob/e7a574cbb44f6e468f055e71e4121935f404837a/.claude/commands/sc-implement.md", "key": "Lordpluha/supply-chain-admin-panel/.claude/commands/sc-implement.md" } } }

sc-implement

About

description: Implement a change in this panel end to end — clarify, plan if needed, build, verify, report. argument-hint: "" [--session] [--plan] [--review] allowed-tools: Read, Write, Edit, Glob, Bash, Agent, AskUserQuestion, Skill

Routing

Steps

Rules

Install sc-implement 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