work-judge

/work-judge — 生成的設計／ソリューションパネル

このスキルは、ジャッジパネルの品質パターンを実装します。多様な候補を生成し、根拠に基づいて評価し、敗者の優れた点を取り込んだ勝者を統合することで、幅広いソリューション空間を探索します。

これは品質システムにおける1つのパターンです。オーケストレーションモデル（形状、仕組み、スキーマ規約）は ../work/references/workflow-mode.mdに記載されています。 これが防ぐべき失敗モードについては、 ../work/references/anti-error-lessons.md （教訓L1〜L8）に記載されています。このスキルはそれらを運用に落とし込むものであり、内容を繰り返すものではありません。

使用する場面

• ソリューション空間が広い場合：アーキテクチャ、設計上のトレードオフ、「この機能はどのように実装すべきか？」
• 「最善の推測」を1つ出すのではなく、複数の視点を明示的に探索したい場合。
• 既存の主張を純粋に検証する場合には使わず、../work-refute/SKILL.mdを使用してください。
• すでに構築済みの実装から選ぶ場合には使わず、../work-tournament/SKILL.mdを使用してください（worktreeでのトーナメント）。

work-refuteとの違い：こちらは生成的（候補を生成）であり、 比較スコアリングと統合を行います。敵対的アプローチは破壊的であり、 既存の調査結果を否定しようとします。

L1 ゲート — パネルを招集する前に、低コストで結論を出す

**オラクルで結論を出せる判断については、パネルを招集しないでください。**何かを実行する前に、 決定論的な答えが得られるか確認してください。

• 成功／失敗するテスト、型チェック、ベンチマーク、類似の判断がどうなったかを示すgit log、 実現可能性を証明する20行の使い捨てプロトタイプ、選択肢をすでに規定しているAGENTS.mdのルール。
• 1つのコマンドで使えるオラクルや使い捨てのスパイクで問いに決着がつくなら、**実行して判断を記録し、パネルを省略してください。**結論の出ている問いに対して、一般的な視点を並べるだけの1-of-N「パネル」は茶番です（L1、およびworkflow-mode §5の「問いに応じたスケール」）。

パネルは、安価なオラクルが存在しない、真に未解決の設計空間に用います。

使用方法

/work-judge [N=3] "the design problem or decision to explore"

オプション：

• /work-judge 5 "problem description"
• 視点を追加：/work-judge angles="MVP-first,risk-first,user-experience,performance,maintainability" "problem"
• 焦点を指定：/work-judge focus="security and multi-tenancy" "problem"

オーケストレーター（../work/SKILL.md）は、 より大きなハーネスの設計フェーズとして、これを呼び出すことがよくあります。

---

オーケストレーションの形状：PARALLEL / BARRIER

展開する前に、計画／todoにこれを明記してください（workflow-mode §1）。このパネルはパイプラインではなく バリアパターンです。2つのステージに、項目間の実質的な依存関係があるためです。 つまり、前段階の項目がすべてそろうまで開始できません。

Generate   →  parallel fan-out: N candidate agents, one per angle  (no barrier among them)
   ║  BARRIER #1 — judging compares candidates against EACH OTHER → needs ALL candidates
Judge      →  parallel fan-out: judges score the full candidate set
   ║  BARRIER #2 — synthesis grafts across ALL verdicts → needs ALL judge verdicts
Synthesize →  single agent picks base + grafts the best of the losers

パイプラインではなくバリアを使う理由：ジャッジは候補を他の候補との相対比較で順位付けし、 統合では判定結果全体からアイデアを取り入れます。どちらも項目間の実際の比較であり、 workflow-mode §1でバリアが正当化されるとされている、まさにそのケースです。各ステージ内ではエージェントが並行して実行されます。バリアはメインエージェント内の単純なセット／コレクション処理であり、エージェントの呼び出しではありません。

早期終了（候補数の下限）：候補のnullフィルタリング後（仕組みを参照）、 2つ未満しか残らない場合は、比較対象がないため評価を行わないでください。トーナメントを中止し、その理由を記録したうえで、残った候補を比較なしのドラフトとして返すか、終了した視点を1度だけ再起動してください。1つだけの「パネル」はパネルではありません。

