designloop

designloop は何をしますか？

既存のインターフェースやその周辺の書き物の品質を、推測ではなく計測によって向上させるループ。各ラウンド：同じ方法でUIをキャプチャ（またはテキストをスナップショット）し、新しい審査員が固定ルーブリックに基づいて採点し、発見された問題を修正して繰り返します。これはdream-loopの審査方法（毎ラウンド新しい審査員、細かい指摘、退行は低評価）を、ターゲット画像との一致ではなくUIポリッシュに応用したものであり、また、Theo (t3.gg) がAgents Sucked At UI (Until Today)で述べた、UIデザインにおける丘登りアプローチをモデルにしています。

このループは、以下の3つの分離によって機能します。これらを維持してください。

• 審査員は実装せず、実装者は審査しません。 修正を書いたエージェントは自分に甘い採点をします。
• 審査員は毎ラウンド新しいメンバーです。 前のラウンドを見た審査員は、自身の以前の判定に引きずられます。新しい審査員には、ルーブリック、新しいキャプチャ、および前回の判定（採点の一貫性を保ち、退行を指摘するため）を与え、会話は与えないでください。
• キャプチャセットは固定されています。 Nラウンド目が0ラウンド目と同じ表面、状態、テーマを示している場合にのみ、スコアは比較可能です。

3つのモード

ループ自体は全モードで同じです。審査員の評価基準だけが異なります。最初にモードを確定してください。ルーブリック、問うべき質問、期待される変更量が決まります。

• プロフェッショナルポリッシュ — 客観的なパス。シニアプロダクトデザイナーがチェックする項目：トークンとサーフェスの一貫使用、フォントサイズとウェイトの削減、一貫したスペーシングスケール、可読性とコントラスト、ヒットターゲットとカーソルゾーン、状態カバレッジ、ライト/ダークパリティ、モーション品質。目標はアプリ自身の最高の状態であり、好みの変更は範囲外です。references/mode-polish.mdを参照してください。
• アートディレクション — 特定のルック＆フィールに向けた主観的なパス：名前付きスタイル（「グラフィックリアリズム」、「ASCIIアートとブルータリストで動的なレイアウトを用いたネオンポップ」）、一連のリファレンス、生成されたターゲット画像、または一致させるFigmaデザイン。審査員はUIがその方向性をどれだけ表現しているかを採点します。より大きな視覚的変更が想定されるため、フォント、色、レイアウトの特性が影響を受けます。references/mode-art-direction.mdを参照してください。
• ライティング — 言葉に適用されたループ：UIコピー（ラベル、エラー、空状態、オンボーディング）、ドキュメントとプロダクトページ、または独立した作品。審査員は、名前付き読者に対して、明確さ、簡潔さ、声、一貫性、正確性を、リーダーテスト（新しいエージェントがテキストを初見で読み、何をするかを述べる）に基づいて採点します。意味は固定され、言葉が改善されます。references/mode-writing.mdを参照してください。このファイルでは、以下の各ステップがどのように変わるか（サーフェスではなくテキスト、キャプチャではなくスナップショット、トークンではなく用語集）が説明されています。

リクエストからモードが明確な場合は推測します（「タイトにする」、「一貫性がない」、「雑」→ポリッシュ；「～のように見せる」、「よりアーティスティックに」、スタイル名、Figmaリンク→アートディレクション；「コピー」、「文言」、「ドキュメント」、「エラーメッセージ」、「この投稿」→ライティング）。そうでない場合は尋ねてください。ユーザーは複数のモードを希望することもあります。まずアートディレクションを実行してルックを設定し、次にポリッシュパスで一貫性を持たせ、さらにコピーに対してライティングパスを実行します。それぞれを独自のルーブリックを持つ独立したループとして扱います。1つのルーブリックに混ぜないでください。審査員が一貫性とスタイルをトレードオフし、スコアが意味をなさなくなります。

ステップ1: ユーザーへのインタビュー

モードを確定したら、残りの質問をAskUserQuestionで行います（2回の呼び出し。各最大4つの質問）。ユーザーのメッセージですでに回答された質問はスキップし、最初に推奨オプションを提示してください。回答はブリーフファイル（ステップ3）に保存され、すべてのサブエージェントが参照します。

