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.

ui-sdk-write-docs - Skill - OpenSmartRoute

Name: ui-sdk-write-docs
Author: vercel-labs

Imported from vercel-labs/ui (.agents/skills/ui-sdk-write-docs/SKILL.md). Install upstream with npx skills add vercel-labs/ui --skill ui-sdk-write-docs. Copyright stays with the author.

Write ui-sdk Docs

Write in the website's current style. This skill is for contributors working on the website.

Size the work to the request. For a small edit, such as a sentence, caption, or typo, read the writing guide and the section you're changing, verify any API claim you change, and reread that section. For a new section, new page, or rewrite, follow the steps below. In either case, use only the checks the change reaches.

Honor the requested scope: a review produces findings, a draft stays in chat, and an edit changes files. Treat existing wording and structure as intentional. Preserve the maintainer's edits unless the request calls for revising them; suggest unrelated improvements separately.

1. Read the Page and Its Reference

Read Writing Website Docs and its main voice reference, Build a Component. Then read the page being changed and choose a reference for that page type from the guide. For a new page, read the neighboring pages so it continues what the reader already knows.

Identify what this page adds and which concepts can be linked instead of repeated.

2. Check What the API Does

For behavior you introduce or change in the explanation, inspect the relevant exported types, implementation, and tests. This matters especially for defaults, persistence, cancellation, SSR, and hydration. Resolve mismatches against the actual behavior rather than assuming either prose or JSDoc is correct. Keep planned capabilities separate from shipped behavior.

When writing code examples, follow ui-sdk-write-code and the relevant framework conventions.

3. Write the Explanation

Apply the writing guide to the requested scope. For changes shared across framework pages, update the corresponding copies with each framework's actual API. Framework-specific changes stay in the affected framework.

4. Read and Verify

Reread the changed section or page using the writing guide's final question. Check links, file titles, snippets, and generated references affected by the edit. Consult the docs-site guide for the implementation and the test guide for commands when these checks apply:

Walkthrough code: the React and Web Components docs-walkthrough tests extract code from Compose Behaviors and their Rendering pages. Check the extraction and run the affected tests when changing those snippets; update the tests if the documented behavior requires it.
Headings: keep TypeTable examples maps and incoming fragment links in sync with renamed headings. The maps derive anchors from heading text.
Component examples: tests/docs/props.spec.ts checks public API coverage in React examples. Preserve that coverage when replacing or removing examples, and check the corresponding framework copies.
Live demos: run the relevant specs under tests/docs/ and try changed interactions in the rendered page. Check captions and layout stability. A prose-only edit doesn't need a new demo or a full browser sweep.
MDX rendering: for changes to MDX components, tables, or framework-specific blocks, check both the rendered page and its Markdown export.

Report what changed and what was verified, including checks you couldn't run.

Install ui-sdk-write-docs 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": "vercel-labs-ui-ui-sdk-write-docs", "kind": "skill", "name": "ui-sdk-write-docs", "description": "Write or review ui-sdk website documentation in apps/docs/content/docs, including Core, framework, component, and agent guides. Use for new pages, prose edits, example explanations, and documentation reviews, following the current site's writing style.", "publisher": "vercel-labs", "version": "1.0.0", "capabilities": { "domains": [ "coding" ], "tags": [ "skill-md", "skills-sh" ], "languages": [ "en" ] }, "quality_prior": 0.6, "examples": [ "Write or review ui-sdk website documentation in apps/docs/content/docs, including Core, framework, component, and agent guides. Use for new pages, prose edits, example explanations, and documentation reviews, following the current site's writing style." ], "primary": false, "metadata": { "source": { "provider": "skills.sh", "repository": "https://github.com/vercel-labs/ui", "path": ".agents/skills/ui-sdk-write-docs/SKILL.md", "ref": "HEAD", "url": "https://github.com/vercel-labs/ui/blob/HEAD/.agents/skills/ui-sdk-write-docs/SKILL.md", "key": "vercel-labs/ui/.agents/skills/ui-sdk-write-docs/SKILL.md" } }, "instructions": "# Write ui-sdk Docs\n\nWrite in the website's current style. This skill is for contributors working on the website.\n\nSize the work to the request. For a small edit, such as a sentence, caption, or typo, read the writing guide and the section you're changing, verify any API claim you change, and reread that section. For a new section, new page, or rewrite, follow the steps below. In either case, use only the checks the change reaches.\n\nHonor the requested scope: a review produces findings, a draft stays in chat, and an edit changes files. Treat existing wording and structure as intentional. Preserve the maintainer's edits unless the request calls for revising them; suggest unrelated improvements separately.\n\n## 1. Read the Page and Its Reference\n\nRead [Writing Website Docs](../../../contributing/docs-writing.md) and its main voice reference, Build a Component. Then read the page being changed and choose a reference for that page type from the guide. For a new page, read the neighboring pages so it continues what the reader already knows.\n\nIdentify what this page adds and which concepts can be linked instead of repeated.\n\n## 2. Check What the API Does\n\nFor behavior you introduce or change in the explanation, inspect the relevant exported types, implementation, and tests. This matters especially for defaults, persistence, cancellation, SSR, and hydration. Resolve mismatches against the actual behavior rather than assuming either prose or JSDoc is correct. Keep planned capabilities separate from shipped behavior.\n\nWhen writing code examples, follow [ui-sdk-write-code](../ui-sdk-write-code/SKILL.md) and the relevant framework conventions.\n\n## 3. Write the Explanation\n\nApply the writing guide to the requested scope. For changes shared across framework pages, update the corresponding copies with each framework's actual API. Framework-specific changes stay in the affected framework.\n\n## 4. Read and Verify\n\nReread the changed section or page using the writing guide's final question. Check links, file titles, snippets, and generated references affected by the edit. Consult [the docs-site guide](../../../contributing/docs-site.md) for the implementation and [the test guide](../../../tests/README.md) for commands when these checks apply:\n\n- **Walkthrough code:** the React and Web Components `docs-walkthrough` tests extract code from Compose Behaviors and their Rendering pages. Check the extraction and run the affected tests when changing those snippets; update the tests if the documented behavior requires it.\n- **Headings:** keep `TypeTable` examples maps and incoming fragment links in sync with renamed headings. The maps derive anchors from heading text.\n- **Component examples:** `tests/docs/props.spec.ts` checks public API coverage in React examples. Preserve that coverage when replacing or removing examples, and check the corresponding framework copies.\n- **Live demos:** run the relevant specs under `tests/docs/` and try changed interactions in the rendered page. Check captions and layout stability. A prose-only edit doesn't need a new demo or a full browser sweep.\n- **MDX rendering:** for changes to MDX components, tables, or framework-specific blocks, check both the rendered page and its Markdown export.\n\nReport what changed and what was verified, including checks you couldn't run.", "cost": { "context_tokens": 833 } }

ui-sdk-write-docs

About

Write ui-sdk Docs

1. Read the Page and Its Reference

2. Check What the API Does

3. Write the Explanation

4. Read and Verify

Install ui-sdk-write-docs 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