ui-design

UI：再利用し、新たに作り出さない

../rule-maker/rules/design.md（インストール済みの兄弟スキル）とCONTRACT.mdを読んでください。これは権限と選択に関するスキルであり、デザイナーでも別の実装ワークフローでもありません。通常のルール準備状況の確認、詳細な聞き取り、計画レビュー、実装承認は引き続き必要です。

1. 対象範囲と判断を明確にする

タスク、フレームワークのバージョン、影響を受ける領域／ブランド／プラットフォーム、指定されたプロジェクトの参照元、既存の変更、適用されるルールを特定します。UIコントラクトを変更しないバックエンドのみの作業では、このスキルを省略します。同等に権威ある参照元がある場合、DESIGN.md というファイル名が見つからなくても妨げにはなりません。そのファイル、カタログ、見慣れたクラスが存在するだけでは、選択や承認がなされたことにはなりません。

新規の実質的な UI タスクでは、正確な参照元と、選択されたコンポーネント／パターンの ID、バリアント、状態を確認します。明示されたオーナーの選択、または現在も有効な同一タスク内の決定を再利用します。未解決の点がある場合は一度だけ質問し、重要な未確定事項はまとめて詳細な聞き取りで確認します。すべてのコントロールについて、または変更のない作業再開時に、何度も質問してはいけません。

2. 許可されたモードを選択する

共有ルールメーカーの rules/design.md で定義されている動作のみ、再利用、ブロック、指示によるプレーン実装のいずれかを正確に選びます。CONTRACT.mdには、各モードで許可されることと禁止されることが記載されています。新規または変更する要素ごとに、デザインキット（存在する場合）と既存コードを検索し、模倣する要素を file:line、タグ、クラス、および必要なラッパーとして記録します（python -X utf8 -I scripts/class_rules.py <project-root> <class>... を実行すると、各クラスのすべてのルールが一覧表示され、コンテキストが必要なものには印が付きます）。どのモードでも、新しい CSS は作成しません。ユーザーから明示的な指示がない限り、新しいプレーン HTML コントロールも作成しません。ブロックされた要素については、design.md のルール 4 にある正確な質問にユーザーが回答するまで待ちます。同じタグに該当する既存要素のみを提示し、プレーン HTML の推奨、新しい CSS、別のタグのクラスは提示しません。指示によるプレーン実装の例外は、包括的な肯定ではなく、design.md のルール 4 を満たす必要があります。独立したロジックとテストは続行できます。

kit-audit、kit-setup、kit-check には KIT.md を、コードに基づく検出には LIVE-KIT.md を使用します。デザイナーが手動で変更した場合は、scripts/design_drift.py --root <project> を実行します。その結果は LIVE-KIT.md の説明に従って調整します。セットアップでは、アプリケーション内の開発専用キットの導入ルートを監査／提案し、templates/DESIGN.md をもとに DESIGN.md を作成できますが、アプリケーションのプレゼンテーションを作成したり、ツールをインストールしたり、新しいコンポーネントを承認したりすることはできません。デザイナーによる変更は調整対象となる外部入力であり、このエージェントが CSS を記述する許可にはなりません。以前のモード名の対応関係は CONTRACT.md の記載どおりです。

3. 既存の計画／レポートを準備する

PLAN/STATUS に、モード、対象範囲、権限、安定した項目／ストーリー ID、コンポーネントと例のソース、バリエーション／状態、選択したパターン、プレビューへのアクセス、残っているデザイン／リリース上の制約を簡潔に記録します。選択ごとにコンポーネント一覧を重複して作成したり、新しいフォルダーを作ったりしないでください。EXAMPLES.md を使用してください。

スタイル付きの参考資料を手早く確認するには、既存の HTML とコンパイル済み CSS を使って ui_review.quick_previews を使用してください。codebase-map/UI-FLOW.md を参照してください。プロトタイプをビルドしたり、フレームワークが実際にレンダリングされたと主張したりしないでください。

UI に表示される変更にはすべて、ローカルの codebase-map にある同じ完全な HTML レポートの ui_review の画面フロー表示に、画面図を含めます。現在の画面と提案する画面をインタラクションの矢印でつなぎ、画面ごとに再利用する要素とそのソースファイルを示してください。安全に開ける場合は現在の画面をキャプチャします（ローカルの静的ページは codebase-map の scripts/screenshot_report.py でキャプチャできます）。提案する画面は、実際に存在するまでは再利用する要素のみで作成した、ラベル付きのレイアウトスケッチとします。納品時のスナップショットで実際の結果をキャプチャします。スケッチが示すのは構造であり、見た目ではありません。キャプチャまたはユーザーのデバイスでの確認が必要なため、スケッチで見た目や読みやすさを判断できるとユーザーに伝えてはいけません。画面図のない UI 表示上の変更がある場合、レポートはドラフトのままです。必須の内容とスナップショットの確認については codebase-map/UI-FLOW.md を読んでください。承認済みのレポートの枠組みは変更しないでください。

重要な判断事項を解決し、計画／レポートを提示して、オーナーの承認を待ちます。動作の承認は、確認されていないデザインの承認ではありません。スラッシュコマンドがなくても、新たな通常の UI リクエストにはこれらのゲートを適用します。

4. 許可された再利用のみを実装して検証する

選択した ID、API、パターン、ソースのリビジョン、保護された内部要素、プレビューの許可を、ワーカーにそのまま渡します。CSS、インラインスタイル、任意のビジュアルプロパティは使用しません。新しい要素は既存要素のクラスとタグを引き継ぐか、ユーザーがそのように指定した場合に限り、装飾のない要素にします。既存の機能セレクターとランタイムの契約を維持してください。アクセシビリティは必須です。アクセシブルな既存要素を再利用するか、確認を求めてください。アクセシビリティに問題のある代替要素を出荷してはいけません。完了する前に、使用したクラスと、それを定義しているファイルをすべて列挙し、CSS を追加していないことを確認してください。

実際の最終差分と関連するランタイム状態に VERIFY.md を適用します。プレビューを実行する前に、ソース／バリエーション／スコープの最新性、安全な環境、ビルドの許可を確認してください。スキャナーが問題なしと判定しても、承認を意味するわけではありません。承認済みの参考資料を保持し、成果物ポリシーに従ってください。

更新／削除／再開時は、影響を受けるソース／利用箇所のみを照合します。コンポーネントが見つからない場合、その選択はブロックされます。コンポーネントに変更がある場合はレビューが必要で、自動的に再承認してはいけません。過去のキャプチャと判断を保持してください。動作の検証済み、デザインの承認済み、リリース準備完了をそれぞれ分けて報告します。実際に確認していない限り、ライブキットがインストールされた、またはすべてのホストがルールに従っていると主張してはいけません。