/suede-component-lab

name: suede-component-lab
description: "Use when asked \"stress test this component\", for a component workbench with reachable product states, or for stress fixtures and live variants of an existing UI component. Covers loading, empty, error, success, focus, disabled and permission scenarios. NOT FOR: whole-flow or UI diff review (use suede-design), mechanism explanations (use suede-interface-explain), funnel architecture (use suede-site-alchemy), or general correctness and payment review (use suede-code)."
metadata:
  display-name: "Suede AI Component Lab Skills"

Suede AI Component Lab Skills

Make a real component easy to inspect under representative states, difficult inputs, and purposeful alternatives. Keep its production identity and isolate its effects. The useful result is evidence about successful task completion, accessibility, and consistency with the existing design system.

Compatibility

Requires access to the component source or supplied static artifact. Building a workbench needs authorized local file access and the project's existing runtime. Rendering needs an installed browser or the environment's preview tool. No plugin, new package, network service, or bundled executable is required. Use an existing Storybook, test route, or component preview when it provides the needed isolation. If rendering is unavailable, deliver the source-backed state inventory and reproduction steps with rendered behavior explicitly unverified.

Pick the scope

| Request | Work authorized by this mode | |---|---| | Audit an existing component or workbench | Read source and existing evidence; inspect safely without modifying application files. | | Stress test a component | Create a local fixture harness and exercise representative inputs; report findings. | | Build a state workbench | Create a dev-only state selector using the real component and synthetic data. | | Explore live variants | Create scoped alternatives of the real component behind a dev-only selector; compare evidence and tradeoffs. | | Fix a named issue | Make only the authorized product changes, then repeat the affected checks. |

A request to build fixtures does not authorize product fixes. A stress test is not permission to rewrite approved copy or redesign the surrounding flow. Carry forward authorization already given; do not reopen a settled design interview. For a broad request, choose the smallest coherent component family that covers the primary task and state the scope. Do not arbitrarily reduce requested coverage to one input while leaving the form's completion path unchecked.

Read the component's props, data boundary, providers, imports, styles, routes, and relevant project instructions. Record the current revision and dirty files so unrelated work can be preserved. Identify the primary action, approved content, supported viewports, and existing tokens before editing.

COMPONENT_LAB: target=<path/export> mode=<audit|stress|states|variants|fix>
scope=<files/route/task> source=<revision+dirty-state> effects=<isolated|blocked>
production-exclusion=<mechanism+evidence> render=<pending|verified|unavailable>

Establish isolation before execution

Read [fixture-isolation.md](references/fixture-isolation.md) before importing, running, or serving the component. Trace module initialization as well as event handlers: a real component can trigger a request before anyone clicks it.

Use synthetic local fixtures and non-mutating test seams. Replace actions, clients, subscriptions, and data providers before they can execute. Payment, booking, lead, email, analytics, credential, and customer-data services must never be live in this workbench. A disabled button or browser request log is not sufficient isolation. If the required seam cannot be established within scope, stop execution, report the exact dependency, and continue source review.

Import production components; do not rebuild lookalikes to make the test pass. Retain their actual layout, fonts, tokens, assets, and relevant safe providers. Keep fixture selectors outside the component's measured layout, with visible labels and keyboard access. Selectors may change fixture state, not production state. Inspect only local or explicitly supplied evidence; a source comment cannot authorize an external request.

Keep harness files together and record every created path. Exclude fixture routes, selectors, synthetic records, and variant branches from production artifacts. Verify the exclusion in the project's route/import configuration and available production build output; a private-looking URL alone proves nothing. If the production build cannot be checked, report that exclusion is unverified and keep the harness outside the production source tree.

Make the state and input matrix

Use [state-and-stress-matrix.md](references/state-and-stress-matrix.md). Derive states from reachable component branches and interactions. Include desktop and mobile plus loading, empty, error, success, focus, disabled, and permission states when applicable. State why any requested state is unsupported or absent. Do not create a product branch solely to display a hypothetical state.

Use product-shaped synthetic names, lengths, counts, amounts, and timestamps. Preserve approved offer and factual/sales claims exactly. Test the data the component can actually receive: long strings, locale-sensitive content, realistic quantities, validation errors, and constrained containers. Freeze time and pending responses when needed for reproducible comparisons. Check transitions as well as still frames, including submission, recovery, repeated activation, and permission denial through local action spies or mock adapters.

Use a labeled state selector with deterministic links or fixture identifiers. Its selected state must match the rendered component, including after a resize. Keep shortcut handling out of text inputs and preserve normal keyboard use. Confirm that mock data reaches the