gemini-designer

Grok Designer — UI、UX、ビジュアルデザインのアドバイザー

Grok 4.5 を外部アドバイザーとして使用し、ビジュアルデザイン、UI の仕上げ、UX のタスクフロー、操作時の摩擦、アートディレクション、軽量なデザイン成果物について相談できます。

API Key の設定方法

外部サービスの認証情報が必要な場合は、まずAPI Key の設定と業務からの読み取りを確認してください。既存の安全な設定方法を再利用します。ローカル環境に Key がない場合は、付属の固定ページを使用してください。保存後、業務用ラッパーのエントリーポイントから読み取ります。組み込み機能と完全なローカルワークフローでは、Key の設定は不要です。

重要なルール

• Grok とのやり取りには、grok-designer CLI（PATH にあるバージョン、またはこの Skill に付属するスクリプト）のみを使用してください。API やプロバイダー固有のスクリプトを直接呼び出さないでください。
• このスキルを使用する場合、UI に関する助言、UX に関する助言、デザイン画像、アートディレクション、批評、ビジュアルに関する助言、HTML、または SVG を提示する前に、grok-designer を呼び出してください。エージェント自身の判断でこれらの成果物を作成しないでください。
• 実行時の認証情報がすでにある場合は、そのまま呼び出してください。ローカルページに保存された認証情報を使用する場合は、設定手順に従い、run を介してこの Skill に付属するスクリプトを実行してください。コマンドが見つからない場合は、現在の Skill ディレクトリにある scripts/grok-designer の絶対パスを使用し、グローバルコマンドを自動でインストールしたり上書きしたりしないでください。
• 既存ファイルのビジュアル/UI レビューには、grok-designer ui を使用してください。
• UX、タスクモデル、コンポーネントの選択、インタラクションフロー、操作上の煩雑さ、または状態の振る舞いに関するレビューには、grok-designer ux を使用してください。
• UI と UX の両方のレビューが必要な依頼では、ui と ux を個別に実行してください。grok-designer ui,ux ... のように CLI のカンマ区切り形式を使用することも、別々のコマンドを並行して実行することもできます。
• 全般的なアートディレクションには、grok-designer direction を使用してください。背景情報としてファイルを含めることもできます。
• デザイン画像用の Markdown には、grok-designer direction を使用し、応答する前に生成された Markdown を読んでください。
• 新規の単独 HTML/SVG デザイン案には、grok-designer html または grok-designer svg を使用してください。
• 手書きの SVG ブランドワードマーク、レタリングマーク、サインマーク、またはロゴ風のテキストアセットを 1 つ作成する場合は、grok-designer svg を使用してください。
• 複数のワードマーク候補を並べた比較シートには、grok-designer html を使用してください。
• ユーザーがスクリーンショット、モックアップ、ムードボード、またはビジュアル参考資料を提供した場合、Grok がビジュアルスタイル、レイアウト、階層、雰囲気、忠実度、インタラクションの順序、または状態遷移を判断するうえで役立つ画像を、-i / --image を使って含めてください。
• Grok はステートレスです。現在のプロジェクト、これまでの会話、スクリーンショット、ローカルファイル、デザインルール、または過去の Grok の出力は、現在のコマンドに含めない限り把握していません。
• ユーザーから明示的に依頼されない限り、コード品質、技術的負債、CSS のリント、エンジニアリングの一貫性、パフォーマンス、またはアーキテクチャのレビューを Grok に依頼しないでください。Grok の対象は、ユーザーが知覚し操作できる内容に絞ってください。
• 既存ファイル向けのコードパッチや差分を Grok に出力させないでください。デザインに関する助言を受けた後、実際の編集は自分で行ってください。
• Grok から UI に関する助言、UX に関する助言、デザイン画像用の Markdown、ビジュアルの方向性、または HTML モックアップが返されたら、その出力または簡潔な要約をユーザーに提示し、プロジェクトコードへの実装について確認を待ってください。ただし、この会話ですでに実装の許可を得ている場合を除きます。
• UX の変更は状態ロジック、ルーティング、フォームの挙動、データ読み込み、またはバリデーションに影響することが多いため、コンポーネントロジックをリファクタリングする前に、構造やロジックの変更内容を要約して提示し、確認を待ってください。ただし、この会話ですでに実装の許可を得ている場合を除きます。
• HTML/SVG を生成した後は、ファイルの存在、構造の完全性、およびユーザーが明示した要件を満たしているか確認してください。構造の検証だけではビジュアルの確認にはなりません。許可があり、ビジュアルを確認できる場合は実際のレンダリングを確認してください。そうでない場合は、ビジュアル確認を行っていないことを正直に伝えてください。複数回にわたる有料レビューへ自動的に拡張しないでください。
• 通常の HTML、SVG、またはアイコンの依頼では、タスクごとにスクリプトを 1 回だけ実行してください。出力ファイルを読み、その後の作業を進めてください。
• ユーザーが示した要件と具体的なプロジェクトのコンテキストを渡してください。ユーザーが明示していない限り、エージェント独自のスタイルラベル、レイアウトの選択、色の選択、比喩の選択、インタラクションの概念、または評価基準を追加しないでください。
• Grok に渡す前にデザインを決めないでください。クリエイティブな生成では、ユーザーの目標、素材、出力形式、絶対条件のみを伝えてください。ユーザーが明示していない限り、ビジュアルの方向性、比喩、レイアウト、配色、タイポグラフィ、素材、アニメーション、またはインタラクションモデルを指定しないでください。
• 複数の案を求める場合は、それぞれ独立した、明確に異なる案を Grok に依頼してください。ユーザーが方向性を指定していない限り、「ダッシュボード案」「エディトリアル案」「レーダー案」などの名前を付けないでください。
• CLI は独自に設定と認証を管理します。事前に認証状態を確認しないでください。呼び出しが error=not_authorized で失敗した場合は、Grok Designer が認証されていないことを伝えてください。

