refero-design

Refero Design

Refero は、エージェントに審美眼とプロダクトの根拠を提供します。デザイン作業の前に活用し、モデルの一般的な知識だけに頼らないようにしてください。

Refero には、次の 3 つのリサーチレイヤーがあります。

1. Styles - ビジュアルの方向性と審美眼。
2. Screens - 具体的な UI パターンとプロダクト画面の判断。
3. Flows - 複数ステップにわたるユーザージャーニーのロジック。

最良の結果を得るには、各レイヤーを組み合わせてください。Styles でビジュアルの方向性を、Screens で具体的な UI パターンを、複数のステップがあるタスクでは Flows で順序を定めます。

譲れない原則

• デザイン作業の前にリサーチを行います。 すべてのデザインは、実装前にリファレンスに基づいている必要があります。モデルの一般的なデザインの審美眼に頼らないでください。
• Refero MCP ツールを利用できる場合、ビジュアル作業ではまず Styles を使います。 ツールを利用できない場合は、同梱のクラフトリファレンスを使い、同じリファレンス固定のワークフローを維持してください。
• リファレンスを 1 つだけコピーしないでください。 複数の優れたリファレンスを調べ、ユーザーのプロダクトに合わせて新たな方向性を統合してください。
• リファレンスを平均化して無難な中間案にしないでください。 リファレンス同士が相反する場合は、主となる方向性を 1 つ選び、その際立った特徴を保ってください。副次的なリファレンスは、限定的な細部の追加にのみ使用できます。
• トークンの意味を変えないでください。 リファレンスで色、フォント、角丸、影、グラデーション、コンポーネントに特定の役割が割り当てられている場合は、その役割にのみ使用するか、使用を見送ってください。
• 画像に関する指針を尊重してください。 スタイルが写真、イラスト、プロダクトショット、グラフィックに依存している場合は、そのメディアの役割を保ってください。利用できる場合は実際のアセット、生成アセット、ストックアセットを使用してください。利用できない場合は、アートディレクションを意識したプレースホルダーを作成してください。質の低い CSS、テキスト、装飾的なボックスで複雑な画像を偽装しないでください。
• このスキルが利用できる場合、一般的なフロントエンド／プロダクトデザインスキルを並行するデザイン上の判断基準として使用しないでください。 Refero がデザイン手法です。一般的なデザインスキルは、作業を一般的な AI デザインへ引き戻しがちです。
• リサーチ結果は具体的でなければなりません。 リファレンスを挙げ、具体的な選択内容を説明し、何をどのように応用するかを示してください。
• 雰囲気の記憶だけでデザインしないでください。 主要なビジュアル、レイアウト、コンテンツ、インタラクションに関する判断はすべて、Refero のリサーチ、ユーザーの要件、またはクラフトリファレンスにたどれる必要があります。
• 実装前に統合してください。 リサーチをコンセプト、トークンの方向性、具体的な判断をまとめた台帳に落とし込んでから、描画やコーディングに進んでください。
• 要件は、そのまま実装の目標になるわけではありません。 実装前に、ユーザー提供のビジュアルソース、既存のプロダクト／デザインシステムの目標、選択した生成モックアップ、または直接実装が承認された明示的なリファレンス固定の方向性のいずれかを確定してください。
• 成果を変える場合にのみ画像生成を使ってください。 画像生成には時間がかかる場合があり、すべてのコーディング環境で利用できるとは限りません。ビジュアルの検討、モックアップ、画像、イラスト、テクスチャ、作成が難しいアセットには使い、小さな修正、明白な本番環境向けの編集、コード主体の UI 作業では省略してください。
• ビジュアル作業の構築後に検証してください。 引き渡し前に、レンダリングされた実装を固定した目標／リファレンスと比較してください。リサーチだけで十分とせず、修正可能なデザインのずれを直してください。

MCP のセットアップ

