agentic-design-system

エージェント型デザインシステム

ADS は、ビジュアルおよびフロントエンド作業の唯一のエントリーポイントです。次のループを使用します。

理解する → 選択する → 作業する → 検証する → 判断する

コピーのみ、または機械的な小規模編集は、小規模なままにします。選択した方向性を維持し、影響を受ける結果を確認します。新たなブリーフ、調査、バリエーション、評価レポート、完全なキャプチャーマトリクスは不要です。ビジュアル以外の作業では ADS を使用しないでください。ヘルパーはこのループに貢献しますが、別のプロセスや予算を作り出すものではありません。

パスはこのスキルディレクトリを基準に解決してください。<skills-root> はその親ディレクトリです。インストール済みリリースには create-design-workflow.md はありません。任意のソースメンテナンスワークフローには、ソースチェックアウトが必要です。

インストールのレビューやプロジェクトのデフォルト設定の変更については、信頼とカスタマイズを読んでください。実行時の影響、任意のテレメトリ、好みの上書き、来歴について説明しています。これはタスクごとに追加される段階ではありません。

理解する

大規模な作業では、依頼と現在のプロダクトソースから簡潔な内部ブリーフをまとめます。

• ユーザーの目的と成功条件： ユーザーが理解、判断、実行すべきことと、想定される閲覧・操作の順序。
• 正確な対象箇所と現状： 変更する既存のルート、コンポーネント、ドキュメント、成果物と、維持すべきもの。該当する場合は、現在のソースとレンダリングされたベースラインを確認します。バックエンドの拡張は、選定済みのフロントエンドを置き換える許可ではありません。
• 参考資料と方向性： 取り入れる特性、除外するもの、求める忠実度。不具合を示すスクリーンショットは根拠になりますが、新たなアートディレクションを自動的に意味するものではありません。
• 出力と対象範囲： 要求された形式、重要な状態、対象ブラウザーとブレークポイント、使いやすい形で結果をユーザーに届ける方法。

タスクに既存のブリーフやメモがあれば、それを使用します。より詳しい引き継ぎに役立つ場合は、成果テンプレートを任意で使用できます。以前の回答を再利用してください。結果を左右する重要な未解決の選択を既存の情報から判断できない場合に限り、質問します。許可された実装・修正の依頼では、範囲を限定した、元に戻せるローカル実装が認められています。同じ書き込み許可を再度求めないでください。外部への書き込み、デプロイ、インストール、支出、破壊的な操作には、それぞれ別途許可が必要です。

関連する DESIGN.md、ガイドライン、トークン、コンポーネント、承認済み・却下済みの判断を確認します。内容が不明な DESIGN.md のセクションは維持してください。フロントマターのトークンと説明文が矛盾する場合、現在のユーザーまたは主要なソースによる訂正がない限り、フロントマターのトークンを優先します。重要な矛盾を解決し、近似する代替案で済ませないでください。既存のプロダクト言語で要件に応えられない場合に限り、プリセットを使用します。

生成または大規模なレビューでは、Foundation v2を読んでください。プロダクトや運用の作業では、utility がデフォルトです。expressive は、マーケティング、エディトリアル、ローンチ、または明示的なブランド表現の対象範囲に限ります。シンプルなユーティリティ画面をクリエイティブな制作物に変えないでください。never 違反が確認された場合は、準備完了の判定を出せません。レポートのみを対象とする候補は、実際に確認された場合に限って報告します。契約に含まれる数値評価基準は、任意の診断情報であり、デザインの好みやリリースの認証ではありません。

選択

ユーザーの意図に応じて振り分けます。実際に未解決の方向性を探る場合はExplore、許可された変更を実施する場合はBuild、修正を前提とせずに確認する場合はReviewを選びます。タスクに必要な担当だけを使います。

• design-review は、プロダクトとタスクの適合性、情報アーキテクチャ、参照との忠実度、視覚的な判断を担当します。
• ux-baseline-check は、該当する状態と再利用可能なコンポーネントの契約を担当します。
• ui-polish-pass は、仕上がり、形状、テキスト／データ／フォームの動作、プリミティブを担当します。
• Ember は、重要なデザインの引き継ぎにあたり、原則としてエビデンスを読み取ります。実装担当でも、独立したレビュアーでも、審美的な判断者でもありません。

該当するニーズがある場合に限り、条件付きの専門担当を読み込みます。

• 目指すビジュアルの指定がある場合：../visual-reference-calibration/SKILL.md。借用するレイヤー、除外事項、忠実度を記録します。必要に応じて参照資料の受け入れを使います。
• 選択肢や未確定の方向性がある場合：../design-variations/SKILL.md。選択が必要な場合は、具体的な推奨案と、レビュー可能な代替案または目標を提示します。承認後に選択肢を新たに作り出してはいけません。
• 対象となるマーケティング／エディトリアル／ローンチの作業で、個性や楽しさを明示的に求められている場合：../whimsical-design/SKILL.md。
• 没入感や雰囲気が明示的に求められている場合：../world-build/SKILL.md。
• モーションやインタラクションの感触が求められている場合：../web-animation-design/SKILL.md と design-review のモーションリファレンス。
• エージェントが利用する公開インターフェースの場合：../agent-friendly-design/SKILL.md。必須のセマンティクスまたは機械可読な振る舞いに限り、クロール可能性の向上や API の拡張を自動的に行うものではありません。
• モバイルについて深い判断が必要な場合：モバイルレビュー。
• 許可された独立した批評家が有益な、高度な判断を要する作業の場合：敵対的レビュー。ランタイムが利用可能であることを確認します。同じエージェントによる読み直しは独立したレビューではありません。