Grok CLI

Grok のすべてのタスクで grok-designer を使用してください。 以下の例では業務パラメーターを示しています。ページの認証情報を使用する場合は、常に node "<Skill目录>/scripts/credential-ui/src/profile.ts" run default -- python3 "<Skill目录>/scripts/grok-designer" にこれらのパラメーターを追加して実行します。実行時の認証情報がすでにある場合は、そのまま呼び出せます。再インストールは不要です。

コマンドが見つからない場合は、python3 "<Skill绝对目录>/scripts/grok-designer" を直接使用します。Python 3.11 以降が必須の依存関係です。グローバルインストールは、ユーザーから要求された場合にのみ行います。

CLI が error=not_authorized を返した場合は、処理を中止し、Grok Designer が認証されていないことをユーザーに伝えます。API Key を読み取ったり、コピーしたり、表示したりしないでください。設定が不足している場合は、この Skill の設定手順に従って固定ページを表示し、ユーザー自身に保存してもらいます。

各コマンドには、組み込みのプロンプトがあります。適切なコマンドを選び、ユーザーのタスクをそのまま渡してください。ユーザーが明示的に指定しない限り、コマンドをまたぐプロンプトの枠組み、デザイン方針、UX の解決策、追加の出力ルールを加えないでください。

コマンド：

• grok-designer ui — レイアウト、階層、密度、タイポグラフィ、色、間隔、サーフェス、シャドウ、コンポーネントの外観、ビジュアルの一貫性、UI の仕上がりなど、ビジュアル／UI のレビューに使用します。参照コンテキストとして -f と -i を指定できます。-o で読みやすい Markdown ファイル名を指定する必要があります。
• grok-designer ux — タスクモデル、コンポーネントの選択、フロー、摩擦、コントロールの構造、アフォーダンス、復旧可能性、バリデーション、ナビゲーションの明確さ、使いやすさに影響する場合のアクセシビリティ、読み込み／エラー／空／成功／無効／ホバー／フォーカス／アクティブの各状態など、UX とインタラクションのレビューに使用します。参照コンテキストとして -f と -i を指定できます。-o で読みやすい Markdown ファイル名を指定する必要があります。
• grok-designer ui,ux — ビジュアル／UI と UX の両方のレビューをユーザーが求めている場合に使用します。CLI は独立した Markdown レビューコマンドを実行し、コマンドごとに 1 つの出力を書き込みます。
• grok-designer direction — 実装の前に、より強いアイデア、アートディレクション、ビジュアルメタファー、デザインイメージの Markdown、高レベルのデザイン方針が必要なタスクに使用します。ファイルは任意です。常に -o で読みやすい Markdown ファイル名を指定してください。
• grok-designer html — 新しい単独の HTML モックアップまたはコンセプトページに使用します。参照コンテキストとして -f と -i を指定できますが、既存のプロジェクトファイルを直接修正する用途には使用しないでください。
• grok-designer svg — 新しい SVG アイコン、シンプルなイラスト、または手描き風の単語ロゴ 1 点に使用します。参照コンテキストとして -f と -i を指定できます。