このスキルは、リサーチを優先するデザイン手法およびクラフトリファレンスとして単独でも役立ちます。 リサーチは必須です。利用できる場合は、ライブのスタイル、画面、フローをリサーチするために Refero MCP を使ってください。そうでない場合は、同梱のクラフトリファレンスとユーザー提供のリファレンスを使ってリサーチしてください。

一般的な MCP のセットアップ：

claude mcp add --transport http refero https://api.refero.design/mcp

次に、Claude Code で /mcp を実行し、プロンプトが表示されたら Refero にサインインしてください。

ツールの詳細については、references/mcp-tools.md をお読みください。

調査

調査を始める前に、簡潔な設計ブリーフを作成します。結果を大きく左右する情報が不足している場合にのみ質問し、それ以外は妥当な前提を置いて進めます。

次の点を確認します。

• 何を設計するのか
• プラットフォーム：Web、iOS、または両方
• 対象ユーザーと技術レベル
• ユーザーの主な目的
• 望ましい印象やブランドの方向性
• 解消すべきビジネス上・ユーザー上の懸念
• 制約：既存ブランド、フレームワーク、期限、アクセシビリティ、コンテンツ
• 必要なのはビジュアルの方向性、具体的な UI パターン、ユーザージャーニーのロジック、またはその組み合わせか
• そのままコードに進むのか、まずビジュアル案を作成するのか、実装中に生成アセットを作成するのか

ブリーフの形式：

Designing [WHAT] for [WHO] on [PLATFORM].
Goal: [PRIMARY USER GOAL].
Tone: [DESIRED FEELING].
Main objection/risk: [OBJECTION].
Must remember: [HOOK OR DISTINCTIVE IDEA].
Constraints: [CONSTRAINTS].
Research needed: [styles/screens/flows].
Path: [direct build / visual exploration / audit / asset generation].

ワークフローの選択

高品質な結果を得られる、最も軽量なワークフローを選びます。

• 直接実装： 小規模な UI 修正、内容が明確な本番環境向け編集、既存のデザインシステムに関する作業、または照合する具体的なソースがあるタスクで使用します。調査して方向性を確定してから、コードを作成します。
• ビジュアル探索： ユーザーが複数案、新しいビジュアル言語、大幅な再設計、ランディングページ、または複数の方向性が考えられる注目度の高い画面を求めている場合に使用します。通常は、参照資料に基づく3案を提示してユーザーに選んでもらいます。詳しくはreferences/visual-workflow.mdを参照してください。
• 監査： 批評の根拠として、キャプチャしたスクリーンショット、Refero の画面、またはフローを使用します。
• アセット生成： 参照資料との整合性を保つためにビットマップメディアが必要で、コード、アイコン、既存アセットでは忠実に表現できない場合に限り、生成画像を使用します。詳しくはreferences/visual-workflow.mdを参照してください。

ツールの選択

ビジュアル作業では、まずスタイルを使用する

ユーザーがビジュアル要素を含むものの設計、再設計、改善、仕上げ、作成を求めている場合は、refero_search_stylesを使用します。

スタイルとは、実際のWebマーケティングページや製品ページから抽出された、意味的なデザインリファレンスです。スクリーンショットでも、コンポーネントライブラリでもありません。検索結果にはプレビューが表示され、refero_get_styleで取得できるスタイルの完全なリファレンスには、ビジュアルの方針、トークン、タイポグラフィ、レイアウトと構成、セクションのリズム、余白、高低差、表面、コンポーネント、画像の扱い、実装上の注意点、推奨事項と禁止事項など、デザインの指針が含まれます。

現在の制限：Refero のスタイルは現在、ランディングページ、料金ページ、製品マーケティングサイト、エディトリアル系のブランドサイト、SaaS の Web サイトなど、Web マーケティングページや製品ページを対象としています。アプリ内ダッシュボード、認証画面、設定画面、iOS アプリ画面は、スタイルシステムとしては現在対象外です。それでも、製品 UI のタスクではスタイルを使用してビジュアル言語を確立し、その後、製品のロジックには画面やフローを使用します。

次の用途にはスタイルを使用します。