1. 目標 — 完了時に何が改善されていればよいか、ユーザーの言葉で。（「Chromeの一貫性がない」、「メニューが雑」、「カクつく」）また、禁止範囲も尋ねます。ユーザー自身が処理したいサーフェスや、許容できる変更の程度（微調整 vs. スタイル変更 vs. 再デザイン）。ほとんどのユーザーは再デザインではなく微調整を望みます。すべてのブリーフや実装者への指示にその旨を明記し、過剰な変更を防ぎます。
2. 焦点（複数選択可） — 最も重要な次元。これによりルーブリックの重みが設定されます。オプションはモードによって異なり、そのリファレンスファイルにリストされています（ポリッシュ：一貫性とトークン、タイポグラフィ、スペーシングとレイアウト、可読性、インタラクションとヒットターゲット、モーション、パフォーマンス；アートディレクション：選択されたルックの特性、およびUIのどの部分がそれを伝えるべきか；ライティング：明確さ、簡潔さ、構造、声とトーン、一貫性、有用性、正確性）。ライティングモードでは、references/mode-writing.mdの追加質問も尋ねます（読者と目的、声のサンプル、固定するもの、長さとローカライゼーションの制限）。
3. ベースライン — 現在のUIの状態。ユーザーが10点満点で評価するか、審査員が最初に採点します。ユーザーが意見を持っている場合は両方を推奨します。ユーザーの数値で審査員を較正します（ユーザーが6点と言い、審査員が8点なら、ルーブリックが甘すぎるため、ラウンド1の前に厳しくします）。
4. 停止条件 — 目標スコア（例：すべてのグループとテーマで≥9/10）、ラウンド数、または先に達した方。「目標スコア、上限Nラウンド」を推奨します。上限なしのループはトークンを多く消費する可能性があると警告します。
5. サブエージェントのインテリジェンス — 審査員と実装者が使用するモデルと努力量。以下から選択肢を提示：最高（最も遅いが最も徹底）、バランス（セッション自身のモデルと努力量）、高速（キャプチャと機械的な修正には安価なモデル、審査には強力なモデル）。審査に最もインテリジェンスを投資するのが効果的です。節約したい場合は、キャプチャと機械的な実装から節約します。
6. リファレンス — ユーザーが気に入っている、または一致させなければならないデザインはありますか？ウェブサイト、アプリ、スクリーンショット、Figmaリンク、デザインシステム、または名前付きガイドラインやスキル（プラットフォームHIG、デザインエンジニアリングスキル）。それぞれのどこが気に入っているか尋ねます（密度、メニュー、モーション）。理由なしに「このサイトのように」と言われると、そのままコピーされる可能性があります。ポリッシュモードではリファレンスはオプションであり、通常はガイドラインです。アートディレクションモードではループにターゲットが必要です：スタイルの説明、リファレンス、Figmaデザイン、または生成画像。ユーザーにない場合は、収集または生成を提案します（「リファレンスとターゲット」を参照）。
7. 納品 — ブランチのみ、PR（マージしない）、またはユーザーが実行できるビルド。デフォルト：ブランチ＋未マージのPR。明示的に依頼がない限り、マージやリリースは絶対に行わないでください。

ユーザーから得たすべての情報を.designloop/references/（ステップ3）に配置し、ルーブリックにリストしてください。すべての審査員と実装者が同じソースから作業できるようにします。

ステップ2: プロジェクトのセットアップを調査する

ルールを書く前に、このプロジェクトが実際にどのように実行、テスト、出荷されているかを調べ、ループが独自の習慣を押し付けるのではなく、ユーザーの習慣に従うようにします。まず調査し、次に質問します。リポジトリとマシンからわかることを読み取り、まだ不明な点や好みの問題だけを質問します。

調査項目：

• すでに書かれている指示： CLAUDE.md / AGENTS.md、READMEとCONTRIBUTING、メモメモ、および以前のエージェントルールファイル。これらは推測よりも優先されます。
• アプリの実行方法と駆動方法： パッケージスクリプト、Makefile、開発ビルドと本番ビルド、およびそれをキャプチャできるもの（ブラウザ/CDP、Playwright、シミュレーターまたはデバイスツール、既存のスクリーンショットまたはe2eセットアップ）。アプリを自動的に駆動する方法がない場合は、その旨を伝え、ユーザーがどのようにキャプチャを作成したいかを尋ねます。
• プロジェクトが信頼するチェック： 型チェック、リント、テスト、ビルド、およびそれらが現在パスしているかどうか。
• Gitの習慣： デフォルトブランチ、ブランチ命名規則、ワークツリーがすでに使用されているかどうか、コミットメッセージの慣例、PRを介した作業かどうか。
• 実行がリポジトリ外に影響を与える可能性のあるもの： 実際のアカウント、有料APIやAIバックエンド、メッセージング、本番データ、ユーザー自身のアプリプロファイルやデバイス。モック、デモ、またはサンドボックスモードがあるかどうかを確認します。
• デザインツールが接続されているかどうか： ユーザーがFigmaリンク（または他のデザインツールリンク）を提供した場合、それを読み取れるコネクタまたはMCPサーバーが利用可能か、およびサインインしているかどうかを確認します。
• ここで画像を生成できるかどうか： このセッションが実際に呼び出せるものを確認します（仮定しないでください）。一部のハーネスには画像生成が組み込まれています（Codexなど）。他の場合は、インストールされたスキル、プラグイン、またはMCPサーバー（Higgsfieldや他の画像モデル）から提供されます。利用可能なツールとスキルを調べてください。ない場合でもループは機能します。ターゲット画像はオプションです。
• 並列作業に影響するマシンの制限： 空きディスク容量、すでに使用中のポート、実行中の他のエージェントや開発サーバー。