ジャッジ数の下限：各候補には、根拠に基づくジャッジの判定が1件以上（workDone:true）必要です。ある候補に対するすべてのジャッジが棄権した場合（L8の怠慢な判定を参照）、その候補は「スコア0」ではなく未評価です。再計算して記録し、棄権をスコアとして扱わないでください。

---

フェーズ（オーケストレーション）

ハーネスのtodo／計画ツールを使って、各フェーズを告知してください（workflow-mode §3のログ／フェーズ）。フェーズ： "L1 oracle check" → "Angle coverage" → "Generating candidates" → "Judging" → "Synthesizing"。

0. 問題の整理と観点網羅性の確認（メインエージェント）

• 決定事項、制約、成功基準、既知の判定基準（テスト、既存コード、AGENTS.md の要件）を明確にします。まず、上記の L1 ゲートを実行します。
• 観点網羅性の事前確認（L5 — 完全性を確認するには、観点リストで網羅されていないものを確認します）。 生成前に、標準的な懸念事項のチェックリストを確認し、それぞれがいずれかの観点で扱われていることを確認するか、明示的に対象外として記録します。 security · multi-tenancy / isolation · data migration · rollback / reversibility · observability / operability · cost / quota いずれの観点にも含まれておらず、意図的に対象外にもされていない懸念事項は、見落としになります。対象範囲に含まれないものは、決定記録に網羅性マップ（懸念事項 → 観点または out-of-scope: reason）として記載します。これは、L5 の「対象範囲で網羅されていないものは何か？」に相当する生成時の確認です。

1. 多様な候補を並行して生成する（ファンアウト）

エコシステム内で一貫性を保つため、../work-tournament/SKILL.md の仕組みに倣い、N 個の候補エージェントを1つのメッセージで起動します（サブエージェントの並列呼び出し）。

• サブエージェントの役割：汎用の役割を使用します（ファイルへの書き込みを伴わない純粋な設計の場合は、計画専用の役割を使用します）。
• 分離：候補がコードを書き込む、または実行する場合（使い捨てのプロトタイプやスパイク）に限り、分離されたワークツリーを使用します。純粋な設計提案は読み取り専用のため、ワークツリーは不要です。
• バックグラウンドで実行します。
• 説明："Candidate "（中立的な ID — ブラインド化を参照）。
• プロンプト：問題、割り当てられた観点、候補者との契約を含めます。

  "あなたは、<angle> の視点から提案する、独立した <N> 個の提案のうちの候補 <id> です。この観点から、完全で自己完結した提案を1つ作成してください。主なトレードオフ、意図的に優先度を下げた事項、具体的な次のステップ／擬似コード／データ構造、およびテスト／型チェック／プロトタイプで検証できる前提を含めてください。以下の候補 JSON オブジェクトのみを返してください。"

デフォルトの観点（未指定の場合）：MVP-first、risk-first / safety、user-first、performance / scalability、maintainability / simplicity。L5 の網羅性マップと照合します。focus="security and multi-tenancy" の場合は、それぞれの観点が扱われるようにします。

同時実行数の上限（workflow-mode §3）： min(16, cores−2) 件ずつのウェーブで起動し、超過分はキューに入れます。観点を無断で省略して上限に合わせてはいけません。Budget を参照してください。

すべての候補エージェントの完了を待ってから、各結果を収集します。

2. 判定（バリア #1 — すべての候補が必要）

すべての候補が揃い、null を除外したら、判定エージェントを起動して全候補を対象に判定させます。判定エージェントはブラインド化し（ブラインド化を参照）、以下の強化版判定者契約に従います。Judge Verdict JSON を返します。

3. 統合（バリア #2 — すべての判定結果が必要）

メインエージェント（または専任の統合担当）が、辞書式ルール（以下を参照）に従って判定結果を集約し、最も優れた候補をベースとして選び、他の候補の中から最良の統合可能なアイデア／緩和策／簡略化を取り込みます。出力：統合提案＋スコア表＋取り込んだアイデアの一覧＋残るリスク＋推奨する直接検証手順。

