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.

start-debugging - Prompt - OpenSmartRoute

Name: start-debugging
Author: jesscss

Prompt file imported from jesscss/jess (.cursor/commands/start-debugging.md). Copyright stays with the author.

Start Debugging

You are starting a focused debugging session. Follow these steps. The area (extend, mixins, parser, core, jess, etc.) comes from the user or from the current-focus block in docs/state/PROJECT_STATE.md. This workflow is generic so it works for any bug, not just extend.

1. Load state (do not skip)

Read docs/state/PROJECT_STATE.md (build shape, verification commands, and current debugging focus if one is active).
If the state file or the user mentions a relevant active plan file, read that too so you know baseline and order of attack.
For extend, prefer the canonical pointers:
- .cursor/rules/subtrees/core__extend.mdc
- docs/architecture/core/EXTEND-SEMANTICS.md

2. Run the right baseline

Use section 3 in PROJECT_STATE and the current area to choose what to run. Examples:

Area	Typical baseline (from PROJECT_STATE §3)
extend	`cd packages/core && pnpm test -- --run src/ast/__tests__/extend src/ast/extend/__tests__`
core	From `packages/core`: `pnpm test -- --run` (or the path the user/plan specifies)
jess	After building core if needed: `pnpm --filter @jesscss/core build` then `pnpm run test:less:test-data` (or a single fixture – see packages/jess/test/less/README.md)

If the user specified an area (e.g. "extend", "parser"), use that. Otherwise use the current-focus "Area" field or ask. Run the baseline and report: passed, failed, and names of any failing tests.

3. Focus on one case (if user specified)

If the user asked to focus on a specific test or fixture:

Add it.only() or describe.only() in the relevant test file for that case only.
Re-run the baseline.
Proceed with the systematic debugging methodology: observe → hypothesize → trace → one small change → run test → update state. Use syncLog() only; never console.log or JSON.stringify on nodes.

4. Build dependency first (when crossing packages)

If the area involves packages that depend on another (e.g. jess tests that use core), build the dependency first so tests see updated code. See PROJECT_STATE §1–2. Example: after changing core, run pnpm --filter @jesscss/core build before jess tests.

5. Before ending session

Update docs/state/PROJECT_STATE.md (and the area’s active plan file, if any) with: what you tried, result, next step. Remove any .only before committing.

If the user provided context after the command (e.g. "focus on nested & extend all"), use that to choose the focus in step 3.

Install start-debugging 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.

# Start Debugging You are starting a focused debugging session. Follow these steps. The **area** (extend, mixins, parser, core, jess, etc.) comes from the user or from the current-focus block in `docs/state/PROJECT_STATE.md`. This workflow is generic so it works for any bug, not just extend. ## 1. Load state (do not skip) - Read `docs/state/PROJECT_STATE.md` (build shape, verification commands, and current debugging focus if one is active). - If the state file or the user mentions a relevant active plan file, read that too so you know baseline and order of attack. - For extend, prefer the canonical pointers: - `.cursor/rules/subtrees/core__extend.mdc` - `docs/architecture/core/EXTEND-SEMANTICS.md` ## 2. Run the right baseline Use **section 3** in PROJECT_STATE and the **current area** to choose what to run. Examples: | Area | Typical baseline (from PROJECT_STATE §3) | |--------|------------------------------------------| | extend | `cd packages/core && pnpm test -- --run src/ast/__tests__/extend src/ast/extend/__tests__` | | core | From `packages/core`: `pnpm test -- --run` (or the path the user/plan specifies) | | jess | After building core if needed: `pnpm --filter @jesscss/core build` then `pnpm run test:less:test-data` (or a single fixture – see packages/jess/test/less/README.md) | If the user specified an area (e.g. "extend", "parser"), use that. Otherwise use the current-focus "Area" field or ask. Run the baseline and report: passed, failed, and names of any failing tests. ## 3. Focus on one case (if user specified) If the user asked to focus on a specific test or fixture: - Add `it.only()` or `describe.only()` in the relevant test file for that case only. - Re-run the baseline. - Proceed with the systematic debugging methodology: observe → hypothesize → trace → one small change → run test → update state. Use `syncLog()` only; never `console.log` or `JSON.stringify` on nodes. ## 4. Build dependency first (when crossing packages) If the area involves packages that depend on another (e.g. jess tests that use core), build the dependency first so tests see updated code. See PROJECT_STATE §1–2. Example: after changing core, run `pnpm --filter @jesscss/core build` before jess tests. ## 5. Before ending session Update `docs/state/PROJECT_STATE.md` (and the area’s active plan file, if any) with: what you tried, result, next step. Remove any `.only` before committing. If the user provided context after the command (e.g. "focus on nested & extend all"), use that to choose the focus in step 3.