ルーティングリファレンスには専門担当の詳細を記載しており、別のエントリーポイントではありません。ドキュメント、デッキ、画像には適切なネイティブ成果物スキルを使います。共有ブリーフによって、それらの成果物が Web 実装や Web の状態一覧を経由するよう強制されることはありません。

作業

意図されたプロダクトと出力形式で構築します。有用なコントロール、コンテンツ、トークン、インタラクションモデルを維持します。構造、状態の網羅性、仕上がりは、3 つの作業を順番に行うのではなく、一貫したひとつの工程として適用します。既存のプリミティブを再利用し、コンポーネントを増やす前にその契約を定義します。再利用が求められる成果の一部である場合は、実際の利用箇所を確認します。

レビューは次の順に進め、後の項目を磨く前に、先に見つかった問題を修正します。

1. 適切なプロダクト、サーフェス、ユーザータスクであること。
2. エビデンスの確認や戻り先のコンテキストも含め、情報やアクションの構造が理解しやすいこと。
3. ブリーフ／参照との忠実度と、意図の明確なビジュアルの方向性。
4. 仕上がりとコンポーネントの一貫性。
5. 振る舞い、該当する状態、対象サーフェス、実用可能な納品物。

すでに機能している部分は維持します。技術的な実装概要は、プロダクトがユーザーに提示する答えではありません。Review では、修正がすでに許可されている場合を除き、編集せずに指摘事項を報告します。

証明する

主張を裏付ける証拠を使います。ソースコードのチェックは参考情報です。実際のブラウザーで、条件をそろえたベースライン／参照キャプチャと比較し、意味のある視覚的な変更を確認します。該当する場合は、対象のデスクトップおよびモバイル／WebKit の画面でインタラクションを試します。スクリーンショットだけでは、動き、キーボード操作、以前のコンテキストへの復帰を証明できません。必要なアクセスが不足している場合は、未検証とします。

design-review が、キャプチャ手順と、確立済みのゲートとレポートのみの測定値の区別を定めます。普遍的なマトリックスではなく、タスクに関連するソースチェックと状態を選びます。必須のアクセシビリティ、状態、レイアウト、またはインタラクションの不具合は、ソーススキャナーを通過していても、準備完了の判定を妨げます。診断情報は、変更していない主要なキャプチャとは分けてください。

権限、読み取り専用、無効、オフライン、または破壊的な状態に変更がある場合は、近接するすべてのアクションについて、ラベル、強調度、ネイティブの有効／無効状態、セマンティクス、補足テキストが一致していることを確認します。影響を受けない状態では、有効なアクションを維持します。この隣接アクションの確認は UX baseline が担い、独立した実質的なレビューでも確認します。レビューで正確な場所、重要度、指摘事項から修正までの追跡可能性が必要な場合は、structured findings を使います。

任意の decision provenance では、実質的な作業について、ソースから判断に至る重要な関連を記録します。モデル呼び出しが追加されるわけではなく、小規模な編集が追跡対象の実行になるわけでもありません。

判断する

実質的なデザインの引き継ぎには、Ember を使って、このループですでに収集した証拠を読み取り、簡潔な Ember’s review を提示します。確認した内容、失敗した点または未検証の点、そしてユーザーの判断がまだ必要な点を示します。その short handoff に従ってください。これは結果に含まれるレビュー部分であり、二度目のレビューや実行ループではありません。実際に証拠をレビューした後に限り、この見出しを使います。レビューを行っていない場合は、Ember のラベルを使わず、その旨を明確に伝えます。ユーザーから明示的に求められない限り、小規模な文言や機械的な編集には、この形式を適用しません。

結果、証拠、実際に残っている判断事項を提示します。範囲を限定した判定を 1 つ使います：ready、needs repair、または blocked。成果物がローカル候補、インストール済み、納品済み、リリース済みのいずれかを明記します。ready が示すのは、証拠で確認されたタスク／バージョンに限られ、好みへの合意やリリースの許可を意味しません。使用可能な添付ファイル、またはすでにアクセスが許可されているレビュー画面を提供します。マシンローカルのパス、スクリーンショットフォルダー、localhost は内部証拠であり、リモートへの納品ではありません。

ADS、Ember、スペシャリストを通じて、1 つのタスク予算を適用します。ユーザーから別の予算が指定されない限り、実装／レビューは 1 回、修正は最大 1 回です。修正後は、影響を受けた証拠を再キャプチャします。スキル、レビュアー、美的基準、ランナーを切り替えても、予算はリセットされません。予算の上限に達したら、候補と未解決の指摘事項を維持し、誤っていた前提を診断して、具体的なブロッカーまたは判断事項を報告します。自動的に再構築したり、方針を転換したり、別のレビューを始めたりしてはいけません。

フィードバックを残す前に分類します。明示的な好みは既存の好みの管理先に、プロジェクトの判断事項はプロジェクトのコンテキストに、繰り返し発生する測定可能な不具合はプリミティブ／テストに、単発の修正事項はタスクに記録します。妥当であり、権限の範囲内にある場合に限り、管理先となる指示を更新します。受け入れ済みの例には、実際に人間が承認したことが必要です。スクリーンショットを改訂しただけでは、肯定的な例とはみなされません。ビルドのたびに普遍的な教訓を付け加えてはいけません。