既存の UI を評価する必要がある ui または ux では、原則として関連するファイルをすべて渡します。ファイルが CLI の上限を超える場合や、ユーザーが範囲を限定したレビューを求めている場合を除き、ファイルを要約したり、一部を切り出したり、注釈を付けたりしないでください。一般的なデザインの質問であれば、プロンプトのみの ui または ux でもかまいません。

ui、ux、direction では、呼び出し時に必ず -o で Markdown ファイル名を指定してください。accounts-filter-ui.md、tag-editor-ux.md、museon-home-art-direction.md、pricing-page-design-imagery.md など、読みやすいファイル名のみを指定することを推奨します。CLI はファイル名のみの指定を .grok-designer/ 内に保存します。特定のディレクトリが必要な場合にのみ、明示的なパスを使用してください。

複数コマンドによる Markdown レビューでは、読みやすい -o 名を 1 つ指定します。CLI はコマンドごとにサフィックスを付けます：

grok-designer ui,ux "评审这个标签编辑组件" \
  -f ./TagEditor.tsx \
  -f ./tag-editor.css \
  -o tag-editor-review.md

これにより、tag-editor-review-ui.md や tag-editor-review-ux.md など、別々の出力が書き込まれます。

html と svg では、既存の内容、デザインルール、以前のモックアップ、テーマトークン、コンポーネント例、ブランド資料などを Grok が参照する必要がある場合に、-f でファイルを渡してください。これらのファイルは新しいデザイン案のコンテキストとして扱い、Grok がその場で修正するファイルとして扱わないでください。

html では、デザインの目標のみを説明してください。Grok にファイルの保存、file:// URL の返却、ダウンロードリンクの提示、ファイルの保存場所の説明を求めないでください。CLI が出力ファイルを書き込みます。Grok は完全な HTML ソースのみをそのまま返す必要があります。

html では、原則としてアセットや依存関係のポリシーに触れないでください。画像、フォント、スクリプト、スタイルシート、アイコンライブラリ、音声、動画がデザインに役立つかどうかは、Grok に判断させます。完全な自己完結型、オフラインでの安全性、外部リソースの禁止、現実的な公開画像の使用など、ユーザーが明示的に求めた場合にのみ、アセットの制約を追加してください。 手書き風のワードマークでは、ユーザーが1つの素材を求めている場合はsvgを、比較できる複数の候補を求めている場合はhtmlを使います。単語や語句、雰囲気、ユーザーが明示した素材の希望を説明します。ユーザーから求められていない限り、ネオン、金属、SF風など、効果を多用するスタイルを指定しないでください。デフォルトでは、読みやすい紙とインクを思わせるSVG文字に、控えめな筆記アニメーションと、効果的な場合は上品な仕上げの書き込みを加えます。

組み込みのdirection、html、svgプロンプトは、汎用的なAIテンプレートやカテゴリーごとの定型表現を避けること、具体的な感覚的手がかりを通じて題材をすぐに認識できるようにすること、デザインの選択を製品の題材や実際のコンテンツに即したものにすること、視覚的な伝達を改善できる場合は意図的にコントラストを付けること、重要な1か所に大胆さを集中させること、周囲のUIを控えめに保つことを、Grokにさりげなく促します。

コンテキストのルール

Grokが受け取るのは、コマンドのテキスト、-fで渡されたファイル、-iで渡された画像のみです。呼び出しをまたいだ記憶はありません。

CLIは、Grokが具体的なタスクを最後に見るよう、参照ファイルと画像マニフェストの後に最終的なユーザーの目的を配置します。エージェントは、制約を何度も繰り返すのではなく、タスクのテキストをユーザーの表現にできるだけ近づけてください。

既存のUIについて質問する場合、判断に必要な最小限のファイル一式を渡します。

