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-check - Prompt - OpenSmartRoute

Name: ui-check
Author: Marcus100

Prompt file imported from Marcus100/grenmet (.claude/commands/ui-check.md). Copyright stays with the author.

UI Check

Figma is not linked to this repo. The design reference is a Claude Design canvas, a screenshot the user supplies, or a written description. Never ask for a Figma frame URL or reach for a Figma MCP tool.

Step 1 — Gather info Ask the user for:

The design reference (Claude Design canvas, a pasted/attached screenshot, or a description)
The component file path (or "new component" if creating from scratch)
Target viewport(s): mobile (375px), desktop (1280px), or both

Do not proceed until you have all three. If the user has no reference yet, establish intent from the existing design lane and the user's description; use an available design skill if useful.

Step 2 — Establish the design intent From the reference, write down the intended colors, typography (size, weight, line-height, family), spacing, border-radius, layout direction, and component hierarchy.

Map every value onto the token contract before comparing: a color must resolve to a --gm-* token, a Tailwind alias, or a shadcn semantic. If an intended value has no token, say so explicitly — that is a token request needing user approval, not something to hardcode.

Step 3 — Audit the current implementation Read the component file. Compare it against the intended values. List every discrepancy:

Typography (weight, size, line-height, family)
Spacing (padding, margin, gap)
Color (background, text, border)
Border radius
Layout / alignment
Missing or extra elements

Present this list to the user. Do not edit files yet.

Step 4 — Propose changes For an implementation request, apply changes within the authorized scope. For a review-only request, show proposed changes without editing; existing authorization counts. Flag separately any change that would need a new or altered --gm-* token.

Step 5 — Apply and hand off After approval, apply the changes. Run pnpm design-system:check to confirm the token contract still holds. Tell the user which dev command to run to preview (pnpm dev:web:gms, pnpm dev:web:gaa-admin, etc. — see docs/ports.md) and ask them to screenshot the result.

Dev servers run on the host, never inside the devcontainer.

Step 6 — Iterate When the user shares the screenshot or describes remaining issues, return to Step 3 with the updated state. Continue until the user declares done.

Install ui-check 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.

## UI Check Figma is not linked to this repo. The design reference is a Claude Design canvas, a screenshot the user supplies, or a written description. Never ask for a Figma frame URL or reach for a Figma MCP tool. **Step 1 — Gather info** Ask the user for: - The design reference (Claude Design canvas, a pasted/attached screenshot, or a description) - The component file path (or "new component" if creating from scratch) - Target viewport(s): mobile (375px), desktop (1280px), or both Do not proceed until you have all three. If the user has no reference yet, establish intent from the existing design lane and the user's description; use an available design skill if useful. **Step 2 — Establish the design intent** From the reference, write down the intended colors, typography (size, weight, line-height, family), spacing, border-radius, layout direction, and component hierarchy. Map every value onto the token contract before comparing: a color must resolve to a `--gm-*` token, a Tailwind alias, or a shadcn semantic. If an intended value has no token, say so explicitly — that is a token request needing user approval, not something to hardcode. **Step 3 — Audit the current implementation** Read the component file. Compare it against the intended values. List every discrepancy: - Typography (weight, size, line-height, family) - Spacing (padding, margin, gap) - Color (background, text, border) - Border radius - Layout / alignment - Missing or extra elements Present this list to the user. Do not edit files yet. **Step 4 — Propose changes** For an implementation request, apply changes within the authorized scope. For a review-only request, show proposed changes without editing; existing authorization counts. Flag separately any change that would need a new or altered `--gm-*` token. **Step 5 — Apply and hand off** After approval, apply the changes. Run `pnpm design-system:check` to confirm the token contract still holds. Tell the user which dev command to run to preview (`pnpm dev:web:gms`, `pnpm dev:web:gaa-admin`, etc. — see `docs/ports.md`) and ask them to screenshot the result. Dev servers run on the host, never inside the devcontainer. **Step 6 — Iterate** When the user shares the screenshot or describes remaining issues, return to Step 3 with the updated state. Continue until the user declares done.

{ "prompt": "## UI Check\n\nFigma is not linked to this repo. The design reference is a Claude Design canvas,\na screenshot the user supplies, or a written description. Never ask for a Figma\nframe URL or reach for a Figma MCP tool.\n\n**Step 1 — Gather info**\nAsk the user for:\n- The design reference (Claude Design canvas, a pasted/attached screenshot, or a description)\n- The component file path (or \"new component\" if creating from scratch)\n- Target viewport(s): mobile (375px), desktop (1280px), or both\n\nDo not proceed until you have all three. If the user has no reference yet, establish intent from the existing design lane and the user's description; use an available design skill if useful.\n\n**Step 2 — Establish the design intent**\nFrom the reference, write down the intended colors, typography (size, weight,\nline-height, family), spacing, border-radius, layout direction, and component\nhierarchy.\n\nMap every value onto the token contract before comparing: a color must resolve to\na `--gm-*` token, a Tailwind alias, or a shadcn semantic. If an intended value has\nno token, say so explicitly — that is a token request needing user approval, not\nsomething to hardcode.\n\n**Step 3 — Audit the current implementation**\nRead the component file. Compare it against the intended values. List every\ndiscrepancy:\n- Typography (weight, size, line-height, family)\n- Spacing (padding, margin, gap)\n- Color (background, text, border)\n- Border radius\n- Layout / alignment\n- Missing or extra elements\n\nPresent this list to the user. Do not edit files yet.\n\n**Step 4 — Propose changes**\nFor an implementation request, apply changes within the authorized scope. For a review-only request, show proposed changes without editing; existing authorization counts.\nFlag separately any change that would need a new or altered `--gm-*` token.\n\n**Step 5 — Apply and hand off**\nAfter approval, apply the changes. Run `pnpm design-system:check` to confirm the\ntoken contract still holds. Tell the user which dev command to run to preview\n(`pnpm dev:web:gms`, `pnpm dev:web:gaa-admin`, etc. — see `docs/ports.md`) and ask\nthem to screenshot the result.\n\nDev servers run on the host, never inside the devcontainer.\n\n**Step 6 — Iterate**\nWhen the user shares the screenshot or describes remaining issues, return to\nStep 3 with the updated state. Continue until the user declares done.", "variables": [], "notes": "Implement or refine a UI component against a design reference — extract intent, list discrepancies, propose changes, iterate Tools: Bash(pnpm dev:*), Bash(pnpm design-system:*), Read, Edit, Glob, Grep.", "metadata": { "source": { "provider": "github-claude-commands", "repository": "https://github.com/Marcus100/grenmet", "path": ".claude/commands/ui-check.md", "ref": "2ad41d133d2616de66d3236d1eb0205f4bf80ff7", "url": "https://github.com/Marcus100/grenmet/blob/2ad41d133d2616de66d3236d1eb0205f4bf80ff7/.claude/commands/ui-check.md", "key": "Marcus100/grenmet/.claude/commands/ui-check.md" } } }

ui-check

About

UI Check

Install ui-check 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