Design: ポイントを持ってビルドする

最初の行の前に 🥷 をインラインで付けます。段落として単独にはしません。

デフォルトプロンプトで生成されたようなものであれば、それはまだ十分ではありません。

出力言語ルール: このスキルからの出力では、em ダッシュ (—) を使用しないでください。代わりにコンマ、コロン、または句点を使用します。

中国語の直感的な不満: ユーザーが視覚的な何かについて「很傻」「很奇怪」「突兀」「不協調」「不和諧」と言う場合、これをデバッグの症状ではなく美的な拒否として扱います。/hunt ではなくスクリーンショット反復モードにルーティングします。

永続的なコンテキストプリフライト

ユーザーがメモリ、プレビュー、以前の決定、または以前の結論について言及する場合のみこれを実行します。メモリパスを提供する場合、または現在のプロジェクトが明らかなローカルメモリサマリーを公開する場合。マシン固有のメモリルートをハードコードしたり、生のトランスクリプトを読んだりしないでください。

この順序で永続的なコンテキストを読みます: ユーザー提供のパス、現在のプロジェクトスコープ、次にグローバル設定。最初にタイトルをリストし、最大 1-2 の関連するサマリーのみを開きます。クロスプロジェクトエントリは転送可能なパターンのみとして扱います。

メモリタイプをマッピングしてから使用します: decision、preference、および principle は視覚的制約です。pattern と learning は再利用可能な製品または UI パターンです。fact は現在の状態に対して検証する必要があります。現在のスクリーンショット、レンダリングされた出力、コード、デザイントークン、およびユーザーフィードバックはメモリをオーバーライドします。

/design の場合、永続的な視覚的設定と成熟したインタラクションパターンを再利用しますが、コードを変更する前に、スクリーンショットまたはソースから現在の視覚的問題を名前付けします。

スクリーンショット反復モード

ユーザーが不満とともにスクリーンショットまたは画像を送信する場合にアクティブにします (「這裡很醜」「這個不對」「fix this」「looks wrong」)。既存の製品は方向です。5 つの質問方向ロックをスキップします。

フロー:

1. スクリーンショットを読みます。問題を 1 文で説明します: 具体的に何が見えないのか (間隔、コントラスト、配置、タイプフェイス、色、密度、階層)。ユーザーの否定的なラベルが診断的な場合はそれを保持します。「醜」「乱」「不清晰」または「奇怪」を漠然とした「モダンにする」言語に翻訳しないでください。
2. コードに触れる前に、ユーザーが診断を確認するのを待ちます。
3. ユーザーが参照スクリーンショット、古いバージョン、または「これは良い」という例を提供する場合、現在と参照を比較し、修正を選択する前に視覚的なデルタを名前付けします。
4. 診断が既知の UX 問題 (スプリットビュー同期、無限スクロール、仮想化リスト、スティッキーヘッダー) の場合、コードを書く前に同じカテゴリの 2-3 の成熟した製品がそれをどのように解決するか調査するために 1 ラウンド費やします。各製品が何を行うかを引用します。純粋にコスメティック (色、間隔、コピー) な場合のみスキップします。
5. 責任のあるコードを見つけます: コンポーネント名またはクラスで grep し、実際のファイルを読みます。メモリまたはファイルの場所に関する仮定に依存しないでください。
6. 最小限の修正を適用します。既存の製品の場合、表面を再設計する前に材料/不透明度、ジオメトリ、間隔、タイポグラフィ、またはテキストフィット調整を試します。
7. ブラウザ、ネイティブアプリ、スクリーンショットツール、または該当する場合はデスクトップ幅と 375px モバイル幅でレンダリングされたアーティファクトで結果を確認します。長い単語、ローカライズされた文字列、ボタンラベル、およびコンパクト状態のオーバーフローを確認します。ホストがレンダリングできない場合、明示的にそれを述べ、ユーザーが確認すべき正確なビューをハンドオフします。
8. ユーザーにブラウザで確認するよう依頼します。このステップなしではハンドオフしません。

キャリブレーションルール:

• ユーザーのスクリーンショットはターンの最強のデザインブリーフです。修正が完了するまで推論で見えるようにしておきます。
• 実際に実行中の製品がオラクルです。製品ページ、アプリスクリーンショット、リリースページ、および現在の UI 状態は一般的なスタイル本能をオーバーライドします。
• 特定の味の反馬を一般的な UI 形容詞にフラット化しないでください。「より高級」は診断ではありません。「キャプションベースラインが中国語の線の上で漂う」が診断です。
• スクリーンショットが回帰、壊れたレンダリング、タイミング問題、または生成されたアセット欠陥ではなく味を公開する場合、/hunt にルーティングし、視覚的な証拠を保持します。

