SKILL ARTICLE / design-system-drift-reviewer
UIレビューで「好み」と「ルール違反」を分ける
きれいかどうかではなく、約束からずれていないかを見る。
公開デザインシステムのように原則・部品・パターンを整理し、実装画面が自分たちのルールから外れた箇所を根拠付きで報告するSkill案です。
この記事で紹介するSkill案は、参考資料を読んだうえで私が考えたものです。参照先が提供・評価・推奨しているものではありません。
OVERVIEW → CAN DO → BUILD
知ったことをSkillづくりに活かす
原則、スタイル、コンポーネント、パターンが分かれていると、好みではなく共通の根拠で画面をレビューできる。
UIの指摘に、画面上の場所と根拠となるルールを添える。
Skillが何を正しいとみなすか曖昧だと、AI自身の好みで評価してしまいます。トークン、コンポーネント仕様、アクセシビリティ方針など、優先する資料と版を入力時に固定します。
01 / OVERVIEW
資料の概要
GOV.UK Design Systemは、政府サービスをGOV.UKらしく一貫したものにするため、レイアウト、書体、色などのStyles、再利用できるComponents、利用者が共通の作業を完了するためのPatternsを分けて公開しています。
アクセシビリティも独立した重要テーマとして扱い、各チームの調査や経験を再利用することで、同じ仕事を繰り返さないことを目指しています。
02 / CAN DO
できるようになること
GOV.UKの仕組みをそのまままねる話ではありません。この記事では、「原則、部品、利用場面を正本として整理する」という考え方を、自分たちのUIレビューに応用します。
社内のデザイントークン、コンポーネント仕様、利用パターンと実際の画面・コードを照合し、指摘に画面上の場所と根拠ルールを添えます。「何となく違う」という感想と、共通ルールから外れている箇所を分けて話せるようになります。
活かしやすい場面
- 複数チームでUIのばらつきが出ている
- デザイントークンやコンポーネント集がある
- PR時に軽量なUI監査をしたい
使う前に確認したい場面
- デザインシステム自体がまだ定義されていないチーム
- ブランド刷新のように意図的な逸脱を検討する作業
03 / BUILD
自分たちのSkill作成に活かせること
文章やコードをそのまままねるのではなく、自分たちのSkillに取り入れたい判断基準や工程の分け方を整理しました。
参照する正本を最初に決める
Skillが何を正しいとみなすか曖昧だと、AI自身の好みで評価してしまいます。トークン、コンポーネント仕様、アクセシビリティ方針など、優先する資料と版を入力時に固定します。
見た目とコードの両方を見る
色や余白のずれは画面で分かっても、独自実装や誤った部品利用はコードを見なければ分かりません。出力には、スクリーンショット上の場所とコードのファイル・行番号を並べます。
違反と意図的な例外を分ける
すべての差分が修正対象とは限りません。修正候補、許容済みの例外、デザインシステム側を見直す提案に分け、人間が最終判断できる余地を残します。
04 / WORKFLOW
Skillにするときの流れ
- 01
正本を特定
参照するトークン、部品、パターンの最新版を決める。
- 02
画面とコードを照合
見た目と実装の両方から逸脱箇所を集める。
- 03
例外を分離
修正、許容、ルール更新の候補に分ける。
05 / TRY
試すときに使える依頼文
これは完成したSkillではありません。先に依頼文として試し、期待する結果が返ってくるかを確かめるための試作プロンプトです。
この画面を、リポジトリ内のデザイントークンとコンポーネント利用規約に照らしてレビューしてください。違反候補ごとに、画面上の場所・コード上の場所・根拠ルール・修正案を示し、意図的な例外の可能性は別にしてください。06 / BUILD BRIEF
試作するときの設計メモ
これは配布済みのSkillではありません。対象を小さく絞り、停止条件と評価ケースを足しながら確かめるための出発点です。
自社のデザインシステムを正本として、画面とコードの逸脱を検出するSkillを作る。
参照元の優先順位、対象外、アクセシビリティの手動確認項目、例外承認の扱いを定義する。
出力は「場所・根拠・重要度・修正案・自動修正可否」の表にそろえる。07 / WATCHOUTS
人が確認するところ
- 外部デザインシステムをそのまま自社ルールとして扱わず、参照範囲を明示します。
- 自動判定だけでアクセシビリティ適合を保証しません。キーボード操作と目視確認を残します。