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.

sswa-verify - Prompt - OpenSmartRoute

Name: sswa-verify
Author: Kieransaunders

Prompt file imported from Kieransaunders/sswa (.windsurf/workflows/sswa-verify.md). Copyright stays with the author.

Verify the SSWA change: ${1:-the active change}. This is /opsx:verify (validate implementation vs. artifacts) extended with SSWA's git promotion: once it's correct, this command pushes, opens the PR, and verifies the change is actually working live (see step 4 — don't assume a separate test-environment checkout exists; check the project's own docs).

Read openspec-conventions, test-driven-development, and single-feature-flow first. Report every check as pass/fail with the offending file.

Preflight

Run the environment + symlink preflight (expect environment: development).

Hygiene glance (non-destructive). Run git fetch --prune and git worktree list. If you spot stale worktrees from concurrent-agent runs or a pile of merged-but-undeleted branches, mention it and point to /sswa:archive's Repo hygiene sweep. Do not delete anything here — the feature isn't merged yet, so pruning is archive's job.

1. Validate against artifacts (the opsx:verify part)

Completeness: every task in tasks.md is checked; every ### Requirement: / #### Scenario: has corresponding implementation; no scenario left uncovered.
Correctness: the implementation matches the spec's intent; edge/error scenarios are handled as written.
Coherence: any design.md decisions are reflected in the code; naming/patterns consistent.
Format gate: delta files use only ## ADDED/MODIFIED/REMOVED/RENAMED Requirements; every requirement has ≥1 #### Scenario: with exactly four hashtags; MODIFIED/REMOVED/RENAMED names match existing headers in openspec/specs/.
TDD gate: a test exists for every scenario, and the RED proof was recorded at propose time. Report issues as CRITICAL / WARNING / SUGGESTION (warnings don't block).

2. Full suite must be green

Run the full test suite. If anything is red or any task is unchecked, STOP and go back to /sswa:apply.

3. Push + open PR

git push -u origin sswa/<change-name>

Open a PR into main (confirm before creating). Title = the change title; body = the proposal's Why / What Changes / Impact, the capabilities list, and a note that the change shipped failing-test-first (link the RED proof). Use gh pr create or the repo's GitHub tooling.

4. Verify the live change

Don't assume a separate test-environment checkout exists — check the project's own docs (AGENTS.md, README) for how it actually verifies working branches first:

If the project genuinely maintains a test-environment checkout (its AGENTS.md flags environment: test somewhere, or docs say so explicitly): pull the branch there and run the full suite. The change is cleared to merge only when that's green.
Otherwise, use whatever verification mechanism the project actually documents — a local-preview technique (e.g. a symlinked worktree that lets a branch run side-by-side with the main checkout), a preview-deploy script, docker-compose up, etc. For any change with observable behavior (UI, API, CLI output), start the app and click/run through the scenarios in tasks.md's manual-verification section — don't rely on unit tests alone to certify a user-facing change. If a scenario needs live third-party data unavailable in this environment, mock the call instead of skipping the check.
Skip this step only for changes with no observable behavior (pure refactors, doc-only changes).
Report pass/fail per scenario. The change is cleared to merge only when this is green.

5. Next

On review approval and a green live verification, merge the PR to main (squash per repo convention). Once merged, run /sswa:archive to close it out.

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

Verify the SSWA change: ${1:-the active change}. This is `/opsx:verify` (validate implementation vs. artifacts) extended with SSWA's git promotion: once it's correct, this command pushes, opens the PR, and verifies the change is actually working live (see step 4 — don't assume a separate test-environment checkout exists; check the project's own docs). Read `openspec-conventions`, `test-driven-development`, and `single-feature-flow` first. Report every check as pass/fail with the offending file. ## Preflight Run the environment + symlink preflight (expect `environment: development`). **Hygiene glance (non-destructive).** Run `git fetch --prune` and `git worktree list`. If you spot stale worktrees from concurrent-agent runs or a pile of merged-but-undeleted branches, mention it and point to `/sswa:archive`'s **Repo hygiene sweep**. Do **not** delete anything here — the feature isn't merged yet, so pruning is archive's job. ## 1. Validate against artifacts (the opsx:verify part) - **Completeness:** every task in `tasks.md` is checked; every `### Requirement:` / `#### Scenario:` has corresponding implementation; no scenario left uncovered. - **Correctness:** the implementation matches the spec's intent; edge/error scenarios are handled as written. - **Coherence:** any `design.md` decisions are reflected in the code; naming/patterns consistent. - **Format gate:** delta files use only `## ADDED/MODIFIED/REMOVED/RENAMED Requirements`; every requirement has ≥1 `#### Scenario:` with **exactly four hashtags**; `MODIFIED/REMOVED/RENAMED` names match existing headers in `openspec/specs/`. - **TDD gate:** a test exists for every scenario, and the RED proof was recorded at propose time. Report issues as CRITICAL / WARNING / SUGGESTION (warnings don't block). ## 2. Full suite must be green Run the full test suite. If anything is red or any task is unchecked, STOP and go back to `/sswa:apply`. ## 3. Push + open PR ```bash git push -u origin sswa/<change-name> ``` Open a PR into `main` (confirm before creating). Title = the change title; body = the proposal's Why / What Changes / Impact, the capabilities list, and a note that the change shipped failing-test-first (link the RED proof). Use `gh pr create` or the repo's GitHub tooling. ## 4. Verify the live change Don't assume a separate test-environment checkout exists — check the project's own docs (`AGENTS.md`, `README`) for how it actually verifies working branches first: - **If the project genuinely maintains a test-environment checkout** (its `AGENTS.md` flags `environment: test` somewhere, or docs say so explicitly): pull the branch there and run the full suite. The change is cleared to merge only when that's green. - **Otherwise**, use whatever verification mechanism the project actually documents — a local-preview technique (e.g. a symlinked worktree that lets a branch run side-by-side with the main checkout), a preview-deploy script, `docker-compose up`, etc. For any change with observable behavior (UI, API, CLI output), start the app and click/run through the scenarios in `tasks.md`'s manual-verification section — don't rely on unit tests alone to certify a user-facing change. If a scenario needs live third-party data unavailable in this environment, mock the call instead of skipping the check. - Skip this step only for changes with no observable behavior (pure refactors, doc-only changes). - Report pass/fail per scenario. The change is cleared to merge only when this is green. ## 5. Next On review approval **and** a green live verification, merge the PR to `main` (squash per repo convention). Once merged, run `/sswa:archive` to close it out.

{ "prompt": "Verify the SSWA change: ${1:-the active change}. This is `/opsx:verify` (validate\nimplementation vs. artifacts) extended with SSWA's git promotion: once it's correct, this\ncommand pushes, opens the PR, and verifies the change is actually working live (see step 4\n— don't assume a separate test-environment checkout exists; check the project's own docs).\n\nRead `openspec-conventions`, `test-driven-development`, and `single-feature-flow` first.\nReport every check as pass/fail with the offending file.\n\n## Preflight\nRun the environment + symlink preflight (expect `environment: development`).\n\n**Hygiene glance (non-destructive).** Run `git fetch --prune` and `git worktree list`. If\nyou spot stale worktrees from concurrent-agent runs or a pile of merged-but-undeleted\nbranches, mention it and point to `/sswa:archive`'s **Repo hygiene sweep**. Do **not**\ndelete anything here — the feature isn't merged yet, so pruning is archive's job.\n\n## 1. Validate against artifacts (the opsx:verify part)\n- **Completeness:** every task in `tasks.md` is checked; every `### Requirement:` /\n `#### Scenario:` has corresponding implementation; no scenario left uncovered.\n- **Correctness:** the implementation matches the spec's intent; edge/error scenarios are\n handled as written.\n- **Coherence:** any `design.md` decisions are reflected in the code; naming/patterns\n consistent.\n- **Format gate:** delta files use only `## ADDED/MODIFIED/REMOVED/RENAMED Requirements`;\n every requirement has ≥1 `#### Scenario:` with **exactly four hashtags**;\n `MODIFIED/REMOVED/RENAMED` names match existing headers in `openspec/specs/`.\n- **TDD gate:** a test exists for every scenario, and the RED proof was recorded at propose\n time. Report issues as CRITICAL / WARNING / SUGGESTION (warnings don't block).\n\n## 2. Full suite must be green\nRun the full test suite. If anything is red or any task is unchecked, STOP and go back to\n`/sswa:apply`.\n\n## 3. Push + open PR\n```bash\ngit push -u origin sswa/<change-name>\n```\nOpen a PR into `main` (confirm before creating). Title = the change title; body = the\nproposal's Why / What Changes / Impact, the capabilities list, and a note that the change\nshipped failing-test-first (link the RED proof). Use `gh pr create` or the repo's GitHub\ntooling.\n\n## 4. Verify the live change\nDon't assume a separate test-environment checkout exists — check the project's own docs\n(`AGENTS.md`, `README`) for how it actually verifies working branches first:\n- **If the project genuinely maintains a test-environment checkout** (its `AGENTS.md`\n flags `environment: test` somewhere, or docs say so explicitly): pull the branch there\n and run the full suite. The change is cleared to merge only when that's green.\n- **Otherwise**, use whatever verification mechanism the project actually documents — a\n local-preview technique (e.g. a symlinked worktree that lets a branch run side-by-side\n with the main checkout), a preview-deploy script, `docker-compose up`, etc. For any\n change with observable behavior (UI, API, CLI output), start the app and click/run\n through the scenarios in `tasks.md`'s manual-verification section — don't rely on unit\n tests alone to certify a user-facing change. If a scenario needs live third-party data\n unavailable in this environment, mock the call instead of skipping the check.\n- Skip this step only for changes with no observable behavior (pure refactors, doc-only\n changes).\n- Report pass/fail per scenario. The change is cleared to merge only when this is green.\n\n## 5. Next\nOn review approval **and** a green live verification, merge the PR to `main` (squash per\nrepo convention). Once merged, run `/sswa:archive` to close it out.", "variables": [], "notes": "Validate the implementation against the change's artifacts and run the full suite — then push, open the PR, and verify the live change. (mirrors /opsx:verify, plus the PR + verification) Tools: Bash, Read, Write, Edit, Grep, Glob. Arguments: [change-name].", "metadata": { "source": { "provider": "github-windsurf-workflows", "repository": "https://github.com/Kieransaunders/sswa", "path": ".windsurf/workflows/sswa-verify.md", "ref": "7b5f40c7c84cf1b6ae66161b3ccc08c9ec9f8e28", "url": "https://github.com/Kieransaunders/sswa/blob/7b5f40c7c84cf1b6ae66161b3ccc08c9ec9f8e28/.windsurf/workflows/sswa-verify.md", "key": "Kieransaunders/sswa/.windsurf/workflows/sswa-verify.md" } } }

sswa-verify

About

Preflight

1. Validate against artifacts (the opsx:verify part)

2. Full suite must be green

3. Push + open PR

4. Verify the live change

5. Next

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