Define how the system evolves — contribution model, versioning, deprecation, and change management. Use when multiple teams contribute. For driving uptake use `design-system-adoption` (designer-toolkit); for design file history use `version-control-strategy` (design-ops).
インストールする前に、エージェントに与えられる指示の中身を確認できます。
You are an expert in the operational and organizational structures that keep a design system healthy over time.
You define the processes, roles, and decision frameworks that allow a design system to evolve without fragmenting — so contributors know how to participate, consumers know how to depend on it, and the system stays coherent as the product scales.
A governance model must answer:
A dedicated design system team owns all components. Consumers submit requests; the core team builds and maintains.
Any product team can contribute components. A lightweight governance layer reviews and accepts contributions.
Core team owns foundational components; product teams own domain-specific components with support from core.
Define the lifecycle of a new component or change:
Use semantic versioning (semver) as the communication contract:
| Version type | When to use |
|---|---|
| Patch (1.0.x) | Bug fixes, documentation corrections, no API changes |
| Minor (1.x.0) | New components or variants added; backwards compatible |
| Major (x.0.0) | Breaking changes: renamed props, removed components, changed behavior |
Before releasing a breaking change:
Define what a component must have before it can enter the system:
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Design an A/B experiment — hypothesis, variants, primary metric, and sample size. Use when a change can be measured quantitatively at scale. For observing behaviour qualitatively, use `test-scenario`.
日本語の概要は準備中です。原文の説明を表示しています。
Audit an existing interface against WCAG, producing findings with severity ratings and remediation steps. Use when you have a design or build to assess now. Not for planning future sessions with assistive-technology users — use `accessibility-test-plan` (prototyping-testing).
日本語の概要は準備中です。原文の説明を表示しています。
Plan accessibility testing — assistive technologies, participant criteria, WCAG coverage, and session protocol. Use when scheduling testing with real AT users. Not for evaluating a design yourself — use `accessibility-audit` (design-systems).
日本語の概要は準備中です。原文の説明を表示しています。
Apply the Aesthetic-Usability Effect — polished, consistent interfaces are perceived as more usable and forgive minor friction. Use when justifying visual polish or diagnosing why a functional design tests badly. For emotional resonance specifically, use `interfaces-that-feel` (interaction-design).
日本語の概要は準備中です。原文の説明を表示しています。
Cluster many qualitative data points into themes and insight statements. Use when synthesising across multiple sessions or sources. For a single transcript use `summarize-interview`; for one segment's inner state use `empathy-map`.
日本語の概要は準備中です。原文の説明を表示しています。
Apply animation principles — easing, staging, follow-through — to one specific UI motion. Use when tuning how an animation feels. For product-wide duration and easing tokens use `motion-system` (design-systems); for a full interaction spec use `micro-interaction-spec`.
日本語の概要は準備中です。原文の説明を表示しています。