UIスロップ除去デザイン（Unslop design）
3つのパートで構成されます: 何を修正するか（checklist.md、各修正に理由付き）、どのようにオーケストレーションするか（process.md、レビュアーと開発者が並行して作業するラウンド）、事例とソース（references.md: このスキルの発端となった5つのbefore/afterと Refactoring UI のマップ）。すべてのレビュアーが記入するスペックカードはspec-card.mdにあります。プラットフォーム別の注意事項（SwiftUI、Compose、Web、ウィジェット、Watch、Car）はplatforms.mdにあります。必要なものだけを読んでください。
原則（譲歩不可）
- 修正はルールであり、微調整ではない。 すべての変更はトークンまたはコンポーネント（スペーシング、フォントサイズ、ウェイト、カラーロール、半径、シャドウ、ボタン）として適用され、ビュー内のリテラル値としては決して使用しません。トークンがない場合は、同じ変更内で作成します。値はスケール内で除外法によって選択します（値とその両隣の2つの値を試し、中央値が勝つか、または繰り返します）。ピクセル単位で調整してはいけません。
- 色の前に階層。 画面はグレースケールで機能しなければなりません。スペーシング、サイズ、ウェイト、コントラストが役割を果たし、色はその後で、意味がある場合にのみ使用します。グレーで何が重要かが明確でなければ、色は問題を解決しません。
- 最初に読むものが答えである。 画面ごとに1つのヒーロー数値（残高、価格、今日の進捗）を設定し、他のすべては控えめにします。強調するには、競合を弱めることで行い、ヒーローを大きくすることはしません。画面ごとに最大1つのダーク/ヒーローサーフェスとし、シートやモーダル内には配置しません。
- 色は一つのことを伝える。 アクションまたはヒーロー数値には1つのブランドアクセントカラーを使用し、それ以外は意味のあるロール（お金/成功、上昇/危険、ステータス、報酬）と、ナビゲーションのみのグレーを使用します。装飾的な色 = スロップです。色は単独で使用せず、形状または単語を組み合わせます。
- コントラストは想定せず測定する。 実際の16進数値から実際の背景（ライトおよびダーク）に対して計算されたWCAG AA（テキスト4.5:1、大きいテキストとアイコン3:1）を満たします。緑/黄色のブランドカラーに白いテキストはほぼ常に不合格です。色付きの背景にグレーのテキストも同様です（同じ色相のシェードを選びます）。
- 画面が提供できないものは載せない。 架空の数値、データとして提示された予測、存在しない機能を示唆するもの、虚偽の空の状態を表示してはいけません。実際に出荷可能な最小のバージョンをデザインします。
- ドメインから抽出された、一つの特徴的なジェスチャー。 アプリが表示するもの（価格ボードの価格で最後の桁を小さくする、ランニングアプリでドットマトリックス数字）から生まれたブランドのディテールであり、新しいフォントやエフェクトではありません。また、適用されない場所では優雅に劣化します。他のすべてはネイティブに従います。タブバー、スイッチ、システムシートと戦わないでください。
- プラットフォームは一緒に出荷する。 プロジェクトにiOSとAndroid（またはアプリとWeb）がある場合、変更は同じPR内で、すべての言語に対して両方に適用します。
- ユーザーが実際に見るものを検証する。 ライトおよびダークモード、最大テキストサイズ、デフォルト以外の通貨/言語、実データ（長い名前、空、2000アイテム）のスクリーンショットを取得します。自分の環境でコンパイルできないものは、コードを読んで監査し、その旨をPRに明記します。
任意のエージェント（Claude Code、Codex、Cursor、Copilot、Gemini…）
ルールはどこでも同じです。「エージェント」と書かれている場合、使用しているツールが持つ機能を使用します。サブエージェントがある場合（Claude Code、Codex…）は、各開発者にgitワークツリーを割り当てます。サブエージェントがない場合は、レビュアーを順次実行し、各レビュアーに個別の指示を与え、審査ステップまで出力を分離します。「公開」と書かれている場合、Claude Codeはアーティファクトを公開し、他のエージェントはユーザーが開くHTMLファイルを書き出します。コードベースがないチャットアプリの場合は、before/after提案で停止します。
作業合意（デフォルト）
- レビュアー = シニアプロダクトデザイナー、開発者 = シニア開発者（エージェントとして、ユーザーが指定したモデルを使用します）。オーケストレーターは各エリアを構築せず、共通作業の実行、統合、監査を行います。
- すべての決定には、明示的で実行可能な推奨事項を付随させます。
- 実装前に、before/afterを公開し、ユーザーの「はい」を待ちます。
- 各ラウンドでは、以前のラウンドで出荷されたものと、受信したすべての動画/スクリーンショット（最新のものだけでなく）をレビューします。
- CIが成功したらマージを許可します。閉じる際には、コンパイル時に確認すべき事項（具体的なリスク）のリストと、Mac/シミュレータがない場合にはローカルセッション用の自己完結型プロンプトを添付します。
- 「すべて完了したか？」という問いには、完了（PRあり）・あなた次第・意図的に除外した、の3通りで回答します。
- 最後のラウンド後、プロジェクトのデザインシステムを更新します。
簡易フロー
- インベントリ: 動画（
process.md§ 1）からフレームを抽出し、画面と状態を特定し、各画面のコード上の位置を特定します。 - システム: スペーシング、タイポグラフィ、カラー、エレベーションのスケールを確認（または作成）します（
checklist.md§ システム）。スケールがない場合、レビュアーは目視で判断します。 - グレースケールパス + 並列レビュアー（3～4名、エリアごとに1名）が
checklist.mdに基づき、一度に1つの修正を適用します。 - 採用提案: before/after、スペックカード、決定事項リストを含む1つのHTMLページを作成し、ユーザーが選択します。
- 各エリアの開発者が隔離されたワークツリーでクローズドな指示のもと作業します。統合、コンパイル、監査、PR、レビューボットへの対応、グリーンになったらマージします。
- 最後に: 新しい内容でプロジェクトのデザインシステム（ドキュメント + トークン + 独自のスキル）を更新します。
プロジェクトに既に独自のデザインスキルがある場合
具体的なトークンとコンポーネントにはそれを使用します。このスキルはメソッドと一般的なチェックリストを提供します。ここでのルールが文書化されたプロジェクトの決定と矛盾する場合は、プロジェクトの決定が優先され、その旨が提案に記載されます。