• 判断対象となるファイルまたはコンポーネント
• ワークスペースに存在する場合は、プロジェクトのデザインガイドまたはスタイルリファレンス
• 視覚的な結果に実質的な影響を与える関連CSS／テーマ／トークンファイル
• 表示される構造、表示状態、または再利用されるUIパターンを定義している場合に限り、近接するコンポーネントファイル
• UXの動作に実質的な影響を与える場合は、状態、フック、フォーム、バリデーション、ルーティング、またはコンテキストのファイル
• ユーザーの質問がUIの見た目や変化に依存する場合は、スクリーンショット、モックアップ、ムードボード、参考画像、書き出したプレビュー、または状態を順に示すスクリーンショット

uiでは、表示されるコンテキストを優先します。

• 対象のコンポーネントまたはページのファイル
• CSS／テーマ／トークンファイル
• デザインシステムまたはスタイルリファレンスのファイル
• スクリーンショット、レンダリング済みのプレビュー、モックアップ、またはビジュアルリファレンス

uxでは、ビジュアルファイルだけでは不十分です。ユーザーのタスクや状態遷移を定義するコンテキストも含めてください。

• コントロール、状態、バリデーション、表示動作を定義するコンポーネントファイル
• 適切なコントロールパターンの選択が質問に関係する場合は、既存のコンポーネントライブラリのファイルまたは近接する使用例
• フローを制御するフック、コンテキスト、ルート、フォーム、スキーマ、またはデータ読み込みのファイル
• ラベル、エラー、確認、空の状態、成功状態に影響するコピー／設定ファイル
• 複数の状態にまたがる体験の場合は、-i step1.png -i step2.pngのような連続した画像
• ファイルから意図するユーザータスクが明らかでない場合は、そのタスク

抜粋よりも、ファイル全体を優先してください。-fフラグを複数使用します。

grok-designer ui "判断这个页面是否符合项目现有视觉风格，并给出具体优化建议" \
  -f ./design.html \
  -f ./src/styles/tokens.css \
  -f ./src/components/Button.tsx \
  -o design-page-ui.md

grok-designer ux "评审这个标签编辑组件的任务模型和交互状态" \
  -f ./src/components/TagEditor.tsx \
  -f ./src/hooks/useTags.ts \
  -i ./screenshots/tag-editor-open.png \
  -o tag-editor-ux.md

画像のコンテキストには-iを使用します。

grok-designer ui "结合截图给这个页面提视觉设计建议" \
  -f ./design.html \
  -i ./screenshots/current.png \
  -o current-page-ui.md

grok-designer direction "参考这张图，生成设计意象 markdown" \
  -i ./references/moodboard.png \
  -o product-design-imagery.md

-iで画像を渡すと、リクエストサイズを抑えつつ読みやすいUIの詳細を保つため、CLIが内部で最適化されたWebP版をGrokに送信する場合があります。エージェントは、元のスクリーンショットまたは参考画像のパスを渡してください。

視覚的な結果やユーザーに見える操作に影響しない、無関係なソースファイル、ビルド出力、依存関係フォルダー、ログ、実装の詳細は渡さないでください。必要なコンテキストが大きすぎる場合は、代表的なデザインシステムのファイルを選び、タスクのテキストで不足しているものを伝えてください。

Grokのuiまたはuxの出力で追加のコンテキストが必要だと示された場合、それを最終的な助言として扱わないでください。要求されたファイルまたは情報が入手可能なら集めて、追加の-fまたは-i入力とともに同じコマンドをもう一度実行してください。要求されたコンテキストが見つからない場合は、不足しているものを具体的にユーザーに伝え、提供を依頼してください。

組み込みのuiプロンプトは、Grokに次のことを求めます。

• 視覚効果、情報の階層、読み進めるリズム、タイポグラフィ、色、余白、サーフェス、コンポーネントの見た目、UI の仕上がり、感情的なトーンに重点を置く
• コードレビュー、CSS の整理に関する批評、技術的負債、アーキテクチャ、ビジネスロジック、新機能の提案は避ける
• どこを、どのように変更するのか、また、視覚的な結果がなぜ改善するのかを正確に説明する
• 変更内容の説明に役立つ場合は、十分な長さの擬似コード、CSS、または JSX スニペットを含める。ただし、ファイル全体は出力しない
• 実装エージェントには、既存のコンポーネント、セレクター、クラス、トークン、変数、レイアウトパターン、インタラクションパターンを優先するよう伝える
• 再利用可能なコンポーネントやトークンの名前は、提示されたファイル内で確認できる場合にのみ挙げる。確認できない場合は、プロジェクト固有の名前を作らない
• 保持すべき具体的な領域、トークン、コンポーネント、視覚的特徴、文言、状態がある場合は、短い「変更しないこと」セクションを含める
• 信頼できる UI 判断ができない場合は、推測せず、不足している情報を尋ねる