4. 直接検証を優先（L1、再度、フェイルクローズ）

候補が提示した前提のうち、決定的に確認できるものはすべて、推奨案を確定する前に検証します。未検証の前提はすべて openQuestions に記載し、確認せずに真と仮定してはいけません。

---

強化された判定者契約（L2、L6、L8を運用可能にする）

候補者の自己申告に基づいて採点する判定者には価値がありません。各判定者は必ず次を実行してください。

1. ソースを独自に再確認する（L2）。 候補者が実現可能性／リスクの根拠として挙げた file:line、テスト名、コマンド、ドキュメントについて、現在のソースから再読するか、再実行してください。 自己申告は一切信用しないでください。再読した内容を reReadSources に正確に記録し、実際に作業を行ったかどうかを workDone に記録してください。
2. すべてのスコアを、検証済みの影響に基づかせる（L6 — 双方向）。 判定者が確認していない主張を根拠にしたスコアは認められません。次の両方の誤りを防いでください。実現可能性を検証できなかった提案を高く評価せず、実際にリスクを追跡していない提案を退けないでください。各スコアには evidence の行（file:line／コマンド出力／「判定の基準がないため未検証」）を付けてください。
3. 作業を行った判定だけが有効です（L8）。 workDone:false または reReadSources が空の判定は投票ではなく棄権です。除外して記録し、残る根拠に裏付けられた判定を使って候補者を評価してください（該当するものがなければ未判定とします）。根拠が十分な判定1件は、自信があるように見えても根拠のない判定2件を上回ります（L8に基づく、根拠に応じた重み付け）。

これは anti-error-lessons §"the case" のバグを生成的に反映したものです。単発の判定者は、経路を1つ読んだだけで、実際の分離に関するバグを「解決済み」としました。ここで、対象となるストレージハンドラーを再読せずに候補者を「リスク：9、安全」と評価する判定者も同じ誤りを犯しています。workDone:true になるまでは、その判定は棄権です。

採点基準（1～10の評価帯、検証済みの影響に基づく — L6）

各項目は、判定者間でスコアを比較できるよう、同じ調整済み評価帯で採点します。

評価帯	意味（必ず根拠に基づき、推測に基づかないこと）
9–10	強いと検証済み：判定の基準／再読したソース／プロトタイプで確認済み。この項目に未解決のリスクはありません。
6–8	妥当で、一部検証済みです。未検証の前提は軽微で、すべて明示されています。
3–5	妥当ではあるものの、未検証です。判定の基準を利用または実行できなかったため、暫定評価として扱ってください。
1–2	弱いと検証済み：再読した内容または判定の基準によって、この項目に関する具体的な失敗／阻害要因が示されています。

禁止事項：判定者が検証できなかった項目に 9–10 を付けること（これは「未検証」を示す 3–5 に該当します）、また実際に追跡していない項目に 1–2 を付けること。L6を反映し、推測に基づく不確実性には決して high を付けず、確認済みの事柄を決して low と評価しないでください。

集約ルール（辞書順 — 勝者を決定論的に選定）

6つの項目は、曖昧な平均値ではなく、辞書順で比較して勝者を決めてください（平均値では、保守性の優位が正確性の失敗を覆い隠す可能性があります）。

1. 正確性／実現可能性 — 根拠に裏付けられた判定者の最小値が最も高い候補。機能しない候補は、どれだけ洗練されていても負けます。
2. リスク／安全性 — 実現可能性で同点の候補の中から、検証済みリスクが最も低い候補を選びます。
3. プロジェクトルール（AGENTS.md／制約）との整合性 — リスクの次に使うタイブレーカーです。
4. 次に、残りのタイブレーカーとして userValue、performance、maintainability を使います。

すべての段階を経ても同点の場合は、統合時の取り込みやすさで決定します（より取り込みやすい候補をベースにします）。勝者を決定した段階を記録し、判断を監査できるようにしてください。

ブラインド評価（L7を運用可能にする — 実施しなかった場合は記録）

