Prompts

Requirements to give an AI before it builds UI, so accessibility is part of the build: WCAG 2.2 standards kept apart from team preferences, and a report of the tests that actually ran.

Audit existing UI against WCAG 2.2 AA, with each finding marked as confirmed from code or as a check that needs a browser or assistive technology.

Define design system adoption metrics with exact denominators, exclusions, and collection methods, keep import counts apart from real UI adoption, and label targets as your own.

Turn trust levels into concrete settings for one task: which files the agent may touch, which actions it may take alone, what needs your approval, and when it must stop.

Turn brand guidelines into design tokens, keeping what the brand guide states apart from the UI decisions the guide does not cover.

Turn a loose design request into a bounded task an AI agent can finish and you can check: inputs, constraints, acceptance criteria, then a small plan with affected files, checks, and a way back.

Turn the changes in a design system release into a changelog that tells consumers what changed, whether it breaks them, and exactly what to do, using only the changes you supply.

Map primitive colours to semantic roles, with the real foreground and background pairs each role is used in, calculated contrast, interaction states, and where not to use each token.

Write a deprecation notice from verified old and new APIs, real release versions, and the tooling that actually exists, without inventing codemods or promising features the replacement lacks.

Generate component documentation from the component's code and tests, where every default, prop, and keyboard behaviour is backed by the implementation and recommendations are labelled.

Extract a structured inventory of your Figma components, with source node IDs, properties, variants, tokens, and the fields that are missing, ready to feed documentation and code.

Write a component spec from real use cases, your existing conventions, and known constraints, with confirmed requirements kept apart from proposed API decisions.

Find the variants and states a component is really missing, ranked by the product use cases that need them, and sort each gap into a variant, a state, or a separate component.

A structured critique that starts from the user, the task, and the product goal, scores against defined anchors with evidence, and says "cannot assess" instead of inventing scores from a screenshot.

Create a small set of real test cases for a prompt or skill you rely on, with pass and fail checks for each, so you can tell whether a prompt change or a new model made it better or worse.

Build a component from Figma with an AI coding agent: inspect the repository and reuse what exists first, flag behaviour the design does not define, and verify visually and by interaction.

Score your design system across tokens, components, documentation, adoption, tooling, and governance, with a defined 1-5 scale, evidence for every score, and actions you can assign.

Write either an internal investment proposal or a procurement RFP for a design system, with ROI calculated in the open from the costs and assumptions you supply.

One reusable context block that holds your design system, with versions and sources, a filled-in example, and how to load it in Claude Projects, Claude Code, or the API.

Start here for token work: pick the right prompt for creating, auditing, mapping, documenting, or exporting design tokens, in the order most teams need them.

Compare what the design file, the code, and the docs each say about a component or token, find where they disagree, and propose doc updates backed by evidence.

Compare a rendered implementation with its Figma design at the same viewport, check token usage in the code itself, and get fixes that fit the component's behaviour.

Get design tokens from Claude as JSON that always parses, using structured outputs, then check references and types with a short script before anything reaches your build.

Name icons by what they depict, not by the action they trigger in one screen, and plan renames with collisions, aliases, search synonyms, and migration effects.

Plan a design system migration from the actual release differences and an inventory of affected usages, with clear alias direction, rollout dependencies, and rollback criteria.

Build prototypes around one testable user journey: realistic data, failure states, a test scenario, and success criteria you can check with real users.

Prompts for survey analysis, competitive analysis, and trend research that require sources, dates, sample sizes, and limitations, and keep findings apart from hypotheses.

Create responsive typography, spacing, and layout tokens from your product's own breakpoints, with clamp() values checked at every viewport width and fluid versus stepped behaviour labelled.

Map a new screen or feature onto the components your design system already has: direct matches, compositions of existing parts, and the few real gaps, each with a reason.

Build a spacing scale that fits your product's density, platform, and existing layouts, with an exact rule for which steps exist and room for documented exceptions.

Generate Storybook stories that match your installed Storybook version and existing story conventions, cover every state the component supports, and include interaction tests that actually run.

Map semantic tokens to dark mode by role instead of inverting them, keep your token file's structure, and test real component pairs, overlays, elevation, and states.

Write token documentation from your real token export and the code that consumes it, without inventing class names, deprecated aliases, or usage history.

Check design token names against your own naming convention, and use values and references to catch tokens that bypass the semantic layer.

Check an AI-built screen against its acceptance criteria by actually using it, and get a report that separates verified behaviour, failures, and what nobody tested, with evidence for each.

Capture an AI session that worked into instructions you can rerun: the inputs it needs, the steps, the corrections you made along the way, the boundaries, and the checks, ready to save as a skill.