Design system prompts work best when they preserve the product's existing decisions. Asking an agent for a modern interface without examples often produces a new style instead of a coherent system. These prompts help inventory semantic roles, describe a component's states and plan gradual adoption. The goal is a usable shared language that makes the next product change easier to implement and review.
Supply the current visual and behavioral evidence
Include token files, representative components and screenshots that reflect the current product. State owner decisions about color, surfaces, typography and interaction. Explain any difference between public pages and the signed-in app. Ask the agent to distinguish observed values from recommendations so a documentation task does not quietly become a redesign.
The Design Tokens Format Module 2025.10 describes an exchange format for tokens. It is a community specification, not a complete design system or a guarantee of tool compatibility. Use it when interchange matters; keep semantic naming and component behavior grounded in your product.
Audit semantic roles before replacing values
A repeated color can mean text, border or selected state in different contexts. Ask the agent to identify the role and current consumers before merging values into one token. Conversely, two values serving the same role may reveal drift. The review should show concrete examples and consequences, not only a count of hard-coded declarations.
Audit design tokens in {{token_files}} and {{component_scope}}.
Use {{product_rules}} and {{reference_screens}} as constraints.
Map values to semantic roles and current consumers. Separate intentional
variation from drift. Propose only changes supported by repeated meaning.
Label observed facts and recommendations separately. Preserve the
established visual style unless the task explicitly authorizes a redesign.
Define the full component state contract
A default screenshot does not explain loading, invalid input or keyboard focus. Choose one component and list the states it actually needs. Ask how state is communicated beyond color and what happens when content is long. Include disabled and pending behavior only where the product has a reason for them.
Document the state contract for {{component}} using {{implementation}}.
Cover default, hover, focus, active and relevant loading/error/disabled
states. Describe accessible names, keyboard behavior and content limits.
Map each visual role to existing tokens. Identify gaps with a small
example and a verification step. Do not claim accessibility compliance
from token values or screenshots alone.
Plan adoption without breaking product behavior
A component replacement should preserve the interaction people rely on. Ask for a small migration slice with a clear comparison before applying it broadly. Include forms, focus management and responsive behavior in the check. A system that looks consistent but changes a familiar keyboard action has changed the product contract.
Plan adoption of {{shared_component_or_token}} in {{target_screens}}.
Identify existing variants, behavioral differences and compatibility gaps.
Choose one representative migration slice. List preserved interactions,
visual comparisons and browser checks, including long text and narrow
layouts. Define when the slice is accepted before expanding the change.
Keep guidance close to a concrete example
Write documentation around a working component and the decisions a contributor needs to make. Show when to use a variant and where an exception belongs. Remove rules that no implementation follows unless the team has accepted them as future work. This keeps the system useful without turning it into a parallel product specification.
Save your design system audit prompt in Kipt with variables for evidence, scope and owner rules. Use the Testing Library prompts for component interactions and the localization prompts for content expansion and language-specific states.