• 見た目や印象
• ブランドの方向性
• ランディングページやマーケティングページ
• タイポグラフィ、配色、レイアウト、セクション構成、余白、角の丸み、高低差、表面
• コンポーネントの表現や、場合によってはコンポーネント／コードの例
• 画像や製品スクリーンショットの扱い
• デザインシステムの参考
• 汎用的なインターフェースの洗練

具体的な UI パターンには画面を使用する

次の情報が必要な場合は、refero_search_screensを使用します。

• 特定の画面タイプ
• 特定のコンポーネントや UI パターン
• ページのレイアウトやコンテンツの階層
• コピーや CTA のパターン
• フォームや状態の例
• ダッシュボード、設定、モーダル、テーブル、料金表示、空の状態、認証、または製品画面の詳細

有力な画面が見つかったら、次の操作を行います。

• 詳細情報を確認するには、refero_get_screenを使用します
• 有力な例をもとに候補を広げるには、refero_get_similar_screensを使用します
• 生のスクリーンショットを確認する必要がある場合に限り、refero_get_screen_imageを使用します

ユーザージャーニーにはフローを使用する

タスクに前後の順序がある場合は、refero_search_flowsを使用します。

• オンボーディング
• サインアップ
• チェックアウト
• サブスクリプション管理
• 解約
• アカウント削除
• パスワードのリセット
• プロフィール／設定の変更
• その他の複数ステップのプロセス

有力なフローが見つかったら、refero_get_flowを使用して、各ステップの目標、操作、システムの応答、完了状態を確認します。

画像にはビジュアルワークフローを使用し、QA を実施する

画像生成、ビジュアルの選択肢、生成アセット、ビジュアル QA については、必要に応じて references/visual-workflow.md をお読みください。

リサーチワークフロー

1. スタイルを使ってビジュアルの方向性を調査する

ビジュアルデザインのタスクでは、まずここから始めてください。

おすすめの手順：

1. 異なるビジュアルの切り口を3～5種類検索します。
2. 幅広い美的方向性に関するクエリを1つ含めます。
3. 分野やカテゴリーに関するクエリを1つ含めます。
4. 関連する場合は、よく知られたブランドや優れた製品に関するクエリを1つ含めます。
5. refero_get_style を使って優れたスタイルを3～4種類取得します。スタイル全体は大きいため、調査の範囲が広い場合は複数のバッチに分けます。
6. 各スタイルがどのような要素をもたらすか比較します。
7. 主軸となるスタイルを1つ選び、ほかのスタイルから具体的なディテールを1～2点取り入れます。
8. 実装前に、主軸となるリファレンスの特徴的な要素を固定します。

スタイルの検索クエリ例：

• エディトリアルなモノクロの SaaS ランディングページ
• 温かみと信頼感のあるヘルスケア製品のマーケティング
• 控えめなタイポグラフィを使った高級感のあるフィンテックサイト
• 鮮やかなアクセントを使った、遊び心のあるクリエイターツールのランディングページ
• 製品のスクリーンショットを使った開発者向けツールのウェブサイト
• エディトリアルな商品ページを備えた高級 EC サイト
• 余白を広く取った生産性向上 SaaS
• ダークで技術的なスタイルのデータインフラストラクチャサイト
• エディトリアルなタイポグラフィの Attio SaaS
• ダークな開発者向けツール Linear changelog
• shadcn モノクロのデザインシステム

スタイルから抽出する要素：

• 北極星／ビジュアルの主題
• タイポグラフィの個性と文字サイズのスケール
• 色の役割とアクセントの規律
• 余白の密度とリズム
• レイアウトシステム、セクションのリズム、構成パターン
• カード、ボタン、サーフェスの表現
• 枠線、影、角丸
• 奥行きと立体感のルール
• コンポーネント例と、記載があれば実装やコードに関する注記
• 画像、グラフィック、イラスト、製品スクリーンショットの扱い
• メディアアセットの方針：実際のアセット、生成画像／ストック画像、コードで作成するプリミティブ、製品のスクリーンショット、プレースホルダー
• すべきこと／避けるべきこと
• 応用する、印象に残るビジュアル上の工夫を1つ

