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.

verify-this - Skill - OpenSmartRoute

Name: verify-this
Author: cursor

Imported from cursor/plugins (cursor-team-kit/skills/verify-this/SKILL.md) via skills.sh. Install upstream with npx skills add cursor/plugins --skill verify-this. Copyright stays with the author.

Verify This

Verification is not a recap. It proves or disproves a specific claim with repeatable evidence.

When To Use

The user asks "verify this", "prove it works", "did this fix it", or "show me the evidence".
A bug fix needs a before/after repro.
A UI, CLI, API, performance, or memory claim needs measurement.
A test passes but the user-visible behavior still needs confirmation.

Do not use this for vague claims like "the code is cleaner". Ask for a measurable claim first.

Workflow

Restate the claim in falsifiable form: condition, metric, and threshold.
Pick the smallest local surface that can disprove it.
Capture a baseline from the old state: merge base, parent commit, failing branch, or current broken repro.
Capture treatment from the changed state with the same command, data, warmup, and environment.
Compare raw artifacts: numbers, screenshots, terminal transcripts, HTTP responses, profiles, heap snapshots, or test output.
Return exactly one verdict: VERIFIED, NOT VERIFIED, or INCONCLUSIVE.

Local Surfaces

Code behavior: focused unit/integration tests or a minimal repro script.
CLI/TUI behavior: control-cli, terminal transcript, or demo recording.
UI behavior: control-ui, screenshots, accessibility snapshots, or browser traces.
API behavior: local HTTP/RPC request and response diff.
Performance: same-machine baseline/treatment timings or CPU profiles.
Memory: heap snapshots before and after the suspected operation.

Artifact Layout

When safe to write artifacts:

/tmp/verify-this/<claim-slug>/
├── claim.md
├── timeline.md
├── baseline/
├── treatment/
├── diff/
└── verdict.md

If artifacts may contain sensitive code, prompts, screenshots, HTTP bodies, or heap data, keep only the minimal inline evidence unless the user agrees to disk storage.

Verdict Rules

VERIFIED: baseline and treatment differ in the predicted direction, by the claimed threshold, with no obvious confound.
NOT VERIFIED: the behavior is unchanged, moves the wrong way, or misses the threshold.
INCONCLUSIVE: no valid baseline, noisy signal, failed measurement, or an environment difference invalidates the comparison.

Output

Use this shape:

VERIFIED | NOT VERIFIED | INCONCLUSIVE
Claim: <falsifiable claim>

Evidence:
<metric/artifact>: baseline=<...>, treatment=<...>, delta=<...>, threshold=<...>

Reasoning:
<one tight paragraph naming the evidence and any confounds>

Do not soften a negative result. A clear NOT VERIFIED is useful.

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

{ "ocm": "1", "id": "cursor-plugins-verify-this", "kind": "skill", "name": "verify-this", "description": "Verify a claim with fresh local evidence: restate it falsifiably, capture baseline and treatment, compare artifacts, and return VERIFIED, NOT VERIFIED, or INCONCLUSIVE.", "publisher": "cursor", "version": "1.0.0", "capabilities": { "domains": [ "coding", "medical" ], "tags": [ "skill-md", "skills-sh" ], "languages": [ "en" ] }, "quality_prior": 0.6, "examples": [ "Verify a claim with fresh local evidence: restate it falsifiably, capture baseline and treatment, compare artifacts, and return VERIFIED, NOT VERIFIED, or INCONCLUSIVE." ], "primary": false, "metadata": { "source": { "provider": "skills.sh", "repository": "https://github.com/cursor/plugins", "path": "cursor-team-kit/skills/verify-this/SKILL.md", "ref": "HEAD", "url": "https://www.skills.sh/cursor/plugins/verify-this", "key": "cursor/plugins/cursor-team-kit/skills/verify-this/SKILL.md" } }, "instructions": "# Verify This\n\nVerification is not a recap. It proves or disproves a specific claim with repeatable evidence.\n\n## When To Use\n\n- The user asks \"verify this\", \"prove it works\", \"did this fix it\", or \"show me the evidence\".\n- A bug fix needs a before/after repro.\n- A UI, CLI, API, performance, or memory claim needs measurement.\n- A test passes but the user-visible behavior still needs confirmation.\n\nDo not use this for vague claims like \"the code is cleaner\". Ask for a measurable claim first.\n\n## Workflow\n\n1. Restate the claim in falsifiable form: condition, metric, and threshold.\n2. Pick the sm", "cost": { "context_tokens": 639 } }

verify-this

About

Verify This

When To Use

Workflow

Local Surfaces

Artifact Layout

Verdict Rules

Output

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