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.

cy-design-review - Prompt - OpenSmartRoute

Name: cy-design-review
Author: cypress-io

Prompt file imported from cypress-io/cypress-design (.claude/commands/cy-design-review.md). Copyright stays with the author.

cy-design-review

Structured design and product review against the Cypress design principles, voice, and review-checklist hosted at https://design.cypress.io/agents/. Pairs with the mechanical checklist (review-checklist.md), which handles token / spacing / a11y violations.

When to run

Before merging or shipping any UI, UX, copy, or illustration work — in any Cypress repo
When generating new pages, components, or copy with AI
When asked for a design review on a proposal
Before claiming any design / UX / product task done

Steps

Identify the surface and the job. What is this — page, component, copy, illustration, AI-generated output? Who is the user (fetch https://design.cypress.io/agents/personas.md) and what's the JTBD? If you can't answer this, stop and ask the requester.
Identify the business goal. What outcome should this drive (revenue, retention, activation, lead gen, NPS)? If there isn't one named, the work isn't ready for review — fetch https://design.cypress.io/agents/principles/ux.md and apply its "Business goals + user needs" section.
Fetch the relevant principles. Always: https://design.cypress.io/agents/principles/ux.md, https://design.cypress.io/agents/principles/visual-hierarchy.md, https://design.cypress.io/agents/principles/feedback.md (delivery rules for any review). As applicable: https://design.cypress.io/agents/principles/ai.md (any AI-generated work), https://design.cypress.io/agents/illustrations.md (illustrations), https://design.cypress.io/agents/accessibility.md (interactive surfaces), https://design.cypress.io/agents/errors.md (error / warning / deprecation messages).
Fetch voice + the mechanical checklist. https://design.cypress.io/agents/voice.md for any copy. https://design.cypress.io/agents/review-checklist.md for the mechanical pass.
Walk the work against each fetched principle. For each, ask: does this design honor or violate it? Note violations with a one-line why.
Cluster findings by section. UX, visual hierarchy, copy, accessibility, AI quality, etc. Use numbered lists — see https://design.cypress.io/agents/principles/feedback.md for delivery rules.
Lead with framing problems if any exist. If the design solves the wrong JTBD, ignores business goals, or skipped the design process, that lands first — visual nits second.
Always include the WHY for each finding. A finding without a reason teaches nothing and reads as a power play.
Run the mechanical checklist last. Use https://design.cypress.io/agents/review-checklist.md to catch token, color, spacing, icon, and accessibility violations.

Output format

## Framing
(if the JTBD, persona, or business goal is unclear or wrong, name it here)

## Findings

### UX
1. <finding> — <why>

### Visual hierarchy
1. <finding> — <why>

### Copy (if applicable)
1. <finding> — <why>

### Accessibility
1. <finding> — <why>

### AI quality (if applicable)
1. <finding> — <why>

## Mechanical checklist
- [ ] colors
- [ ] spacing
- [ ] iconography
- [ ] voice
- [ ] components
- [ ] a11y

## Recommendation
<ship / revise / reframe>

Don't

Don't run on internal-only surfaces (private dashboards, throwaway docs) unless explicitly asked — see https://design.cypress.io/agents/principles/ux.md on prioritizing public-facing work.
Don't deliver findings without the WHY behind each one.
Don't gate-keep — if the framing is right and the work is good, say so directly.

Install cy-design-review 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.

# cy-design-review Structured design and product review against the Cypress design principles, voice, and review-checklist hosted at `https://design.cypress.io/agents/`. Pairs with the mechanical checklist (`review-checklist.md`), which handles token / spacing / a11y violations. ## When to run - Before merging or shipping any UI, UX, copy, or illustration work — in any Cypress repo - When generating new pages, components, or copy with AI - When asked for a design review on a proposal - Before claiming any design / UX / product task done ## Steps 1. **Identify the surface and the job.** What is this — page, component, copy, illustration, AI-generated output? Who is the user (fetch `https://design.cypress.io/agents/personas.md`) and what's the JTBD? If you can't answer this, stop and ask the requester. 2. **Identify the business goal.** What outcome should this drive (revenue, retention, activation, lead gen, NPS)? If there isn't one named, the work isn't ready for review — fetch `https://design.cypress.io/agents/principles/ux.md` and apply its "Business goals + user needs" section. 3. **Fetch the relevant principles.** Always: `https://design.cypress.io/agents/principles/ux.md`, `https://design.cypress.io/agents/principles/visual-hierarchy.md`, `https://design.cypress.io/agents/principles/feedback.md` (delivery rules for any review). As applicable: `https://design.cypress.io/agents/principles/ai.md` (any AI-generated work), `https://design.cypress.io/agents/illustrations.md` (illustrations), `https://design.cypress.io/agents/accessibility.md` (interactive surfaces), `https://design.cypress.io/agents/errors.md` (error / warning / deprecation messages). 4. **Fetch voice + the mechanical checklist.** `https://design.cypress.io/agents/voice.md` for any copy. `https://design.cypress.io/agents/review-checklist.md` for the mechanical pass. 5. **Walk the work against each fetched principle.** For each, ask: does this design honor or violate it? Note violations with a one-line _why_. 6. **Cluster findings by section.** UX, visual hierarchy, copy, accessibility, AI quality, etc. Use numbered lists — see `https://design.cypress.io/agents/principles/feedback.md` for delivery rules. 7. **Lead with framing problems if any exist.** If the design solves the wrong JTBD, ignores business goals, or skipped the design process, that lands first — visual nits second. 8. **Always include the WHY for each finding.** A finding without a reason teaches nothing and reads as a power play. 9. **Run the mechanical checklist last.** Use `https://design.cypress.io/agents/review-checklist.md` to catch token, color, spacing, icon, and accessibility violations. ## Output format ``` ## Framing (if the JTBD, persona, or business goal is unclear or wrong, name it here) ## Findings ### UX 1. <finding> — <why> ### Visual hierarchy 1. <finding> — <why> ### Copy (if applicable) 1. <finding> — <why> ### Accessibility 1. <finding> — <why> ### AI quality (if applicable) 1. <finding> — <why> ## Mechanical checklist - [ ] colors - [ ] spacing - [ ] iconography - [ ] voice - [ ] components - [ ] a11y ## Recommendation <ship / revise / reframe> ``` ## Don't - Don't run on internal-only surfaces (private dashboards, throwaway docs) unless explicitly asked — see `https://design.cypress.io/agents/principles/ux.md` on prioritizing public-facing work. - Don't deliver findings without the WHY behind each one. - Don't gate-keep — if the framing is right and the work is good, say so directly.

{ "prompt": "# cy-design-review\n\nStructured design and product review against the Cypress design principles, voice, and review-checklist hosted at `https://design.cypress.io/agents/`. Pairs with the mechanical checklist (`review-checklist.md`), which handles token / spacing / a11y violations.\n\n## When to run\n\n- Before merging or shipping any UI, UX, copy, or illustration work — in any Cypress repo\n- When generating new pages, components, or copy with AI\n- When asked for a design review on a proposal\n- Before claiming any design / UX / product task done\n\n## Steps\n\n1. **Identify the surface and the job.** What is this — page, component, copy, illustration, AI-generated output? Who is the user (fetch `https://design.cypress.io/agents/personas.md`) and what's the JTBD? If you can't answer this, stop and ask the requester.\n\n2. **Identify the business goal.** What outcome should this drive (revenue, retention, activation, lead gen, NPS)? If there isn't one named, the work isn't ready for review — fetch `https://design.cypress.io/agents/principles/ux.md` and apply its \"Business goals + user needs\" section.\n\n3. **Fetch the relevant principles.** Always: `https://design.cypress.io/agents/principles/ux.md`, `https://design.cypress.io/agents/principles/visual-hierarchy.md`, `https://design.cypress.io/agents/principles/feedback.md` (delivery rules for any review). As applicable: `https://design.cypress.io/agents/principles/ai.md` (any AI-generated work), `https://design.cypress.io/agents/illustrations.md` (illustrations), `https://design.cypress.io/agents/accessibility.md` (interactive surfaces), `https://design.cypress.io/agents/errors.md` (error / warning / deprecation messages).\n\n4. **Fetch voice + the mechanical checklist.** `https://design.cypress.io/agents/voice.md` for any copy. `https://design.cypress.io/agents/review-checklist.md` for the mechanical pass.\n\n5. **Walk the work against each fetched principle.** For each, ask: does this design honor or violate it? Note violations with a one-line _why_.\n\n6. **Cluster findings by section.** UX, visual hierarchy, copy, accessibility, AI quality, etc. Use numbered lists — see `https://design.cypress.io/agents/principles/feedback.md` for delivery rules.\n\n7. **Lead with framing problems if any exist.** If the design solves the wrong JTBD, ignores business goals, or skipped the design process, that lands first — visual nits second.\n\n8. **Always include the WHY for each finding.** A finding without a reason teaches nothing and reads as a power play.\n\n9. **Run the mechanical checklist last.** Use `https://design.cypress.io/agents/review-checklist.md` to catch token, color, spacing, icon, and accessibility violations.\n\n## Output format\n\n```\n## Framing\n(if the JTBD, persona, or business goal is unclear or wrong, name it here)\n\n## Findings\n\n### UX\n1. <finding> — <why>\n\n### Visual hierarchy\n1. <finding> — <why>\n\n### Copy (if applicable)\n1. <finding> — <why>\n\n### Accessibility\n1. <finding> — <why>\n\n### AI quality (if applicable)\n1. <finding> — <why>\n\n## Mechanical checklist\n- [ ] colors\n- [ ] spacing\n- [ ] iconography\n- [ ] voice\n- [ ] components\n- [ ] a11y\n\n## Recommendation\n<ship / revise / reframe>\n```\n\n## Don't\n\n- Don't run on internal-only surfaces (private dashboards, throwaway docs) unless explicitly asked — see `https://design.cypress.io/agents/principles/ux.md` on prioritizing public-facing work.\n- Don't deliver findings without the WHY behind each one.\n- Don't gate-keep — if the framing is right and the work is good, say so directly.", "variables": [], "notes": "Run a structured design and product review against Cypress design principles before shipping work that creates or changes a user-facing surface. Use across any Cypress repo (cypress.io, cypress-cloud, cypress-services, cypress-app, cypress-design, etc.) when reviewing a PR, evaluating a prototype, critiquing AI-generated UI / copy / illustration, or before claiming any design / UX / product task done. Triggers automatically when an agent is creating or modifying pages, components, marketing surfaces, blog posts, illustrations, copy, or making UX / product decisions on Cypress surfaces.", "metadata": { "source": { "provider": "github-claude-commands", "repository": "https://github.com/cypress-io/cypress-design", "path": ".claude/commands/cy-design-review.md", "ref": "a7b3f427df0157feaa55d7184aaea1d3efc8918b", "url": "https://github.com/cypress-io/cypress-design/blob/a7b3f427df0157feaa55d7184aaea1d3efc8918b/.claude/commands/cy-design-review.md", "key": "cypress-io/cypress-design/.claude/commands/cy-design-review.md" } } }

cy-design-review

About

cy-design-review

When to run

Steps

Output format

Don't

Install cy-design-review 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