スタイルの統合ルール：

• 主軸のスタイル：全体のムード、密度、構成を決めます。
• 副次的なスタイル：具体的なディテールを取り入れます。
• ユーザーのコンテキスト：製品、対象ユーザー、タスクに合わせてすべてを調整します。
• すべてのリファレンスの平均や共通部分を使わないでください。1つがダーク、1つが酸味のある色調、もう1つがセリフ体なら、答えは温かみのあるクリーム色にくすんだオレンジと上品なセリフ体を組み合わせたものではありません。

結果を「X のコピー」として提示しないでください。複数のリファレンスに着想を得た、新しい方向性として提示してください。

実装の前に、リファレンスロックを作成します。

Primary reference/direction: [one dominant source]
Preserve: [3-5 traits that must survive: canvas, type, accent, layout, density, media]
Borrow only: [1-2 specific secondary details]
Role rules: [source token/component meanings to preserve, e.g. CTA-only, code-only, decorative-only]
Media strategy: [real/generated/stock/code-native/placeholder, with aspect ratio and art direction]
Reject: [defaults/averages that would collapse the direction]
Token commitments: [background, type, accent, radius, border/shadow, imagery treatment, with roles]

実装がリファレンスロックから逸れたら、作業を止めて修正してください。特徴的な要素を、無難な色、無難なフォント、控えめな角丸、ありきたりなセクションレイアウトに置き換えてはいけません。リファレンスロックは複製を目的としたものではありません。選んだ要素を維持しつつ、コンテンツ、ブランド、インタラクションの詳細をユーザーの製品に合わせて調整するためのものです。

スタイルを組み合わせる場合は、各参照元の役割を限定してください。たとえば、キャンバスとタイポグラフィは一方、コードウィンドウの表現は別の一方、メインの CTA はさらに別の一方に担当させることができます。トークンを担当する役割の範囲外に移さないでください。CTA の色は CTA 専用にし、シンタックスカラーはコード内にとどめ、装飾的なグラデーションは装飾のみに使い、カードやボタンには指定された角丸、影、状態の挙動を適用してください。

主軸のスタイルが画像主体なら、テキストのみのレイアウトに置き換えないでください。必要な画像やグラフィックを用意できない場合は、寸法、アスペクト比、キャプション／代替テキスト、短いアートディレクションの注記を含め、安定したスペースを確保してください。シンプルな図、アイコン、コードウィンドウ、幾何学的なプリミティブを作るのは、参照元のスタイルに合致する場合に限ります。

大規模なビジュアルの検討、生成モックアップ、ビットマップアセット、またはビルド後のビジュアル QA については、references/visual-workflow.md に従ってください。

2. プロダクトの詳細は画面を調査する

インターフェースにどのような要素を含めるべきか、実際のプロダクトが特定の UI の課題をどのように解決しているかを知りたいときは、画面を調査します。

画面の検索クエリの例：

• 料金ページ 年間・月間の切り替え
• 機能比較表
• ダッシュボードの空の状態
• 請求設定の解約モーダル
• オンボーディングの進捗インジケーター
• 2FA の設定とリカバリーコード
• データテーブルのフィルター
• 破壊的操作の確認

画面上の情報を使って検索します：

• ページの種類
• コンポーネント
• 状態
• 企業／プロダクト
• 画面上のテキスト

ビジュアルが主題のタスクでは、画面を主要なスタイルの参考資料として使わないでください。まずスタイルを調べてから、構成や具体的な詳細を把握するために画面を調べます。

画面から把握する内容：

• レイアウト構造
• 情報の階層
• コンポーネントの選択
• CTA のパターン
• コンテンツ／コピーのパターン
• 状態とエッジケース
• 信頼やコンバージョンを促す手法
• 応用する価値のある具体的な詳細

3. ジャーニーのロジックはフローを調査する

複数のステップがある場合や、ユーザーの状態が時間とともに変化する場合は、フローを調査します。

フローの検索クエリの例：