組み込みの ux プロンプトは、Grok に次のように求めます。

• 自然なタスクモデル、コンポーネントの選択、認知負荷、操作時の摩擦、コントロールの構造、アフォーダンス、復旧のしやすさ、検証、ナビゲーションの明確さ、ユーザビリティに影響する場合のアクセシビリティ、画面上の状態フィードバックに重点を置く
• タグを編集する場合は、追加用と削除用の入力を分けるのではなく、編集可能なタグ／チップエディターを使うなど、選択したコンポーネントやコントロールのパターンがタスクに合っているかを判断する
• 関連する場合は、読み込み、エラー、空、成功、無効、ホバー、フォーカス、アクティブの各状態を評価する
• ユーザビリティに直接悪影響を及ぼさない限り、純粋な視覚的な磨き込みは避ける
• プロダクト戦略、機能の肥大化、ゲーミフィケーション、広範な方向転換、コードレビュー、CSS の整理、技術アーキテクチャ、ファイル構成への批評は避ける
• 既存のプロダクト範囲とユーザーの目標に沿って作業する
• 構造、コンポーネントパターン、インタラクション、文言、状態、レイアウトについて、具体的な変更を提示する
• 信頼できる UX 判断ができない場合は、推測せず、不足している状態ロジック、ルーティング、コンポーネントコード、コンポーネントライブラリの例、フォーム検証、または連続したスクリーンショットを求める

並行レビュー

ユーザーが複数のレビュー観点を求めた場合は、該当する各コマンドを個別に実行します。UI、UX、アートディレクション、HTML、SVG の作業を、1 つの広範なプロンプトにまとめないでください。

UI と UX のレビューを行う場合：

1. grok-designer ui と grok-designer ux を個別に実行するか、grok-designer ui,ux を実行して、CLI が個別の出力を生成するようにします。
2. エージェントが独自のビジュアルスタイル、インタラクションのメタファー、カラーパレット、レイアウト、UX の解決策を追加せず、両方のコマンドに同じユーザーの目標を渡します。
3. ui には、スクリーンショット、レンダリング済みプレビュー、スタイルトークン、テーマファイル、表示されるコンポーネントファイルを渡します。
4. ux には、コンポーネントのロジック、状態ファイル、ルーティングファイル、コンポーネントライブラリの例、フォーム／バリデーションのロジック、利用可能な場合は順を追ったスクリーンショットを渡します。
5. 両方の出力が返されたら、ユーザー向けに内容をまとめます：
   • まず UX を示します：タスクモデル、コンポーネントの選択、フロー、状態のフィードバック、摩擦、復旧可能性。
   • 次に UI を示します：階層、タイポグラフィ、余白、仕上がり、ビジュアルの一貫性。
   • UX と UI のアドバイスが矛盾する場合は、まず UX の構造上の判断を優先し、影響を受ける要素が維持される場合にのみ適用される UI のアドバイスを明記します。

便利なコマンド：

grok-designer ui "给这个页面提视觉/UI设计建议" -f ./design.html -o design-page-ui.md
grok-designer ux "评审这个页面的任务流、交互摩擦和状态反馈" -f ./design.html -o design-page-ux.md
grok-designer ui,ux "同时从 UI 和 UX 角度评审这个标签编辑组件" -f ./TagEditor.tsx -o tag-editor-review.md
grok-designer ui "结合截图给这个页面提视觉/UI设计建议" -f ./design.html -i ./screenshots/current.png -o page-screenshot-ui.md
grok-designer direction "给这个产品生成设计意象 markdown" -o product-design-imagery.md
grok-designer direction "基于这个页面生成设计意象 markdown" -f ./design.html -o page-design-imagery.md
grok-designer html "基于这个页面生成一个完整、全新的落地页方案。保留产品信息，由你独立判断视觉方向，不要复刻原稿。" -f ./design.html -o ./designs/page.html
grok-designer html "基于这个页面生成第 1 个完整落地页方案。保留产品信息，由你独立判断视觉方向。后续方案需要彼此明显不同。" -f ./design.html -o ./designs/page-option-1.html
grok-designer svg "为 Museon 生成一个手写 SVG 字标，气质像策展笔记标题" -o museon-wordmark.svg
grok-designer html "展示 Museon、Mel、Signal 三个手写 SVG 字标候选，默认偏纸面墨迹和真实笔触" -o wordmark-candidates.html
grok-designer svg "生成一个设置图标" -f ./brand.md -o ./icons/settings.svg

