複数評価者によるデザイン改善ループ
製品が実際のユーザーに提供できる状態になるまで、独立したレビュアーによる評価ラウンドを繰り返します。すべてのジャーニーですべてのレビュアーから9点以上を獲得し、高重要度の修正が残っておらず、レビュアー間のスコア差が1点以内であり、その状態が2ラウンド連続で維持されることを要件とします。満点の10点が全員一致することは、要件定義を見直すべきフラグであり、目標ではありません。AIのスコアは強力なシグナルではありますが、絶対的な証明ではありません。ループが「提供可能」と判断したら、実際の初めてのユーザーがテストを行い、AIとユーザーの意見が異なる場合はユーザーの意見を優先します。
すべての処理は、1つのコマンドラインツール scripts/eval_loop.py（このファイルの隣にあります）を通じて実行されるため、人間、このエージェント、または他のどのエージェントでも同じ結果が得られます。すべてのコマンドは --dir <レビューフォルダ> を受け付け、status --json は常にループの現在の状態と次にすべきことを出力します。Python 3.9以降、Node.js 18以降、およびGoogle ChromeまたはChromiumが必要です。その他のインストールは不要です。
以下、LOOP は python3 <このスキルのフォルダ>/scripts/eval_loop.py を意味します。
開始前の確認（すべてのmStackスキル共通）
~/.mstack/config.jsonの"disabled"にmulti-evaluatorがリストされている場合、またはユーザーがこのタスクでの使用を禁止した場合は、通常の方法で作業します。~/.mstack/learned/multi-evaluator.mdが存在する場合は、それを読みます。このファイルにはユーザーが受け入れた改善点が記録されており、このファイルよりも優先されます。- ループが終了した（または停止した）ら、結果を非公開で記録します：
python3 <mstackスキルフォルダ>/scripts/mstack.py log multi-evaluator --outcome reached|partial|not-reached --needed-user "..." --stalled "..."（mstackスキルはこのスキルの隣にあります）
1. ジャーニーと基準の事前定義
評価を開始する前に、実際のユーザーがエンドツーエンドで何ができるべきかをユーザーと合意します。
LOOP init --dir design-review --name "<製品名>" --start "<起動コマンド（{port}を含む）>" --cwd <そのフォルダ>（または、すでに実行中のもの（ステージングサイトなど）には--url <アドレス>を使用）- ユーザーと一緒に
design-review/mstack-eval.jsonを記入します。各フィールドの詳細はreferences/config.mdを参照してください：aboutとpersona：製品の説明と、誰が評価するか。デザインの方向性や制約はaboutから除外し、rulesに記述します。これらはレビュアーに「採点対象外」として表示されるため、仕様書が期待する答えをあらかじめ示すことはありません。journeys：3～6の実際のタスク（エンドツーエンドで「本を追加してリストに表示されることを確認する」など）。views：毎ラウンドキャプチャする固定画面（デスクトップ、スマートフォン、ダークテーマ）。ライトテーマを最初に指定します。criteria：基本評価基準は「明確」「迅速」「信頼」「親しみやすさ」「落ち着き」「どこでも動作する」です。stagesでは、製品の成熟に応じて評価基準を追加します（価値実現までの時間、エラー復旧、コピー、エージェント体験、測定されたアクセシビリティ、速度、ファイブセカンドテスト、感情トーン、一貫性、データ安全性、魅力）。ステージは"active": trueまたは"from_round": <n>で有効にします（スコアが基本基準を満たした場合）。reviewers：少なくとも2人、異なるAIメーカーから選びます。デフォルトはClaude（エージェントが実行）とCodex（ツールがcodex execを使用して実行）です。control：ノイズチェック（推奨）。最初のキャプチャでそのラウンドのスクリーンショットをcontrol/に固定し、すべてのレビュアーが毎ラウンドこれをジャーニーcontrolとして採点します。レポートにはそのスコアの変動が表示されます。この変動よりも小さい変化はノイズであり、進捗ではありません。
- ラウンド1の前に、ジャーニーと評価基準をユーザーに提示し、承認を得ます。
2. 各ラウンド
LOOP start-round --dir design-review # rounds/r<N>/ を作成し、このラウンドの評価基準をスナップショット
# rounds/r<N>/changes.md を記述：変更点を箇条書きで
LOOP capture --dir design-review # 毎ラウンド同じ方法で同じスクリーンショットをキャプチャ
LOOP brief --dir design-review # ブラインドスコアリング用の概要を rounds/r<N>/briefs/ に作成。ラウンド2からは比較用概要も追加
LOOP review --dir design-review # コマンドラインレビュアー（Codex）を並列実行；バックグラウンドで実行
同時に、kind が agent であるすべてのレビュアーを新しいコンテキストで自分自身で実行します：
- Claude Code：サブエージェント（Agentツール、汎用目的）を起動し、プロンプトとして
rounds/r<N>/briefs/claude.mdの全文を渡します。自分の意見、期待する答え、以前のスコアを追加しないでください。 - その他のエージェント：新しいセッションまたはスレッドを開き、概要のみを指示として与えます。
kind: "chat"のレビュアー（オプション、オプトイン：ユーザー自身のサインインブラウザでGrok、ChatGPT、Geminiを使用、APIキー不要）：ユーザーの同意を得た上で、新しいプライベートチャットを開き、rounds/r<N>/briefs/<id>.mdを貼り付けます。製品が公開されていない場合はこのラウンドの固定スクリーンショットをアップロードし、返信を保存してタブを閉じ、verdictを実行します。このレビュアーはスクリーンショットのみを見て実際の製品は見ないため、タイブレーカーとして機能します。「ユーザー提供可能」の判定にはカウントされず、唯一のレビュアーになることはできません。
返信が届いたら、JSONを保存します（ツールがフォーマットをチェックし、形式に合わない返信を拒否します）：
LOOP verdict --dir design-review --reviewer claude reply.json # または返信をパイプで - として入力
まずブラインド、次に比較。 スコアリング用の概要はこのラウンドのみを表示します。以前のスクリーンショット、以前のスコア、デザインの方向性は表示されないため、スコアはラウンド1とラウンド9で同じ意味を持ちます。ラウンド2からは rounds/r<N>/briefs/<reviewer>-compare.md も存在します。同じレビュアーにその判定が保存された後（同じセッションで問題ありません。もはやブラインドではありません）に渡し、返信をスコアとは別に保存します：
LOOP verdict --dir design-review --reviewer claude --compare compare-reply.json
LOOP report --dir design-review # design-review/report.html を作成
比較によってスコアが変更されることは決してありません。レポートでは「変更点」として表示されます。
その後、ユーザーにレポートとライトテーマのスクリーンショット（rounds/r<N>/shots/）を表示します。エージェントが通知を送信できる場合（Claude CodeではPushNotification）、ラウンドのレポートが準備できたときやループが決定を必要とするときに通知を送信します。設定の notify コマンドでも通知を送信できます（references/config.md を参照）。
3. 修正して繰り返す
- レポートの次に実行する項目リストから開始します（すべてのレビュアーが最初に指摘したジャーニーの修正、次に高重要度、次に最大の「修正された場合」のギャップ）。ジャーニーテーブルでレビュアーのスコアが2以上異なる場合は、どちらかのスコアに基づいて行動する前に、そのジャーニーを自分自身で確認します。
- 製品に修正を加え、自身のテストを実行し、次のラウンドの
changes.mdを作成します。 LOOP start-roundを実行し、LOOP statusがユーザー提供可能（上記の停止条件、2ラウンド連続）と表示するまで繰り返します。あるラウンドが条件を満たした場合、大きな変更は加えずにもう1ラウンド実行して条件が維持されることを確認します。max_rounds（デフォルト6）に達しても条件を満たさない場合、statusは停止してユーザーと話し合うように指示します。ジャーニーまたは評価基準が、製品が本来達成すべきでないことを要求している可能性があります。- その後、実際のユーザー：5人の初めてのユーザーが支援なしでジャーニーを試します。彼らの時間、つまずき、発言を
rounds/r<N>/people.mdに記録します（箇条書きで1つずつ、レポートに表示されます）。AIレビュアーとユーザーの意見が異なる場合、ユーザーの意見を優先します。彼らが見つけたことを次のラウンドのジャーニーまたは評価基準に反映します。
ルール
- レビュアーは、採点中に互いの判定、以前のラウンド、以前のスコア、レポートを見ることはできません。概要はその旨を明記します。前のラウンドとの比較は、判定後に行う別のパスです。
- 毎ラウンド同じビュー、同じ方法でキャプチャし、比較を同じ条件で行います。
- レビュアーが実際の支払い、メッセージ、個人データを送信しないようにします。デモデータと新しいコピーを使用します。
- サンドボックス化されたレビュアー（Codex）はChromeを起動できません。
reviewは共有のヘッドレスChromeを起動し、概要ではドライバーコマンドの前にMSTACK_CDP_PORT=<ポート>を付けるように指示します。 - レビュアーの返信がフォーマットに合わない場合、
rounds/r<N>/work/<reviewer>/raw-reply.txtを読み、再実行します。ツールは修正案を依然として提案する10点、およびスコアを下回る「修正された場合」のスコアを拒否します。 - レビューフォルダは製品のリポジトリ内（またはその隣）に保持し、すべてのラウンドが保存されるようにします。
ファイル
scripts/eval_loop.py：コマンドラインツール（init、status、start-round、capture、brief、serve、review、verdict、validate、report、notify）。scripts/drive.mjs：ジャーニードライバー（実際のヘッドレスChrome）。レビュアーはこれを直接使用します。scripts/report.py：レポートビルダー。scripts/readiness.py：停止ルールとノイズチェック。templates/mstack-eval.json：スターター設定。references/config.md：すべての設定フィールド。references/verdict-format.md：返信フォーマット。references/method.md：このループがこのように機能する理由と、評価基準がどのように拡張されるか。