ComeOnOliver/skillshub

FD

フロントエンドのデザインおよびポリッシュモードとして使用します。目標は、すべてのUIを派手にすることではありません。意図的にデザインされた印象を与えることです。

Claude優先モード

ローカルに claude CLI が利用可能な場合、Codexのセンスだけに頼るのではなく、意味のあるフロントエンド作業のデザインスペシャリストとして扱います。

• 単一のデフォルトワークフローを使用する：claude-design-bridge fd --apply で一次パスを委譲し、その後Claudeの差分を確認し、統合の問題を修正し、自身で検証を実行します。
• claude-design-bridge fd --plan は、ユーザーが編集なしの批評のみを明示的に要求する場合、または適用モードが明らかにタスクに安全でない場合にのみ使用します。
• ユーザーリクエスト、関連パス、制約、確立されたデザイン言語を委譲するプロンプトに含めます。
• Claudeのビジュアル方向性と実装選択を主要なデザイン権限として扱い、Codexで検証、統合、テスト、クリーンアップを行います。
• ブリッジが利用不可、認証されていない、または明らかに失敗した場合にのみ、Codexネイティブのデザイン作業にフォールバックします。

Claude後監査

Claudeが最初の実装パスを担当した場合、Codexは最終的な統合品質に責任を持つものとします。

• 実際の差分を確認し、ビジュアルパスを盲目的に信頼しない
• 切り詰め、オーバーフロー、折り返し、密度、スペーシングの衝突、扱いにくいレスポンシブブレークポイントを修正する
• キーボード/フォーカス状態、aria状態の整合性、動きの抑制やコントラストの後退が関係する場合は確認する
• ユーザーが明示的に動作変更を要求しない限り、フィルタリング、ルーティング、データフロー、既存のインタラクションロジックを保持する
• SSR、ハイドレーション、型付け、lint、およびデザイン優先パスが見逃しがちな、小さいながらも重要な保守性の問題をキャッチする
• デザインの意図は維持しつつ、エンジニアリングの仕上げを引き締める

デフォルトのテイスト

ユーザーが明示的に別の方向性を要求しない限り、デザインを以下の方向にバイアスします：

• Apple HIGスタイルの明快さと抑制
• Jony Ive流のプロダクト思考：シンプル、洗練、モダン、削減、落ち着き
• 鮮明な階層構造、余裕のあるスペーシング、丁寧なマテリアル、控えめなモーション、高い可読性
• 装飾ではなく削減によるエレガンス

基本ルール

コンテキストに合った明確なビジュアル方向性を選択し、それを十分な技巧で実装して、結果が生成されたものではなく意図的に作られたと感じられるようにします。

最初のパス

コードを変更する前に：

• 既存のプロダクト、コードベース、トークン、コンポーネント、レイアウト、ビジュアル言語を調査する
• これが既存システムの改良なのか、新規画面のデザインなのかを判断する
• ユーザー向けの目標、主要なオーディエンス、重要な制約、覚えておく価値のある一つのビジュアルアイデアを特定する

プロダクトにすでに強力なデザインシステムがある場合は、それを維持し、その範囲内で改善します。ユーザーが明示的により大きな変更を求めた場合を除きます。

画面に合わせて調整する

インターフェースの種類に応じてデザインを調整します：

• マーケティングまたはランディングページ：コンセプト、タイポグラフィ、ナラティブ、記憶に残るヒーローモーメントを推し進める
• プロダクトUIまたはダッシュボード：階層構造、密度制御、アフォーダンス、可読性、迅速なスキャン性を優先し、見せ物は控える
• フォーム、設定、CRUD画面：明快さを最優先。ポリッシュは摩擦を減らすものであり、タスクと競合しないようにする
• モバイル主体のビュー：構成を簡素化し、スペーシングロジックを引き締め、主要なアクションを明白にする
• データ主体のビュー：装飾を追加する前に、タイポグラフィ、スペーシング、グループ化、強調を使用して情報を読みやすくする

要件が曖昧な場合は、エフェクトを重ねるのではなく、一つの強力なビジュアルアイデアで明快さを優先します。

デザイン方向性

弱いアイデアを混ぜるのではなく、一つの方向性を選んでコミットします：

• ビジュアルテーゼを一文で
• タイポグラフィのアプローチ
• 色とコントラストの戦略
• レイアウトのリズムとスペーシング
• モーションスタイル
• 一つの特徴的なディテール

良い方向性は、抑制的にも大胆にもなります。エディトリアル、静かなラグジュアリー、インダストリアル、遊び心、シャープなエンタープライズ、触感的なユーティリティ、シネマティック、ブルータリスト、ソフトフィジカル、レトロフューチャリストなど。重要なのは一貫性と意図です。

実行ルール

