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.

wo - Prompt - OpenSmartRoute

Name: wo
Author: wildbil2me

Prompt file imported from wildbil2me/grammar-studio (.claude/commands/wo.md). Fill in {{arguments}} before use. Copyright stays with the author.

Use the Agent tool to spawn the work-order-orchestrator subagent for: {{arguments}}

If no argument was given, treat it as "next" — whatever node tools/wo-gate.mjs next answers.

Run it in the background (run_in_background: true), then tell the user in one line what was dispatched, roughly how long to expect, and that .claude/dispatch/<ID>-status.md can be read meanwhile. Stay responsive while it works: a dispatch spends nearly all its time inside nested agents that surface nothing, and in the foreground a working dispatch and a hung one look the same.

One work order is two invocations, and they return different reports

The verifier is a fresh session on every work order, so /wo <ID> is run twice. Relay whichever report you actually got. Never fill in the other half from the implementer's claims.

First invocation — the implementer. It ends when the implementer returns and the row reads 🔍 AWAITING VERDICT. What comes back is the boundary report: what landed · the implementer's own account of what it could not close, labelled as its claim · that the verifier is owed. It carries no verdict and no Acceptance list, by design — do not compose one from the implementer's claims. Relay it, including how to start the verifier.

Second invocation — the verifier. Run /wo <same ID> from a new session. The orchestrator sees the 🔍 row and goes straight to the verifier. What comes back is the final report: the verdict, the Acceptance list marked verified / failed / needs-a-human, the needs-a-human items as one checklist, what can be applied and what is owed to the owner, and what is next. Relay the Acceptance list in full — the marks are the point. Nothing is ticked until the user says go.

The format is work-orders/README.md; this project's settings are work-orders/PROFILE.md. If you change how a dispatch stops, change work-order-orchestrator.md in the same sitting — nothing checks the two against each other.

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

Use the Agent tool to spawn the `work-order-orchestrator` subagent for: {{arguments}} If no argument was given, treat it as "next" — whatever `node tools/wo-gate.mjs next` answers. **Run it in the background** (`run_in_background: true`), then tell the user in one line what was dispatched, roughly how long to expect, and that `.claude/dispatch/<ID>-status.md` can be read meanwhile. Stay responsive while it works: a dispatch spends nearly all its time inside nested agents that surface nothing, and in the foreground a working dispatch and a hung one look the same. ## One work order is two invocations, and they return different reports The verifier is a **fresh session on every work order**, so `/wo <ID>` is run twice. Relay whichever report you actually got. **Never fill in the other half from the implementer's claims.** **First invocation — the implementer.** It ends when the implementer returns and the row reads `🔍 AWAITING VERDICT`. What comes back is the **boundary report**: what landed · the implementer's own account of what it could not close, **labelled as its claim** · that the verifier is owed. It carries **no verdict and no Acceptance list**, by design — do not compose one from the implementer's claims. Relay it, including how to start the verifier. **Second invocation — the verifier.** Run `/wo <same ID>` from a **new session**. The orchestrator sees the 🔍 row and goes straight to the verifier. What comes back is the **final report**: the verdict, the Acceptance list marked verified / failed / needs-a-human, the needs-a-human items as one checklist, what can be applied and what is owed to the owner, and what is next. **Relay the Acceptance list in full — the marks are the point.** Nothing is ticked until the user says go. The format is [`work-orders/README.md`](../../work-orders/README.md); this project's settings are [`work-orders/PROFILE.md`](../../work-orders/PROFILE.md). If you change how a dispatch stops, change `work-order-orchestrator.md` in the same sitting — nothing checks the two against each other.

{ "prompt": "Use the Agent tool to spawn the `work-order-orchestrator` subagent for: {{arguments}}\n\nIf no argument was given, treat it as \"next\" — whatever `node tools/wo-gate.mjs next` answers.\n\n**Run it in the background** (`run_in_background: true`), then tell the user in one line what was\ndispatched, roughly how long to expect, and that `.claude/dispatch/<ID>-status.md` can be read\nmeanwhile. Stay responsive while it works: a dispatch spends nearly all its time inside nested agents\nthat surface nothing, and in the foreground a working dispatch and a hung one look the same.\n\n## One work order is two invocations, and they return different reports\n\nThe verifier is a **fresh session on every work order**, so `/wo <ID>` is run twice. Relay whichever\nreport you actually got. **Never fill in the other half from the implementer's claims.**\n\n**First invocation — the implementer.** It ends when the implementer returns and the row reads\n`🔍 AWAITING VERDICT`. What comes back is the **boundary report**: what landed · the implementer's own\naccount of what it could not close, **labelled as its claim** · that the verifier is owed. It carries\n**no verdict and no Acceptance list**, by design — do not compose one from the implementer's claims.\nRelay it, including how to start the verifier.\n\n**Second invocation — the verifier.** Run `/wo <same ID>` from a **new session**. The orchestrator sees\nthe 🔍 row and goes straight to the verifier. What comes back is the **final report**: the verdict, the\nAcceptance list marked verified / failed / needs-a-human, the needs-a-human items as one checklist, what\ncan be applied and what is owed to the owner, and what is next. **Relay the Acceptance list in full —\nthe marks are the point.** Nothing is ticked until the user says go.\n\nThe format is [`work-orders/README.md`](../../work-orders/README.md); this project's settings are\n[`work-orders/PROFILE.md`](../../work-orders/PROFILE.md). If you change how a dispatch stops, change\n`work-order-orchestrator.md` in the same sitting — nothing checks the two against each other.", "variables": [ "arguments" ], "notes": "Dispatch a work order — gate, claim, brief, implement; or, on a row awaiting a verdict, verify Arguments: <ID | \"next\">.", "metadata": { "source": { "provider": "github-claude-commands", "repository": "https://github.com/wildbil2me/grammar-studio", "path": ".claude/commands/wo.md", "ref": "bcee5ad8ac2c6497aeabb192728e6727405b2712", "url": "https://github.com/wildbil2me/grammar-studio/blob/bcee5ad8ac2c6497aeabb192728e6727405b2712/.claude/commands/wo.md", "key": "wildbil2me/grammar-studio/.claude/commands/wo.md" } } }

wo

About

One work order is two invocations, and they return different reports

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