• サインアップのオンボーディング
• プロモーションコードを使ったチェックアウト
• サブスクリプションの解約
• アカウント削除時のフィードバック
• パスワードリセットと 2FA
• ワークスペースの請求プランのアップグレード

フローの検索結果が少ない場合は、クエリの範囲を広げます。それでも少ない場合は、画面を調査し、ジャーニーを再構成します。

フローから把握する内容：

• 開始地点と終了時の状態
• ステップ数
• ユーザーが行う判断
• 手間を軽減する工夫
• 必須の確認事項
• 保存／復元の状態
• エラー処理
• 継続利用や説得を促すタイミング
• 各ステップでのシステムの応答

調査の深さ

タスクのリスクに合わせて調査の深さを調整します。

手早くビジュアルを改善する場合：

• スタイル検索を 2～3 回
• 全体スタイルを 2～3 件
• 簡潔な統合を 1 回

新しいランディングページ、ブランドの方向性、または大規模な再設計の場合：

• スタイル検索を 3～5 回
• 全体スタイルを 1 回のバッチで 3～4 件。必要な場合のみ追加のバッチを使います
• 具体的なセクション／コンポーネントの画面を調査
• 実装前に明確なビジュアルの方向性を定める

プロダクトのワークフローの場合：

• ビジュアル言語のスタイル
• 主要な状態／コンポーネントの画面
• 手順の順序を把握するフロー

重要度が高いタスクや曖昧なタスクの場合：

• 複数の観点から検索する
• 後続のページを確認する
• 優れた参考例と独特な参考例を比較する
• デザインの前にトレードオフを記録する

統合

調査結果を 3 つの分類に分けます。

ビジュアルの方向性

スタイルから得る情報：

• ムード
• タイポグラフィ
• 配色
• 密度
• サーフェス
• 画像
• 独自の詳細
• すべきこと／避けるべきことのルール

出力例：

Use a precise analytics SaaS foundation: white canvas, compact UI copy, restrained black
primary actions, thin borders, and product screenshots in framed panels. Borrow disciplined
accent use from another reference, but keep color rare.

プロダクトのパターン

画面から得る情報：

• インターフェースに含めるべき要素
• 一般的なレイアウト
• コンポーネントのパターン
• 状態
• コピーと CTA
• 具体的な手法

出力例：

Pricing pages commonly put the billing toggle above plan cards, highlight one plan, and
move detailed feature comparison below. We should adapt the comparison structure but keep
the hero quieter because this product sells trust, not hype.

ジャーニーのロジック

フローから得る情報：

• ステップ
• 判断ポイント
• システムの応答
• ユーザーの確信度と負担
• 成功／失敗の状態

出力例：

Cancellation flows usually collect a reason, offer a relevant alternative, confirm the
destructive action, then state when access ends. The best flows give a clear return path.

調査結果の提示

調査結果をすべて羅列しないでください。タスクが簡単ではない場合は、デザインを始める前に簡潔な調査概要をユーザーに提示します。

推奨形式：

Research summary:
- Styles reviewed: [count] across [directions]
- Screens reviewed: [count], if used
- Flows reviewed: [count], if used

Visual direction:
- [primary style foundation]
- [reference lock / signature traits to preserve]
- [borrowed detail 1]
- [borrowed detail 2]

Product patterns:
- [concrete UI decisions from screens]

Journey logic:
- [flow decisions, if applicable]

Recommendation:
- [what to design and why]

実装の前に、調査結果を簡潔な判断台帳にまとめます：

判断	出典	出典のルール／役割	理由
［配色／書体／レイアウト／メディア／コンテンツの選択］	［スタイル／画面／フロー／ユーザーの制約／制作上のルール］	［維持するトークン／コンポーネント／メディアの役割］	［具体的な根拠］

重要な選択に出典がない場合、それをデザイン上の判断として採用してはいけません。追加調査を行うか、ユーザーの制約に結び付けるか、取り除きます。

デザインの仕上げ