判定者は、どの観点からどの候補が生まれたのかを知らずに採点します。「リスク優先」というラベルによってリスクスコアが事前に偏るのを防ぐためです。

• 評価を始める前に、各候補から angle フィールドと、観点を特定できる表現を削除し、中立的なID（A、B、C、…）を割り当ててください。IDと観点の対応表は、メインエージェント内だけに保持します。
• ブラインド評価が実施できない場合（例：提案文にその提案自身の観点が分かちがたく記載されている場合）は、判断記録と、ハーネスのtodo／planツールに 「blinding skipped: 」 と記録してください（L7 — 暗黙の上限適用は禁止）。ブラインド評価を省略すること自体は問題ありませんが、黙って省略することは認められません。

---

構造化 I/O 契約（必須）

すべての候補と判定者は、これらのスキーマに適合する フェンス付きの ```json ブロックを返します。 メインエージェントは、エージェントを失敗とみなす前に、形式を検証し、不正な出力の場合は一度だけ再リクエストします（workflow-mode §4）。列挙値は固定です。自由形式の文字列では、キャリブレーションが損なわれます（L6）。

候補オブジェクト（各生成エージェントが返すもの）：

{
  "id": "A",
  "angle": "risk-first",
  "proposal": {
    "summary": "one-paragraph thesis",
    "keyChanges": ["concrete change 1", "concrete change 2"],
    "tradeoffs": ["what this costs"],
    "deprioritized": ["what this angle deliberately skips"],
    "concreteNextSteps": ["step or pseudocode the reader can act on"]
  },
  "risks": ["named risk + why"],
  "assumptions": ["assumption that a test/type-check/prototype could verify"],
  "verifiableClaims": ["claim X — oracle: run `test <module>` / read the auth middleware"]
}

判定者の評価オブジェクト（各判定者が返すもの。candidateId は BLIND id です）：

{
  "candidateId": "A",
  "scores": {
    "feasibility": 7, "risk": 4, "userValue": 6,
    "performance": 5, "maintainability": 8, "alignment": 9
  },
  "scoreEvidence": {
    "feasibility": "re-ran the type checker clean",
    "risk": "the upload handler — storage tenant from ?hostname, unverified mitigation"
  },
  "strengths": ["..."],
  "weaknesses": ["..."],
  "graftableIdeas": ["specific idea worth stealing into the winner"],
  "overallRecommendation": "strong",
  "directVerificationIdeas": ["oracle the synthesizer should run before committing"],
  "reReadSources": ["src/.../upload-handler:171"],
  "workDone": true
}

列挙値：

• scores.*：整数の 1～10。上記の評価基準の段階に合わせて調整します。
• overallRecommendation："strong" | "acceptable" | "weak"。
• workDone：boolean — false の場合、評価は棄権となり、除外され、記録されます（L8）。

統合出力（スキルの最終成果物）：統合された提案 + スコア表全体（勝者だけではなく、生のスコアも提示）+ アイデアの組み込みリスト（それぞれに出典候補を明記）+ winnerDecidedAtTier + openQuestions[] + 推奨される直接検証 + loggedCaps[]（該当する場合）。

---

適用される実行メカニズム

これらにより、このパターンの信頼性が高まります（全表：workflow-mode §3）。このパネルに適用する場合：

• null の処理と再計算（workflow-mode §3）。 停止・エラー・空の候補または判定者は、.filter(Boolean) で除外し、決してカウントしません。除外後は、残った候補を基に下限数を再計算し、脱落を記録します：「候補 C が停止 → 生存 2 件、下限 ≥2 を満たす」または「候補 C が停止 → 生存 1 件 → トーナメント中止（候補の最小下限を満たさない）」。停止した判定者を低いスコアとして扱ってはいけません。停止した候補を「この観点は敗れた」と扱ってはいけません。
• 同時実行数の上限。 min(16, cores−2) 件ずつ実行し、超過分はキューに入れます。
• 予算 — ローカルで明示し、決して黙って変更しない（L7）。 予算が少なくなったら、優先度が最も低い観点（L5 マップ内で、その懸念がすでに別の観点でカバーされているもの）を除外して N を減らすか、判定者の数を減らして処理を終了します。そのうえで、名前付きの行を記録します： "budget: dropped angle 'performance' (covered by 'scalability'); N 5→4"。パネルを黙って縮小してはいけません。削減後は下限数を再導出します（候補が ≥2 件、各候補につき根拠を示す判定者が ≥1 件必要です）。
• ワークツリーの分離。 コードを記述・実行する候補（プロトタイプ）のみ、isolation:"worktree" を指定します。設計のみのファンアウトは読み取り専用のため、不要です。
• ジャーナリング／再開（workflow-mode §3）。 長時間の実行では、エージェントのデータディレクトリ内に quality-journals/<task-id>.json を書き込みます： { phasesDone[], anglesUsed[], blindMap, survivors[], abstentions[], droppedDueToCaps[], winnerDecidedAtTier }。 再開時は、これを読み込み、anglesUsed[] の観点を再度起動したり、survivors[] に含まれる候補を再評価したりしないでください。また、予算の都合で除外された観点が黙って「カバー済み」とされないよう、droppedDueToCaps[] を保持します。
• 上限を黙って適用しない（L7）。 実行しなかった観点、スキップした判定者、優先度を下げた評価項目、スキップしたブラインド化はすべて、決定記録に名前付きの行として記載し、ハーネスの todo/plan ツールを通じて提示します。読者が「十分に検討した」のか「途中で打ち切った」のかを判断できる必要があります。
• 記録／フェーズ。 ライブプランを可視化し、人間が割り込めるように、上記のフェーズ名をハーネスの todo/plan ツールで出力します。

---

実例（簡潔版）

/work-judge 3 angles="MVP-first,risk-first,scalability" focus="multi-tenancy" "How to add real-time notifications to a multi-tenant app's kanban board"

1. L1 ゲート — 「どのリアルタイム通信方式を使うか」を決めるテスト／オラクルがないため、続行します（記録済み）。
2. アングルの網羅性（L5） — 対応付け：セキュリティ→risk-first、マルチテナンシー→risk-first、 移行→out-of-scope: greenfield feature (logged)、ロールバック→MVP-first（フィーチャーフラグ）、 オブザーバビリティ→scalability、コスト→scalability。見落としはありません。
3. 生成 — サブエージェント3つ、役割は計画のみ、ワークツリーなし（設計のみ）、 匿名IDはA/B/C、アングルは除外。1つ（scalability）が不正なJSONを返したため、1回再要求 → 正常なJSONを取得しました。
4. バリア #1／判定 — 判定エージェントがアップロードハンドラーとテナンシー設計記録を再確認します（L2）。Bの 判定エージェントはworkDone:falseを返したため、棄権として除外し、記録しました。Bには証拠に基づく判定が1つ残っているため、 除外せずに判定対象とします。
5. 集約（辞書順） — AとCは実現可能性（8点）で同点ですが、Cの検証済み テナンシーリスクのほうが低いため（再確認でテナントごとのチャンネルを確認）、リスクの階層でCが勝ちます（記録済み）。
6. バリア #2／統合 — ベースはC、AのフィーチャーフラグによるロールバックとBの バックプレッシャーに関する注記を取り込みます。openQuestions：「チャンネル認証が?hostnameではなくセッションに紐付いていることを確認」 → ../work-refute/SKILL.mdで検証します。

---

他のパターンとの連携

• 多くの場合、Understandフェーズ（../work-sweep/SKILL.mdまたは調査）の後に続きます。
• 統合された勝案は、最終提案を徹底的にレビューするための自然な入力となります。 ../work-refute/SKILL.mdを使って、提案のopenQuestionsを解消してください。
• ../work-gaps/SKILL.mdは統合の後に実行します： 「パネル全体が見落とした重要なアングルやリスクは何か？」— L5の網羅性マップを入力として使います。
• 提案ではなく、すでに構築済みの実装から選ぶ場合は、 ../work-tournament/SKILL.mdを使ってください。

このパターンは、明確な正解が1つもない設計上の判断への確信度を高めます。 また、L1ゲートにより、低コストのオラクルがすでに答えを持っている場合は実行を拒否します。