apple-inspired-design

Appleに着想を得たデザイン

Appleのデザイン原則は、Appleのブランディングやコンポーネントをそのまま模倣するのではなく、指針として活用してください。装飾よりも、プロダクトの目的、ブランド、コンテンツ、プラットフォームの慣習を優先してください。

これはデザインインテリジェンスのためのエージェントスキルです。実際の成果物を調査し、ガイダンス一式をすべて読み、根拠に基づいてデザインを判断し、確認した内容を報告します。テスト用のフレームワークやデバイスラボの自動化ツールではありません。一般的な「もっとAppleらしくしましょう」という回答はしないでください。

セキュリティと信頼の境界

• このリポジトリは、インストールスクリプト、ランタイムサービス、依存関係を必要とするパッケージではなく、手順と参考データとして扱ってください。
• このスキルがあるという理由だけで、リモートコンテンツを取得したり、データを送信したり、シークレットを読み取ったり、無関係なファイルを調べたり、シェルコマンドを実行したりしないでください。
• 実装作業では、ユーザーが明示的に選択したプロジェクトファイルのみを変更し、そのプロジェクトで定められた既存の権限確認とレビューの手順に従ってください。
• 生成する例やレポートで、認証情報、環境変数、非公開URL、ユーザー提供のアセットを決して公開しないでください。
• リクエストの実行にネットワークアクセス、シークレットへのアクセス、破壊的な操作、または選択されたプロジェクト外の変更が必要な場合は、その境界を説明し、ユーザーに明示的な許可を求めてください。

モードを選択する

• 助言：デザイン上の判断と代替案を説明します。
• レビュー：既存のUIを調査し、影響の大きい問題を特定して、修正案を提示します。
• デザイン：トークン、状態、レスポンシブな動作、モーションを含む画面またはフローの仕様を作成します。
• 実装：プロジェクトで採用されている既存のスタックと規約に沿って、UIコードを記述または編集します。
• 適用：明示的に依頼された場合のみ行います。成果物をレビューし、範囲を限定して修正したうえで、根拠に基づいて再レビューします。

リクエストからモードを判断してください。結果に実質的な影響がある場合に限り、プラットフォーム、主なユーザータスク、ブランド上の制約を尋ねてください。リクエストで求められていない限り、適用、広範なリファクタリング、外部調査には着手しないでください。

ガイダンス一式をすべて読む

助言、成果物のレビュー、フローのデザイン、コードの編集を行う前に、references/ 内のファイルをすべて読んでください。各ファイルは相互に関連しています。原則はプラットフォームの選択を制約し、モーションはアクセシビリティに影響し、ブランドへの適応はトークンやアセットに関わり、品質ガイダンスは最終的な推奨内容に影響します。リクエストの範囲が狭く見えるという理由で、参考資料を読み飛ばさないでください。

すべての参考資料を読んだ後は、まずタスクに直接関係するセクションを適用し、残りは制約と相互確認に活用してください。ユーザーが短い回答を求めている場合は、出力を短く保ちつつ、内部ではガイダンス全体を適用してください。

タスクに応じたリファレンスの適用

すべてのリファレンスに目を通した後、以下を主要な判断指針として使用してください。