リサーチの後は、シニアプロダクトデザイナーとして実行します。同梱のリファレンスは関連する場合にのみ使用し、デフォルトですべてのファイルを読み込まないでください。

• タイポグラフィ：references/typography.md
• 色：references/color.md
• モーション：references/motion.md
• アイコン：references/icons.md
• フォーム、フォーカス、画像、タッチ、パフォーマンス、アクセシビリティ：references/craft-details.md
• コピーライティングと説得：references/copywriting.md
• AI っぽさを避けるためのチェック：references/anti-ai-slop.md

デザインの仕上げに関する基本ルール：

• 実装前にトークンを定義します。文字サイズのスケール、色、スペーシング、角丸、シャドウなどです。
• 主要なリファレンスの最も際立った特徴を均一化せずに活かします。
• リファレンスのトークンの役割を保ちます。CTA のアクセントを背景にしたり、コード専用の色を UI の装飾に使ったり、装飾的なグラデーションをインターフェースの表面にしたりしないでください。
• リファレンスにある画像の役割を保ちます。適切なアセットがあれば活用し、なければ質の低い偽物のイラストや写真よりも、誠実で適切なサイズのプレースホルダーを優先します。
• リサーチに基づき、ブランドに適した色を使います。ユーザーから明示的に指定されない限り、デフォルトでインディゴやバイオレットを使わないでください。
• 「落ち着いたエディトリアル調」は、現在の AI っぽいデザインに陥るリスクとして扱います。リサーチとプロダクトの文脈で正当化されない限り、見出しの一語や短いフレーズだけを異なるディスプレイ体、セリフ体、スクリプト体、イタリック体、アクセントカラーで装飾することや、暖かみのあるアイボリーやクリーム色のキャンバス、オリーブ、クレイ、テラコッタの配色をデフォルトで使わないでください。
• リサーチで裏付けられていない限り、汎用的なヒーロー → 特徴のグリッド → 料金 → FAQ → CTA の構成は避けます。
• コピー、信頼性を示す要素、懸念への対応、セクションの順序には、実際のプロダクトの根拠を使います。
• ユーザーの記憶に残る視覚的な工夫、インタラクション、レイアウト、コピーのいずれかを少なくとも一つ取り入れます。
• 見出しや短いディスプレイテキストでは text-wrap: balance を使い、本文では必要に応じて text-wrap: pretty を使います。重要なブレークポイントで、孤立した単語や不自然な最終行がないか確認します。
• アクセシビリティとレスポンシブな動作を、後回しにせずデザインに組み込みます。

品質チェック

最終成果物を渡す前に、以下を確認します。

• 視覚的なテイストを出すためにスタイルを活用したか？
• 一つのスタイルをそのままコピーしていないか？
• 複数のリファレンスを独自の方向性へと統合したか？
• リファレンスを無難な中間点へと平均化していないか？
• 主要なリファレンスの特徴的な要素を保ったか？
• 元のトークンやコンポーネントの役割を、別の用途に転用せず保ったか？
• 必要な画像やメディアの役割を、実際のアセット、適切なプリミティブ、または意図的なプレースホルダーで保ったか？
• 具体的な UI パターンが必要な箇所で、画面を使用したか？
• 複数のステップがあるタスクで、フローを使用したか？
• デザインに影響したリファレンスとその理由を説明できるか？
• 主要なデザイン上の選択それぞれを、リファレンス、ユーザーの制約、または仕上げのルールに結び付けられるか？
• 実装前にコンセプトと意思決定の記録を作成したか？
• 実装が汎用的な AI デザインの定番を避けているか？
• リファレンスとコンテンツ上の役割に根拠がない限り、装飾的なセリフ体、イタリック体、色による単語の強調を避けたか？
• 成果物はユーザーのプロダクト、対象者、制約に合っているか？

回答が「いいえ」の場合は、納品前にさらにリサーチするか、改善してください。

大規模なビジュアル制作では、引き渡し前に references/visual-workflow.md にあるビジュアル QA の手順を実施します。

例

一連の手順については、references/example-workflow.md を参照してください。