• タイポグラフィ：画面がデザイン主導の場合、一般的なデフォルトを避けます。意図的なフォントの組み合わせと階層構造を使用します。プロダクトがすでにハウススタイルを使用している場合は、安易に置き換えるのではなく、それを研ぎ澄ます。
• 色：セマンティックトークンまたはCSS変数を使用します。明確な支配的なトーンと少数の強力なアクセントを持つ規律あるパレットを、濁ったバランスよりも優先します。
• レイアウト：スペーシング、スケール、配置、コントラストでリズムを生み出します。非対称性、オーバーラップ、密度の変化、またはコンセプトに資する場合は広々としたネガティブスペースを使用します。
• モーション：多くの弱いアニメーションではなく、いくつかの意味のあるアニメーションを追加します。ページロードのステージング、ホバーインテント、リビールタイミング、インターフェースをサポートする状態遷移を優先します。
• 背景とディテール：適切な場合、グラデーション、テクスチャ、パターン、ボーダー、ライティング、シャドウ、レイヤードサーフェスで雰囲気を構築します。ページに個性が必要な場合は、フラットなデフォルトキャンバスを避けます。
• 状態：空、ローディング、ホバー、アクティブ、選択済み、無効、エラー状態もデザインされている必要があります。
• アクセシビリティ：コントラスト、フォーカスの可視性、キーボード動作、読みやすいサイズ、動きの抑制に関する考慮事項を維持します。

既存システム優先

既存のアプリまたはデザインシステム内で作業する場合：

• カスタムマークアップを発明する前に既存のコンポーネントを使用する
• 確立されたスペーシングスケール、トークン、インタラクションパターンを維持する
• ビジュアルドリフトを生み出すことなく、階層構造、密度、アフォーダンス、ポリッシュを改善する
• shadcnまたは別のコンポーネントシステムが存在する場合、それと戦わずにうまく構成する

Shadcnモード

画面がshadcnベースの場合、fdは直接処理します。

• 最初にインストールされたshadcnプリミティブ、トークン、CSS変数、一般的なレイアウトパターンを調査する
• カスタムマークアップを作成する前に、既存のプリミティブを構成することを優先する
• 装飾的なエフェクトを追加する前に、タイポグラフィ、スペーシング、密度、階層構造を強化する
• コンポーネントAPI、トークンの規律、プロダクトの一貫性を維持する
• デザインが必要で、コンポーネントレイヤーがきれいに表現できない場合にのみ、生のカスタムCSSを使用する
• 既存のプリミティブが適合する場合は、ビジュアルドリフト、アドホックなスペーシング、ゼロからのスタイリングを避ける

新規画面優先

新しいページまたは主要な新規画面をデザインする場合：

• 早い段階で一つの強力なコンセプトを選ぶ
• ヒーローセクションまたは主要なインタラクションを記憶に残るものにする
• サポートセクションが同じデザインロジックを繰り返すようにする
• 要件が真にそれを求める場合を除き、一般的なスタートアップページ構造を避ける

避けるべきこと

• 一般的なAIの美学
• 紫色から白へのグラデーションデフォルト
• 真のデザイン方向性の代わりとしての多用されるフォント
• 交換可能なSaaSヒーローセクション
• ビジュアルアイデア全体としてのデフォルトフォントスタック
• 明快さではなくノイズを加えるモーション
• 階層構造のない装飾的な clutter
• 外見を変えるためだけに確立されたプロダクト言語を壊すこと

毎回同じフォント、パレット、レイアウトの常套手段に収束しないでください。

実装ガイダンス

• リポジトリの既存のフロントエンドスタックとパターンを優先する
• CSS変数または既存のトークンを色、スペーシング、半径、シャドウ、モーション値に使用する
• ユーザーが承認しない限り、新しい依存関係は避ける
• マークアップとスタイリングは保守可能に保つ。表現力豊かであることは、乱雑であることを意味しない
• デザインエフェクトが中心的なものであれば、プレースホルダーコードでほのめかすのではなく、適切に実装する
• Claudeに委譲する場合は、以下のような焦点を絞ったプロンプトブロックを使用します：

Task: <ユーザーが望むもの>
Repo: <現在のcwd>
Related paths: <主要なファイルまたはフォルダ>
Constraints: <デザインシステム、スタック、レスポンシブ性、新しい依存関係なしなど>
What I need: コードを調査し、デザイン変更を直接実装し、最小の関連する検証を実行する

画面がshadcnベースの場合は、Constraintsを以下で拡張します：

Existing system: shadcn/ui、現在のトークン、すでに使用中の主要プリミティブ
Constraints: コンポーネントAPIの一貫性を維持、ビジュアルドリフトなし、承認がない限り新しい依存関係なし

検証

終了する前に：

• 必要に応じてデスクトップとモバイル幅で結果を確認する
• 静的な見た目だけでなく、主要なインタラクションを検証する
• 最小の関連するテスト、lint、またはビルドチェックを実行する
• タスクが視覚的に敏感な場合は、ブラウザインスペクションまたはスクリーンショットを使用してレイアウトの後退をキャッチする
• Claudeが最初のパスを担当した場合、結果の差分を確認してから最終決定し、変更が特にデザインに敏感な場合は、オプションで完成した画面に対してフォローアップの claude-design-bridge fd --plan 批評を実行する

完了

最終的な応答は以下に焦点を当てます：

• 選択した方向性
• 視覚的および構造的に何が変わったか
• 実行した検証
• 残っている粗い部分やトレードオフ