oma-design

oma-design

スケジューリング

目標

プロジェクトのデザインシステムを定義、作成、検証するデザイン専門スキルです。 DESIGN.md が中心となる成果物であり、すべてのデザイン作業はこれを軸に進めます。

意図のシグネチャ

• ユーザーがデザインシステム、DESIGN.md、ビジュアルの方向性、タイポグラフィ、色、モーション、アクセシビリティ、アンチパターンのレビュー、またはコンポーネントのガイダンスを求めている。
• ユーザーがフロントエンドの実装前にデザイン上の決定を必要としている、またはデザインの観点から UI の品質監査を求めている。

使用する場合

• プロジェクトのデザインシステムを定義または改訂する
• DESIGN.md を作成または監査する
• タイポグラフィ、色、レイアウト、モーション、コンポーネントの方向性を選定する
• レスポンシブ対応、アクセシビリティ、ビジュアルの品質について UI 作業をレビューする
• 既存のサイトやアプリを再設計する（維持モードと全面改訂モード）
• Stitch MCP または getdesign から任意のベンダーのインスピレーションを取り入れる

使用しない場合

• フロントエンドコンポーネントやアプリケーション UI を実装する場合 → oma-frontend を使用
• プロダクトのスコープやタスクの内訳を計画する場合 → oma-pm を使用
• バックエンド、データベース、インフラストラクチャ、モバイルの実装を行う場合 → 該当する専門スキルを使用
• ビジュアル、インタラクション、アクセシビリティ以外の一般的な品質／セキュリティレビューを行う場合 → oma-qa を使用

想定される入力

• プロダクト、ブランド、対象ユーザー、プラットフォーム、UI／デザイン上の課題
• 既存の .design-context.md、DESIGN.md、スクリーンショット、参考資料、コンポーネントの制約
• アクセシビリティ、レスポンシブ対応、言語、実装上の制約

想定される出力

• デザインの方向性、改訂した DESIGN.md、監査結果、コンポーネントのガイダンス、引き継ぎメモ
• レスポンシブファーストで WCAG を考慮したデザインの推奨事項
• getdesign を使用した場合の任意のベンダーシードの出典表記

outputs:
  - name: design-doc
    description: Updated DESIGN.md when the run materially advances the design system
    artifact: "DESIGN.md"
    required: false
  - name: design-context
    description: Refreshed .design-context.md snapshot when a discovery pass runs
    artifact: ".design-context.md"
    required: false

依存関係

• .design-context.md と DESIGN.md
• デザインリソース、参考資料、アンチパターンカタログ、任意の Stitch／getdesign 連携
• コンポーネントを推奨する際の shadcn／コンポーネントライブラリのコンテキスト

制御フローの特徴

• コンテキストの不足、CJK 言語のサポート、ベンダーシードの有無、アンチパターンの監査結果に応じて分岐します
• デザインドキュメントの読み取り／書き込みや、任意のデザイン／ベンダーツールの呼び出しを行う場合があります
• 重要な選択が未解決の場合にのみ方向性を確認し、それ以外は提示されたブリーフに従います

構造的なフロー

開始

1. 関連する既存のデザインコンテキストを読み取り、依頼された判断に必要な場合にのみ不足している情報を収集します。
2. 対象ユーザー、プラットフォーム、コンテンツの言語、デザイン成果物を特定します。
3. ベンダーのインスピレーションや Stitch 連携が適切かどうかを判断します。

遷移

• 調査パスによってデザインシステムの判断に重要な情報が得られる場合は、.design-context.md を作成します。
• 対象が既存のサイト／アプリの場合は、提案の前に resources/redesign-protocol.md を読み込み、維持と全面改訂のどちらかに分類します。
• CJK のサポートが必要な場合は、CJK 対応フォントを優先します。
• ベンダーシードの取得に失敗した場合は、再試行、シードなしで続行、または中止を選択します。
• アンチパターンが見つかった場合は、最終決定の前に代替案を提示します。

失敗と復旧

• デザインコンテキストが不十分な場合は、焦点を絞った確認を 1 つ行うか、前提を提示します。
• ベンダーのインスピレーションを利用できない場合は、ローカルでのデザイン統合を続行します。
• アクセシビリティチェックに失敗した場合は、引き継ぎの前に修正します。

終了

• 成功：デザイン成果物がプロジェクトに固有で、レスポンシブファーストかつアクセシブルであり、監査可能です。
• 部分的な成功：コンテキストの不足、ベンダーの失敗、または未解決のデザイン上の判断が明示されています。

論理操作

ツールと手段

• デザイン参考資料、アンチパターンカタログ、チェックリスト、Stitch 連携、getdesign フェッチャー
• コンポーネントのガイダンスが必要な場合の shadcn CLI の推奨

標準的なワークフローパス

