AIエージェント用のデザインツールを作り、コマンドとチェックを整える

## デザインのコマンドを1つのスキルにまとめ、資料を1か所に置く ユーザー向けのコマンド体系をコンパクトに保ち、対応した各コマンドを対象が明確な参照資料へルーティングします。統合によりメニューのノイズが減り、共有デザイン原則を保守しやすくなります。 ### コマンドアーキテクチャ - 本当に別のライフサイクルが必要な場合を除き、多数の独立スキルよりも、サブコマンドを持つ一つのユーザー実行可能なデザインスキルを優先します。 - 各コマンドと参照ファイルの対応を定義するルーターテーブルを一つだけ保守します。 - コマンドの説明、引数のヒント、カテゴリー、関係性は、ビルドとショートカット生成ツールが利用する正本メタデータに保管します。 - プロバイダーごとのコピーを個別編集せず、一つのソースからプロバイダー別スキルファイルを生成します。 - 軽量ショートカットは正本コマンドへのリダイレクトとしてだけ使用します。 - 共有原則は共通ソースに、コマンド固有の判断は対応する参照資料に置きます。共有ガイダンスを重複させずリンクします。 ### コンテキストルーティング - レジスターやプラットフォームのルールブックを選ぶ前に、プロジェクトのコンテキストを読みます。 - 明示的なプロジェクト項目を最優先し、次にタスクと表示面の手掛かりを使い、最後に文書化された既定値を使います。 - 認識できないコンテキスト値には、無関係なルールブックを黙って適用せず警告します。 - コマンドのプラットフォーム動作が大きく異なる場合は、既定ファイルではなく派生版の参照資料を読み込みます。 ## ブランド用かアプリ画面用かを決めてから、Webや各OSの決まりを重ねる デザインの目的と配信プラットフォームを独立した軸として扱います。レジスターは体験の目標を定義し、プラットフォームは操作規則と実装制約を定義します。 ### デザインレジスター - デザイン自体が商品となるマーケティング、キャンペーン、ポートフォリオ、編集体験、特色ある公開面にはブランドレジスターを使用します。 - ブランド制作は、一つの流行スタイルを強制せず、多様な視覚路線にわたる独自性で評価します。 - アプリケーション、ダッシュボード、管理画面、ツールを支えるデザインにはプロダクトレジスターを使用します。 - プロダクト制作は、使い込むことで得られる親しみやすさ、信頼、熟練ユーザーが円滑に操作できることを基準に評価します。 - レジスターは後続のデザイン判断を変えるため、早い段階で確認します。 ### プラットフォーム - レスポンシブWeb、単一のネイティブプラットフォーム、適応型クロスプラットフォーム配信を区別します。 - プラットフォームをデザイン目的の代替と見なさず、選択したレジスターの上にネイティブプラットフォームのガイダンスを重ねます。 - 適応型プロダクトでは両方のネイティブルールブックを適用し、OSごとに調整します。全プラットフォームで一つの視覚表現を使うだけでは適応型になりません。 - ソースファイルがWebに似た拡張子を使っていても、ネイティブプロジェクトではブラウザオーバーレイ、HTML検出ツール、ライブWebフックを無効に保ちます。 - アクセシビリティ検証は専用の監査経路に置きます。創作生成中に一般的なアクセシビリティ注意を繰り返し挿入し、安全ではあっても設計不足の成果にしないようにします。 ## 色の使い方と、公開する文章の禁止表現リストを守る デザイン変数、レイアウトコード、編集上の語り口、公開コンテンツには明示的な責任者と自動チェックが必要ですが、人間のデザイン判断を置き換えてはいけません。 ### 視覚の基礎 - 一つの入口、共有デザイン変数、対象を絞った部分ファイルを持つ、小さく確認しやすいスタイル構成を優先します。 - 意味に基づく色変数を一貫して使います。本文には最もコントラストの高い文字色を使い、柔らかい暗色は文字サイズが十分な箇所だけに使い、控えめな色は補助ラベルに使います。 - 視覚システムが色味を帯びた両極を定義している場合は、純粋な黒と純粋な白を避けます。 - 実装規則を適用対象の近くに置き、対応している場合はホットリロード動作を保ちます。 ### 編集規律 - 公開コピー、チュートリアル、文書、マーケティングページを変更する前に、プロジェクトの編集方針を読みます。 - 使い古された表現、句読点、AIらしい文章パターンについて、文書化された拒否リストを適用します。 - 綴りを変える小細工で文章検証を回避してはいけません。禁止語に必要な技術的意味がある場合は、スタイルガイドの改定を提案します。 - 正規表現では判断できない、根拠のない断定、反復的なリズム、機械的な三項列挙、型どおりの対比転換などの構造問題を確認します。 - 各編集項目を、ビルドツールとレンダリングフレームワークの両方が使う一つのコンテンツツリーに置きます。 - コマンド解説には短いラベルを付け、用途、手順、具体例、実際の落とし穴の各節を用意します。 ## 自動で作られるファイルを、ふだんのデザイン変更に混ぜない 通常のデザイン作業がノイズの多い成果物や誤解を招く成果物を生まないように、執筆ソース、生成配布物、ローカル状態、リリース成果物を分離します。 ### ソース優先ビルド - 通常開発ではソース優先ビルドを使い、追跡対象のプロバイダー配布物を同期する時は別のリリースビルドを使います。 - 生成されたプロバイダーディレクトリは、インストール用に意図してコミットする場合でも、執筆面ではなく配布成果物として扱います。 - タスクがリリース、生成結果の同期、ビルドシステム変更のいずれかでない限り、生成された派生物を機能変更に含めません。 - ソース変更後は承認済みワークフローで追跡対象の成果物を再生成し、マニフェスト、メタデータ、生成フロントマターにずれがあれば検証を失敗させます。 - 追跡対象の配布ディレクトリ内にあっても、ローカル状態ファイルは無視します。 - コンテンツローダーやコマンドメタデータがホットリロードされない場合は開発サーバーを再起動します。ブラウザ更新を、ビルド時データの再読み込みと取り違えないでください。 ### 公開アセット - 表示件数とラベルがずれないように、ソーシャルカードなどのアセットを正本メタデータから生成します。 - 鮮明な文字が必要な場合は、高解像度でレンダリングしてから縮小します。 - 見た目が変わったアセットでキャッシュ無効化が必要な場合は、同じ変更内でファイル名とすべての参照を更新します。 - デプロイルート、リライト、静的アセット、サーバー関数を、プラットフォームが意図するビルドで検証します。 - 新しいデプロイが稼働した後にだけ、外部プレビューキャッシュを事前取得します。 ## 許可なしに外のプロジェクトへ投稿せず、お金のかかるテストは分ける デザインツールは実装を自動化できますが、明示的な権限なしに人間の貢献境界を越えてはいけません。 ### 貢献の許可 - リポジトリの、まず課題を作る方針または承認を先に得る貢献方針に従います。 - 権限を持つ保守担当者が要求するか明確に承認しない限り、外部の課題やプルリクエストを作成してはいけません。 - 方針で求められる場合は、コミット、変更説明、コメント、課題本文でAI支援を開示します。 - 権限のないAIエージェントがそれでも公開を求められた場合は、外部操作を停止し、代わりにローカルの引き渡し通知を用意します。 - 通常の貢献には、生成されたリリース成果物や無関係な同期変更を含めません。 ### テストの選択 - 高速で決定的な単体テストとフィクスチャテストを既定のテストスイートに含めます。 - ブラウザ駆動の全サイクルテスト、依存関係のインストール、稼働中の開発サーバー、有料モデル呼び出しは、明示的な任意参加コマンドの背後に置きます。 - 高コストなライブテストは、対象となる統合経路を変更した時に実行し、上限のない既定動作にはしません。 - テストエージェントを狭いインターフェースの背後で交換可能にし、広範なフィクスチャ範囲には決定的なフェイクを使用します。 - 動作評価では、磨かれた自由形式の回答ではなくツール呼び出しのトレースを検証します。 - プロバイダー間ルーティングがテスト対象の動作である場合は、複数のモデルファミリーを試し、認証情報がなければ問題なくスキップします。 - コストと変動性を意図して受け入れる場合を除き、有料評価スイートを継続的インテグレーションに含めません。 ## コマンドを足す時は一覧を全部直し、新しい版を出す作業は別にする コマンドと個別配布されるコンポーネントには同期されたメタデータが必要ですが、機能作業とリリース作業は分離したままにします。 ### コマンドの追加・変更 - コマンドの参照資料、ルーター項目、メニュー項目、有効コマンド一覧、メタデータ、カテゴリー、関係性、視覚化マッピングを同時に追加します。 - 人間に見えるすべてのコマンド数を更新し、機械可読な件数はビルドがルーターから導出して検証するようにします。 - 任意の編集コンテンツと自動発火用の説明を分離します。前者は読者向け、後者はコマンド照合向けです。 - プラットフォーム固有コマンドが大きく異なる場合は、ルーティングされた派生版を追加し、共有OS情報はプラットフォームの参照資料に保ちます。 ### バージョンとリリースの方針 - 通常の機能変更ではバージョンを上げたりリリースノートを追加したりしません。 - 個別配布されるコンポーネントは別々にバージョン管理し、変更したコンポーネントだけを更新します。 - リリースでは、正本マニフェストと同期ミラーを更新し、ユーザー向けノートを追加し、リリースビルドを実行してから、コンポーネント固有の接頭辞でタグを付けます。 - 公開前にリリース自動化をプレビューします。 - ワークツリーに未コミットの変更がある、ブランチが未同期、同じタグがすでに存在する、ノートが欠落、再生成で未コミットの差分が生じる場合は、リリースを拒否します。 - 変更履歴項目は簡潔かつユーザー向けにし、内部リファクタリング、ツールの詳細、生成結果の同期は省きます。 ## 新しいデザインチェックは、先に失敗するテストを書いてから作る 一つのデザイン検出ツールをCLI、ブラウザオーバーレイ、拡張機能、Webサイトで利用する場合、規則エンジンの正本を一つにし、派生するすべての利用側を再ビルドして検証しなければなりません。 ### 規則の開発順序 1. 一意に識別された例を含み、検出すべきケースを四つ以上、偽陽性の形を五つ以上持つフィクスチャを追加します。 2. テストDOMにレイアウトエンジンがない場合は、明示的な寸法を使用します。 3. 規則を実装する前に対象を絞ったテストを追加し、失敗することを確認します。 4. 規則メタデータと、DOMへアクセスせず安定した識別子とスニペットを返す純粋な検査関数を追加します。 5. ブラウザ用とテストDOM用のアダプターを別々に実装し、両方のアダプターを関連するすべての走査ループへ接続します。 6. 生成された検出ツールの各利用側を再ビルドし、完全なテストスイートを実行します。 7. アダプター間の不一致と偽陽性を見つけるため、フィクスチャと代表的な実ページをブラウザで検証します。 ### フィクスチャと評価の規律 - テストが該当ケースを抽出できるように、スニペットには安定した引用文または別の決定的な識別子を使います。 - DOMエミュレーターではレイアウト幾何情報に依存せず、明示的なスタイルを解析します。 - ブラウザとエミュレーターの動作が異なる背景、グラデーション、色の正規化には共有ヘルパーを使います。 - 効果を測る時は、同じ要件書からデザインシステムありとなしのデザイン結果を比較します。 - 評価基盤は、専用の操作指示を持つ独自の作業領域に置きます。 - 一括評価の前に最新のデザインソースをビルドし、最上位のガイダンス見出しが変わったらインラインスキルのセクションフィルターを更新します。