{ "prompt": "# Start Debugging\n\nYou are starting a focused debugging session. Follow these steps. The **area** (extend, mixins, parser, core, jess, etc.) comes from the user or from the current-focus block in `docs/state/PROJECT_STATE.md`. This workflow is generic so it works for any bug, not just extend.\n\n## 1. Load state (do not skip)\n\n- Read `docs/state/PROJECT_STATE.md` (build shape, verification commands, and current debugging focus if one is active).\n- If the state file or the user mentions a relevant active plan file, read that too so you know baseline and order of attack.\n- For extend, prefer the canonical pointers:\n - `.cursor/rules/subtrees/core__extend.mdc`\n - `docs/architecture/core/EXTEND-SEMANTICS.md`\n\n## 2. Run the right baseline\n\nUse **section 3** in PROJECT_STATE and the **current area** to choose what to run. Examples:\n\n| Area | Typical baseline (from PROJECT_STATE §3) |\n|--------|------------------------------------------|\n| extend | `cd packages/core && pnpm test -- --run src/ast/__tests__/extend src/ast/extend/__tests__` |\n| core | From `packages/core`: `pnpm test -- --run` (or the path the user/plan specifies) |\n| jess | After building core if needed: `pnpm --filter @jesscss/core build` then `pnpm run test:less:test-data` (or a single fixture – see packages/jess/test/less/README.md) |\n\nIf the user specified an area (e.g. \"extend\", \"parser\"), use that. Otherwise use the current-focus \"Area\" field or ask. Run the baseline and report: passed, failed, and names of any failing tests.\n\n## 3. Focus on one case (if user specified)\n\nIf the user asked to focus on a specific test or fixture:\n\n- Add `it.only()` or `describe.only()` in the relevant test file for that case only.\n- Re-run the baseline.\n- Proceed with the systematic debugging methodology: observe → hypothesize → trace → one small change → run test → update state. Use `syncLog()` only; never `console.log` or `JSON.stringify` on nodes.\n\n## 4. Build dependency first (when crossing packages)\n\nIf the area involves packages that depend on another (e.g. jess tests that use core), build the dependency first so tests see updated code. See PROJECT_STATE §1–2. Example: after changing core, run `pnpm --filter @jesscss/core build` before jess tests.\n\n## 5. Before ending session\n\nUpdate `docs/state/PROJECT_STATE.md` (and the area’s active plan file, if any) with: what you tried, result, next step. Remove any `.only` before committing.\n\nIf the user provided context after the command (e.g. \"focus on nested & extend all\"), use that to choose the focus in step 3.", "variables": [], "notes": "You are starting a focused debugging session. Follow these steps. The **area** (extend, mixins, parser, core, jess, etc.) comes from the user or from the current-focus block in `docs/state/PROJECT_STATE.md`. This workflow is generic so it works for any bug, not just extend.", "metadata": { "source": { "provider": "github-cursor-commands", "repository": "https://github.com/jesscss/jess", "path": ".cursor/commands/start-debugging.md", "ref": "257c7077fe5f0ca701e55f16a48ac69f0047583a", "url": "https://github.com/jesscss/jess/blob/257c7077fe5f0ca701e55f16a48ac69f0047583a/.cursor/commands/start-debugging.md", "key": "jesscss/jess/.cursor/commands/start-debugging.md" } } }

start-debugging

About

Start Debugging

1. Load state (do not skip)

2. Run the right baseline

3. Focus on one case (if user specified)

4. Build dependency first (when crossing packages)

5. Before ending session

Install start-debugging 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