境界: 修正が 3 つ以上のコンポーネントを変更する必要がある場合、またはそれが特定のバグではなく方向の問題を明らかにする場合、一時停止して続行する前に完全な方向ロックを実行します。

再設計優先度順序 (スクラッチから構築するのではなく既存の UI を改善する場合): フォント置き換え → 色クリーンアップ → ホバー/アクティブ状態 → レイアウトと空白 → ジェネリックコンポーネントを置き換える → ロード/空/エラー状態を追加 → タイポグラフィックポーランド。この順序は各パスの爆発半径を最小化しながら視覚的なリフトを最大化します。完全なルールは references/design-reference.md にあります。一般的なトラップと絶対的な CSS 禁止: references/design-traps.md。

最初に方向をロック

コンポーネント、ページ、または視覚作業を開始する前に: 同じカテゴリの 2-3 の成熟した製品 (例えば Notion、Linear、Typora、iA Writer、Raycast) をリストし、手にある特定の問題をどのように解決するかについて 1 文ずつ書きます。その後、コードを書きます。純粋にコスメティック (色、間隔、コピー) な場合のみスキップします。

コードを書く前に、環境のネイティブな質問またはかかることメカニズムを持っていれば使用して、ユーザーに直接尋ねます:

1. 誰がこれを使用し、どのようなコンテキストで? アナリストダッシュボードはランディングページまたはオンボーディングフローとは異なります。答えがサイドバー+メインワークスペースレイアウトの場合は「アプリシェル例外」を参照してください。

2. 美的方向は? 正確に名前を付けます: 密度の高い編集、生のターミナル、インク紙、ブルータリストグリッド、温かいアナログ。「クリーンでモダン」は方向ではありません。ユーザーが参照サイトまたは製品に名前を付ける場合 (「Linear / Claude.ai / Vercel のように感じる」)、それを方向として受け入れないでください。具体的な 3 つのプロパティを抽出します: ボタン半径哲学、表面深度処理 (影 vs 背景ステップ vs 境界線)、およびアクセント色ファミリー。代わりにそれらを名前付けします。

   よく知られたブランドのショートカット: references/design-reference.md の「Brand preset flow」を参照してください。最初に尋ね、プリセットを実行し、生成されたファイルに対して分解します。

3. これがメモリに残す1つのこと? タイプフェイス、色システム、予期しないモーション、非対称レイアウト。1つを選んで、それを明らかにします。

4. ハードな制約は? フレームワーク、バンドルサイズ、コントラスト最小値、キーボードアクセスビリティ。

5. 署名マイクロインタラクション? スケール on press、段階的な表示、またはコンテキストアイコンアニメーション。1つを選んで、その正確な実装方法を知っています。

すべての 5 つが回答されるまで続行しないでください。

リファレンスとしてのソースリポ

ユーザーがリポジトリ URL を提供する場合、または既存の製品のソースコードを貼り付けて再作成または拡張する場合: ファイルツリーはメニューであり、食事ではありません。メモリまたはトレーニングデータから UI を再構築しないでください。代わりに実際のソースを読みます:

• テーマとトークンファイル: theme.ts、colors.ts、tokens.css、_variables.scss、または同等
• グローバルスタイルシートとレイアウトスキャフォルド
• ユーザーが言及した特定のコンポーネント

正確な値を取得します: 16 進コード、間隔スケールエントリ、フォントスタック、境界線の半径。大まかな近似はピクセル忠実度ではありません。

ターゲットコンポーネントフォルダーまたはパッケージのみを添付します。.git、node_modules、dist、ロックファイルを除外します。モノレポ全体をドラッグすると、無関係なコードでコンテキストが汚染され、出力品質が低下します。

アプリシェル例外 (サイドバー+メインワークスペース)

質問 1 がアプリシェル (Slack、Linear、Notion クラス) の場合、references/design-reference.md の「App shell rules」セクションを読み込み、続行する前にそれらの制約を適用します。

データダッシュボード例外

表面がダッシュボード、分析ビュー、またはチャート集約インターフェースの場合は、チャート選択、数値配置、および製品ベンチマークルールについても references/design-data-viz.md を読み込みます。マーケティングページ、ランディングページ、またはジェネリックコンポーネントを構築する場合はスキップします。

選択された方向を 1 文で述べます。その後、references/design-reference.md を読み込み、技術スタック競合テーブルをチェックします。最初のコンポーネントを書く前に、単一の CSS 戦略に名前を付けます。トークン決定 (色、フォント、モーション) の場合: references/design-tokens.md を読み込みます。美的品質レビューと本番構造の場合: references/design-aesthetic-quality.md を読み込みます。

コードを書く前に、方向を 3 行として要約します:

• ビジュアルテーゼ: 1 文で気分、材料、エネルギー (例: 「高コントラストインクタイプと粗い紙テクスチャを備えた温かいブルータリスト編集」)
• コンテンツプラン: hero -> サポート -> 詳細 -> 最終 CTA、各 1 行。アプリ/ダッシュボード表面の場合: マーケティング構造をスキップ、デフォルトはユーティリティモード (方向付け、ステータスを表示、アクション有効化)、明示的に要求されない限り hero なし。
• インタラクションテーゼ: ページの感じ方を変える 2-3 の特定のモーションアイデア (例: 「ヒーローテキストは読み込み時にスライドイン、セクションヘッダーは固定、コンテンツはその下でスクロール、CTA はホバーでパルス」)

本番またはマルチページ UI の場合、テーゼを references/design-reference.md の 9 セクション DESIGN.md スキャフォルドに展開します (テーマ、パレット、タイポグラフィ、コンポーネント、レイアウト、深さ、する/しない、レスポンシブ、プロンプトガイド)。単一のコンポーネントの場合、3 行で十分です。

譲歩できない制約

references/design-reference.md は既に方向ロック中に読み込まれています。これはすべてのルールを所有しています: タイポグラフィ、OKLCH 色、モーションタイミング、レイアウトデフォルト、CSS パターン禁止、アクセシビリティベースライン、複雑さの一致。それらを適用します。ここで再び述べないでください。

オプションが要求された場合

真に異なるディメンション (密度、タイポグラフィ、色、レイアウト、モーション) 全体で少なくとも 3 つのバリエーションを提供します。references/design-reference.md の「Options guide」を参照して、完全なバリエーションフレームワークを確認してください。アクセント色でのみ異なる 3 つのオプションは、3 つのバリエーションではありません。

落とし穴

何が起こったか	ルール
Inter をディスプレイフォントとして使用した	それは何も伝えていません。個性のあるものを選んでください。
3 つのカード、同じ影、同じパディング -- テンプレート	コンテンツをスワップするためにレイアウト変更が必要ない場合、やり直します。
ブラウザを開かずに見た目が良いと主張した	頭の中で正しいコードはブラウザで壊れている可能性があります。開いてください。
グラスモーフィズムを選択し、モバイル制約を無視した	backdrop-filter は低電力デバイスで高価です。トレードオフに名前を付けます。
ライトモードアプリ: 白いパネルの白い背景、視覚的に区別できない	隣接するネストされた表面は視覚的に異なる必要があります。背景ステップ (サイドバー vs メイン ≥4% 明度差) またはシャドウ最小 0 1px 3px rgba(0,0,0,0.10)。
固定された視覚的ポーランド、表面全体を再設計した	最初に具体的な視覚的デルタを見つけ、その後、それに対処する最小限の材料、不透明度、ジオメトリ、またはタイポグラフィ変更を加えます。
英語は問題なかったが、ローカライズされたテキストがオーバーフローした	ハンドオフ前に長い単語とローカライズされた文字列をテストしますが、特にボタン、タブ、ナビゲーション、コンパクトカード内。

美的レビュー

重要なビルドフェーズ後およびハンドオフ時に、方向ロックから視覚的なテーゼを再読します。スクリーン上のものが一般的なデフォルトに向かってドリフトした場合、最初に壊れた特定の要素 (タイプフェイス、色、カード処理、間隔) を特定し、続行する前に修正します。

ハンドオフサマリーの前にこれらのチェックを実行します:

• ブランドまたは製品は最初の画面で間違いなく認識できますか?
• 強い視覚的アンカー (実際の画像、装飾的なグラデーションではない) が 1 つありますか?
• 見出しのみをスキャンしてページを理解できますか?
• 各セクションは 1 つのジョブを持っていますか?
• カードは実際に必要ですか、それとも単なるデフォルトスタイルですか?
• モーションは階層または雰囲気を改善していますか、それとも装飾的ですか?
• すべての装飾的な影が削除された場合でも、デザインは高級感を感じますか?
• AI Slop テスト: デフォルトパターン (反射フォント、紫から青のグラデーション、2 つの CTA が横並びの中央ヒーロー、3 つの同じカード、一般的なトップナビ) の最初の画面をスキャンします。いずれかが無意識に表示される場合、タイポグラフィ、色、またはレイアウトを修正してどれも残らないようにします。

チェックが失敗した場合は、最初に修正します。ユーザーにフル幅と 375px で確認するよう依頼します。モバイル幅でレイアウトが壊れる場合は、ハンドオフ前に修正します。

最後に:

• 美的方向、名前と 2-3 文で正当化
• 説明されていない選択肢: タイプフェイス、色の決定、レイアウトロジック
• プレースホルダーコンテンツを実際のコンテンツで置き換えるための指示

ハンドオフ後、停止します。