実行する前に、すべての出力ファイルを読んでください。プロジェクトに合った提案のみを適用します。

ui、ux、direction の出力には、最後に 原始提示詞 セクションが含まれます。このセクションには、タスクのテキストと、参照されたファイルや画像の読み取り可能なパスが記録されます。付録にファイルの内容全体が複製されることはありません。

Grok のアドバイザリー出力（ui、ux、direction）と HTML モックアップについては、すぐにプロジェクトファイルを編集しないでください。Grok の出力または簡潔な要約を提示し、ユーザーに方向性を選択または確認してもらってから、確認された部分のみを実装します。ユーザーの依頼がアセットの作成のみである場合は、SVG アイコンの出力を直接保存できます。HTML ファイルや SVG ファイルを作成しただけの理由で、セルフレビューを実行しないでください。

成功時、スクリプトは次を出力します：

output_path=<path to output file>

複数コマンドのレビューでは、コマンドごとに 1 つのパスを出力します：

output_path[ui]=<path to UI output file>
output_path[ux]=<path to UX output file>

html と svg の場合、スクリプトは次も出力します：

integrity=passed

Grok の応答を取得するには、output_path にあるファイルを読み取ります。

失敗時、CLI は安定したフィールドを出力します：

error=<code>
message=<short explanation>
hint=<next step>

実行可能な場合は hint に従ってください。error=not_authorized の場合は処理を停止し、Grok Designer が認可されていないことをユーザーに伝えます。

生成された HTML／SVG では、output_path と integrity=passed の組み合わせを、通常の完全性確認のシグナルとして扱います。ユーザーから追加のブラウザー検証やビジュアル検証を求められない限り、エージェント側で CLI の確認を重複して実行しないでください。

出力タイプ

• grok-designer ui — Markdown 形式の UI レビュー出力。
• grok-designer ux — Markdown 形式の UX レビュー出力。
• grok-designer direction — Markdown 形式のデザイン方針出力。
• grok-designer html — インライン CSS を含む、自己完結した完全な HTML ソース。ブラウザーですぐに開けます。CLI は、不完全な HTML、head/body の欠落、ファイル URL、Markdown のフェンス、lorem ipsum、HTML 以外のラッパー出力を拒否します。
• grok-designer svg — アイコン、シンプルなイラスト、または手書き風の単語のみのロゴに使用できる、クリーンな SVG コード。CLI は、無効な XML、ラッパーテキスト、Markdown のフェンス、ローカルファイル URL を拒否します。そのまま保存するか、HTML／React に埋め込めます。

設定

• グローバル CLI は ~/.config/grok-designer/config.toml を読み取ります。
• 画像最適化では、ローカル CLI 環境が対応している場合、デフォルトで WebP が使用されます。
• エージェントは固定の設定ページへのリンクと秘匿化された状態のみを表示し、ユーザーの実際の Key の読み取りや操作は行いません。
• 通常の処理では認可を確認しないでください。認可を明示的にデバッグする場合に限り、grok-designer auth status を使用します。

ワークフロー