1. Inspect relevant existing context; create `.design-context.md` only when substantive discovery is needed.
2. Use the chosen direction. Offer alternatives only for requested exploration or a material unresolved design decision.
3. Generate or revise `DESIGN.md`, then run the design checklist.

任意のベンダーシードの検出：

bunx getdesign@latest list

リソースのスコープ

スコープ	リソースの対象
LOCAL_FS	.design-context.md、DESIGN.md、デザインリソース
CODEBASE	既存の UI とコンポーネントのパターン
NETWORK	任意の getdesign／ベンダー参考資料
PROCESS	任意の CLI／ツール呼び出し

前提条件

• 対象となるデザインの課題と成果物を特定できます。
• デザインコンテキストが存在するか、セットアップで作成できます。

影響と副作用

• DESIGN.md とデザインコンテキストの成果物を作成または変更する場合があります。
• ベンダー提供のシード素材を取得し、MIT ライセンスの帰属表示を追記する場合があります。
• フロントエンドのコードを直接実装することはありません。

ガードレール

1. 関連する既存のコンテキストとトークンを確認します。.design-context.md は、本格的な調査を行う場合に作成し、個々の見た目の編集ごとには作成しません。
2. デフォルトではシステムフォントスタック（system-ui, -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif）を使用します。カスタムフォントは、プロジェクト上の理由がある場合にのみ追加します。
3. サービスが CJK 言語（ko/ja/zh）に対応している場合は、CJK 対応フォントを優先します（Pretendard Variable > Noto Sans CJK > system-ui フォールバック）。ラテン文字のみの場合は、対象ユーザーに適したフォントを選びます。
4. アンチパターンを厳格に適用し、AI 生成らしい粗雑なデザインは却下します。resources/anti-patterns.md を参照してください。
5. 色には 16 進値を含む意味的な名前を付けます。「濃い青」ではなく「ディープオーシャンネイビー（#1a2332）」のようにします。
6. インストールコマンド（shadcn CLI）とともにコンポーネントを提案します。
7. すべての出力は、モバイルレイアウトをデフォルトとして、画面幅の拡大に応じて拡張するレスポンシブファースト設計にします。
8. すべてのデザインで WCAG AA を最低基準とします。
9. Stitch MCP の使用は任意です。すべてのフェーズは Stitch MCP なしでも実施できます。
10. デザインの方向性の検討が依頼されている場合、または重要な方向性が未確定の場合は、複数の方向性を提示します。すでに選択済みの方向性がある場合は、それを再利用します。
11. 重要なデザイン上の前提が結果に影響する場合は、その前提を明示します。確認するのは未決定の選択事項のみです。冒頭の定型句は必要ありません。
12. リデザインでは resources/redesign-protocol.md に従います。「維持」か「刷新」かを判断し、変更に着手する前に監査を行います。URL、ナビゲーションのラベル、フォームフィールド名、ブランドマークを、明示せずに変更してはいけません。
13. ビジュアルアセットは resources/asset-strategy.md に従います。画像生成（oma-image）を最初に試し、次に picsum のシードを使い、最後にラベル付きのプレースホルダーを使います。div で作った偽のスクリーンショットは禁止です。
14. 一貫性を保つための固定ルール：アクセントカラーは 1 色、角丸システムは 1 種類、ページごとのテーマは 1 つにします。早い段階で固定し、フェーズ 6 で監査します（チェックリストのセクション 6「機械的チェック」）。

参考資料

• resources/execution-protocol.md：選択したデザイン操作とそのフェーズ
• resources/redesign-protocol.md：既存サイトのリデザイン
• resources/design-md-spec.md：DESIGN.md の作成または変更
• resources/checklist.md：該当するビジュアル検証項目
• resources/anti-patterns.md：該当するビジュアルまたはコピーのカテゴリー
• resources/getdesign-fetcher.md：明示的に関連するベンダーのインスピレーション
• resources/stitch-integration.md：依頼された Stitch 操作
• resources/asset-strategy.md：ビジュアルアセットの選定
• resources/design-tokens.md：トークンのエクスポート
• resources/prompt-enhancement.md：不完全なデザインブリーフ
• resources/error-playbook.md：確認されたデザインツールのエラー
• reference/visual-hierarchy.md：7 つの階層原則（配置、色、コントラスト、近接、サイズ、質感、時間）
• reference/typography.md：フォント選定、文字サイズの段階、CJK
• reference/color-and-contrast.md：色彩心理、WCAG コントラスト
• reference/spatial-design.md：8px グリッド、ブレークポイント、間隔
• reference/motion-design.md：motion/react、GSAP、Three.js、ogl、Temporal UX
• reference/responsive-design.md：モバイルファースト、テーマシステム
• reference/component-patterns.md：shadcn/Aceternity/React Bits カタログ
• reference/accessibility.md：WCAG 2.2、ARIA、フォーカス
• reference/shader-and-3d.md：WebGL、R3F、ogl、パフォーマンス