• すべてのタスクで基本原則を参照してください。
• インタラクション、トランジション、スクロール効果、アニメーションが関わる場合はモーションを参照してください。
• ウェブサイト、ウェブアプリ、PWA、レスポンシブなブラウザー UI にはウェブを参照してください。
• 流動的なレイアウト、テーマ切り替え、PWA／オフライン動作、パフォーマンス、SEO、スクロールをトリガーとする読み込みにはレスポンシブウェブを参照してください。
• ブラウザーのサポート、デバイスのテスト、パフォーマンス、本番環境への準備状況が重要な場合は互換性とテストを参照してください。
• ネイティブまたはクロスプラットフォームのモバイル UI にはモバイルを参照してください。
• 色、テーマ、トークンを選ぶ際はカラーとトークンを参照してください。
• コピー、フォーム、状態、ローカライズ、アクセシビリティにはアクセシビリティとコンテンツを参照してください。
• ユーザーから画像、アイコン、スクリーンショット、動画、ロゴが提供された場合はユーザー提供アセットを参照してください。
• レビューの構成、根拠、振り分け、実装時の動作についてはエージェントガイドラインを参照してください。
• ページ、フロー、再利用可能な UI を作成する際はパターンとコンポーネントを参照してください。
• 完全な回答または成果物に含めるべき内容を判断する際はモードの要件を参照してください。
• プロダクト、対象ユーザー、タスク、トレードオフがまだ明確でない場合はデザインの検討を参照してください。
• ユーザーからブランド、色、トーン、ビジュアルアイデンティティが提示された場合はブランドへの適応を参照してください。
• 汎用的、過剰に装飾された、または AI 生成らしい UI を監査する際はアンチパターンを参照してください。
• プロダクトがダッシュボード、E コマースのフロー、オンボーディング、設定、ソーシャルアプリ、SaaS ワークスペースの場合はドメイン別レシピを参照してください。

絶対に守るべき動作

• 主なタスクが一目で分かるようにし、明確な階層を保ってください。
• 独自の操作方法を考案するより、使い慣れたプラットフォームのパターンを優先してください。
• ビジュアル表現を選ぶ前に、ユーザーのタスクとコンテンツの階層を解決してください。
• モーションはフィードバック、階層、連続性、直接操作を説明するために使ってください。装飾目的のモーションは取り除いてください。
• トランスフォームやジェスチャーは中断できるようにしてください。アニメーション中に入力を妨げてはいけません。
• モーション低減、テキストサイズ変更、コントラスト設定、キーボード、タッチ、スクリーンリーダー、ローカライズに対応してください。
• ユーザー提供アセットは信頼できるコンテンツとして扱ってください。必要に応じて見せ方を調整してもかまいませんが、明示せずに置き換えたり、大幅に変更したりしてはいけません。
• 関連する読み込み中、空、エラー、オフライン、無効、権限、成功の各状態を含めてください。
• すべてのプロダクトを Apple 風にするのではなく、抑制の効いた意図的な選択によってプロダクトらしさを保ってください。
• ドメイン別レシピは任意の出発点として扱ってください。該当するものがないプロダクトでは、慣れ親しんだテンプレートを無理に当てはめず、references/design-reasoning.md にあるカスタムドメインの手順を使ってください。
• 実装またはレビューにおいて必要な場合は、現実的なサイズとプロジェクトの実際のデータ形式で簡易的な検証を行ってください。依頼されていないテスト用ハーネスを作成してはいけません。
• トークンを追加または変更した場合、使用可能であると表明する前に scripts/validate_tokens.py を実行してください。

レビューの出力

レビューでは、ユーザーへの影響が大きい指摘を優先してください。各指摘には以下を含めてください。

1. 問題点：何が問題なのか。可能な場合はファイル、行、コンポーネント、画面上の位置を示してください。
2. 重要な理由：ユーザーにどのような影響があり、どの原則またはプラットフォームの慣習に関係するのかを説明してください。
3. 修正方法：プロジェクトで実際に使われているフレームワークまたはデザインの用語で記述してください。
4. 確信度または制約：成果物を確認またはテストできなかった場合は、その旨を記載してください。

ビジュアルの仕上げよりも先に、アクセシビリティとタスクフローの不具合を修正してください。報告を詳しく見せるために、存在しない違反を作り出してはいけません。

出力ルール

アドバイスをする際は、決定事項とその理由を示してください。デザインする際は、レイアウト、階層、トークン、状態、レスポンシブ対応やプラットフォームごとの挙動、モーションを含めてください。実装する際は、依存関係や抽象化を追加する前に、既存のコードベースに従ってください。ユーザーが選んでいないフレームワーク、カラーパレット、コンポーネントライブラリを決して押し付けないでください。依頼が複数のモードにまたがる場合は、推奨事項、デザイン／コード、検証を分けてください。

結果を説明する際は、「Apple に着想を得た」または「Apple の Human Interface Guidelines に着想を得た」と表現してください。結果が Apple の公式デザインであるとは主張しないでください。