1. 適切な範囲で最小の Grok タスク（ui、ux、direction、html、svg）を選択します。
2. 読みやすい -o パスを指定して grok-designer を実行し、最終回答やファイルを作成する前に output_path を取得します。
3. 可能な限り、ユーザーの表現をタスクテキストとして使用します。ファイル、製品の対象範囲、またはユーザーが実際に提示した制約を特定するために必要な事実のみを追加します。
4. ビジュアル/UI のレビューでは、grok-designer ui を呼び出します。
5. UX、タスクモデル、コンポーネントの選択、インタラクションフロー、摩擦、状態フィードバックのレビューでは、grok-designer ux を呼び出します。
6. UI と UX を組み合わせてレビューする場合は、grok-designer ui,ux を実行するか、両方のコマンドを個別に実行して結果をまとめます。
7. デザインイメージの Markdown やビジュアルの方向性については、grok-designer direction を呼び出します。
8. 新しい HTML/SVG のデザイン案を作成する場合は、grok-designer html または grok-designer svg を呼び出します。参照情報が重要な場合は -f または -i を含めます。
9. 手描きの SVG ワードマークを 1 つ作成する場合は grok-designer svg を呼び出します。比較シートに複数のワードマーク案をまとめる場合は grok-designer html を呼び出します。
10. Grok の出力を読みます。
11. ui または ux が追加のコンテキストを必要としている場合は、求められたコンテキストを収集し、ユーザーに助言を提示する前に同じコマンドを 1 回再実行します。コンテキストを入手できない場合は、ユーザーに確認します。
12. ui または ux の出力を実装する場合は、編集前に、再利用できる既存のプロジェクトコンポーネント、セレクター、クラス、トークン、変数、レイアウトパターンを確認します。Grok が広範なシステムの置き換えや無関係な UI の新規作成を提案した場合は、編集前に既存のパターンに沿うよう範囲を絞ります。
13. デザインレビューがタスクなのに Grok がコードレビューに逸れた場合は、「UI/UX の観点だけで判断し、コード規約や技術的負債についてはコメントしないでください。」のように、対象を絞って再実行します。
14. ユーザーがこの会話ですでに実装を許可している場合を除き、編集前に、助言の内容や HTML モックアップをユーザーに提示して確認を求めます。
15. 最終回答は Grok の出力に基づいて作成します。役立つ部分を要約、選択、または実装してもかまいませんが、Grok のデザイン判断を、独自に生成したデザインの方向性に置き換えてはいけません。

ヒント

• タスクプロンプトは、ユーザーの依頼にできるだけ忠実なものにします。
• ユーザーがスタイル、色、フォント、レイアウト、メタファー、ビジュアルの方向性、インタラクションモデルを指定していない場合は、プロンプトに独自の要素を加えないでください。
• 複数の Grok 生成結果を、エージェントが考えたテーマごとに分けないでください。「独立した案 1／独立した案 2／独立した案 3」のような中立的な表現を使い、Grok 自身の判断で明確に異なる案にするよう依頼します。
• 参照デザインを渡す場合は、Grok がそれを踏襲してよいか、模倣を避けるべきかを伝えます。独自の代替案に置き換えないでください。
• HTML モックアップでは、ユーザーが求めていない限り、アセットや依存関係のルールに触れないでください。不要な制約は、Grok のデザイン判断を妨げるおそれがあります。
• 「ダークモード」や「青を使う」など、ユーザーが明示した好みだけを渡します。
• デザインの洞察、方向性、HTML モックアップを求められた場合、Grok に長い説明文を求めないでください。可能な限り、目に見える UI の構成、状態、例、階層、インタラクションを通じてアイデアを表現させます。
• 「よりデザインされたものにする」を、視覚的なノイズを増やすことと解釈しないでください。強いビジュアル表現は、主要なアクション、ブランドの記憶に残る要素、主要コンテンツへの導線を支えるものにします。補助的な領域は控えめで安定感があり、見やすい状態に保ちます。
• ありきたりな表現を避ける方法は Grok に判断させます。禁止スタイルのリストを独自に追加せず、「ありがちなテクノロジー感やサイバーパンク感を避ける」など、ユーザーが示した明確な制約だけを伝えます。
• 動き、インライン SVG、素材感、マイクロインタラクションの可能性は Grok に積極的に検討させます。ただし、ユーザーから求められていない限り、特定のアニメーションや素材のスタイルを指示しないでください。
• タスクプロンプトに、独自のアンチテンプレートチェックリストを加えないでください。CLI はすでに、ありがちな AI デザインの回避、印象に残るビジュアルアイデア、節度、実際のコンテンツ、UI の文言について、Grok に簡潔な指針を示しています。
• 中国語のプロンプトも効果的です。Grok は同じ言語で応答します。