次に、調査結果から確定できなかった選択肢のみを、1回のAskUserQuestion呼び出しでユーザーに確認します。典型的なもの：

• 作業場所： 現在のブランチ、新しいブランチ、または実装者ごとの個別のワークツリー（実装者が並行して実行する場合に必要）。
• テスト方法： 開発サーバーのみ、または完了前に本番/パッケージビルドもテストするか。カウントするテーマ、ウィンドウサイズ、デバイス。
• 触ったり消費したりしてはいけないもの： 実際のアカウントと有料サービス、およびキャプチャにモックモードが許容されるかどうか。
• 一度に実行する量： 並列実装者、または一度に1つ。

質問内で推測した内容を述べてください（「Xを見つけたので、Yを計画しています」）。ユーザーが迅速に修正できるようにします。結果をRULES.md（次のステップ）に書き込み、どのルールがユーザーから得られ、どのルールを推測したかをメモします。

ステップ3: セットアップ

ソースツリーの外部、またはリポジトリ内のgit無視された.designloop/に作業フォルダを作成します。

.designloop/
  BRIEF.md        # インタビュー回答：目標、範囲（IN/OUT）、変更許容度、焦点、停止条件
  RUBRIC.md       # references/rubric.mdから、選択された焦点に重み付けしたもの
  RULES.md        # ステップ2からのこのプロジェクトの作業ルール（references/briefs.mdを参照）
  references/     # ユーザーが気に入っているもの、およびターゲット画像（下記参照）
  capture/        # キャプチャスクリプトとサーフェスリスト
  round-0/ …      # ラウンドごと：テーマごとの静止画、videos/、index.json、judge-*.md

これらは何かをスパウンする前に作成してください。サブエージェントはコンテキストなしで開始するため、ファイルがコンテキストとなります。再入力する代わりにブリーフをこれらのファイルにポイントします。

• RUBRIC.md — モードのリファレンスファイル（references/mode-polish.mdまたはreferences/mode-art-direction.md）のルーブリックから開始し、共有ヘッダーとreferences/rubric.mdからの審査員出力フォーマットを含めます。ユーザーの焦点に応じて重みを調整し、INおよびOUTのスコープリストを明示的に記述し、最高スコアの意味を定義します。
• RULES.md — ステップ2で確立した内容：アプリの実行方法と駆動方法、gitでの作業場所、実行するチェック、触ったり消費したりしてはいけないもの、クリーンアップ方法。references/briefs.mdにカバーすべき項目のリストがあります。
• サーフェスリスト — スコープ内のすべてのサーフェスと、それぞれの評価すべき状態（rest、hover、open、selected、empty、error、busy）および各テーマ。各審査員が詳細に見られるよう、関連するサーフェスを2つまたは3つのグループに分割します。1人の審査員が50枚のスクリーンショットをざっと見るのは避けてください。

開始する前にプロジェクトのチェックがパスすることを確認してください。後で失敗した場合、それがあなたの責任であることがわかります。

リファレンスとターゲット

ルーブリックは一般的な良さを定義し、リファレンスはこのユーザーにとっての良さがどのように見えるかを定義します。アートディレクションモードでは常に何らかのターゲットが必要です。ポリッシュモードはルーブリックだけで実行でき、アプリ自身の最高のサーフェスを標準とします。

ターゲットには3つの種類があり、それぞれ権威が異なります。各ファイルがどの種類かをreferences/README.mdに記述してください。審査員と実装者はそれらを異なる方法で扱う必要があります。

• 仕様（ユーザーが一致させたいと言うFigmaデザイン）：権威あり。一致させます。
• リファレンス（ユーザーが気に入っているサイト、アプリ、スクリーンショット）：名前付きの特性を一致させ、全体ではありません。
• 生成画像：雰囲気のみの方向性。

ユーザーが提供するリファレンス。 .designloop/references/に短いREADME.mdとともに保存します。各ファイルについて、それが何か、ユーザーが何を気に入っているかを記述します。ウェブサイトやアプリの場合、関連部分のスクリーンショットをキャプチャします（モーションが魅力の場合はクリップも）。各ラウンドで審査員が同じものを参照できるようにし、変更される可能性のあるページを再フェッチしないようにします。好みを具体的でチェック可能な特性に変換してルーブリックに記述します（「行の高さ約28px」、「アクセントカラー1色」、「メニューは200ms未満でフェードイン」）。審査員は雰囲気ではなく特性を採点できます。

あなたが収集するリファレンス。 ユーザーが方向性を望んでいるが例がない場合、彼らの目標に合ったよく知られた製品のインターフェースを3つまたは4つ提案し、それらを示し、ユーザーに選択させます。ユーザーに代わって選択しないでください。

Figmaデザイン。 ユーザーがFigmaリンクを提供した場合、このセッションでFigmaコネクタまたはMCPサーバーが利用可能かどうかを確認します（ステップ2）。利用可能な場合は、まずそのスキルまたは指示をロードし、次にリンクされた各フレームに対して取得します。

...