Origin Output Eval

origin-output-eval — 合格まで回す評価ループ（共通層）

この skill は評価の共通層である。何を評価するか（ルーブリック・ペルソナ・合格ライン）は 呼び出し側がプロンプトで上乗せし、この skill はシーンが変わっても変わらない部分だけを持つ: 方式の選択・独立性・ループの器・トリアージ・機械判定・最終報告の契約。 spec: biz_ops SPEC-eval-loop-shared-protocol（2026-09-06 承認）。

参照ファイル

手順（要約 — 詳細は protocol.md）

0. 前提条件を確認: 対象に決定論ゲートがあるなら緑であること。呼び出し側がどのゲートを通したかを宣言する。
1. 方式を選ぶ: A テスト → B レビュー skill → C 審査員。A で判定できるものは A、A にできない残りで
   B が使えるものは B、それでも残る主観品質だけ C。選択と非選択の理由を記録する。
2. 評価計画は ws の Authorization Envelope に事前に書かれている（references/eval-plan.template.md）。
   単発利用ではこの skill を呼んだ指示自体が計画にあたる。
3. ループ（無人・有界）: 評価者を毎巡フレッシュに立てる → 出力を固定スキーマで受ける →
   scripts/judge_round.py で合否を機械判定 → 不合格なら指摘を A/B/C に分け、A/B を呼び出し側へ返す →
   呼び出し側が直す → scripts/eval_state.py で収束と上限を判定 → 再評価。
4. 終了: 合格 / 上限到達 / 未収束 のいずれでも最終報告を書く（references/final-report.template.md）。
   C 分類（正典変更に及ぶ指摘）は保留リストとして最終報告に載せる。

この skill が守ること（共通層・8項目）

1. 選択と順序 — 決定論で判定できるものは決定論で。残りだけ非決定論へ。両方あるなら決定論が先。
2. 独立性 — 作った本人に採点させない。再評価は毎巡フレッシュ（過去版・過去評価の文脈を与えない）。
3. 計画は事前に — 評価者数・回数・入力サイズの概算は Envelope に書いて事前に済ませる。ループの中で 計画を問い直さない。
4. ループの器 — 回数上限・収束ガード（blocking_count で比較。方式集合が変われば比較しない）・ 早期終了・変更分のみ再評価。状態は eval_state.py が持つ。
5. トリアージ — 指摘をそのまま反映しない。A（成果物のミス）/B（表記）はループ内、C（正典変更）は保留。
6. 非代理 — この skill の合格は人間確定の代わりにならない。最終報告の後に人間ゲートが1つある。
7. 出力の固定 — 評価者に自由記述レポートをさせない。output-schema.json の形で受け、機械で数える。
8. 報告契約 — 実行した方式と理由・実行しなかった方式と理由・C 保留・評価者の起動条件を必ず報告する。

やってはいけないこと

• 合否・収束を LLM が数えて宣言する（必ず run_round.sh の exit code と verdict.json を判定源にする。 件数は機械が数え、収束は blocking_count で判定する。手書きの verdict は exit 2 で拒否される）
• provenance.json を書かずに判定を走らせる（評価者の申告が無い round は判定できない。 申告と実ファイルが食い違う・fresh: false・読者にサイド情報を渡した・キャッシュ未クリアも exit 2）
• 1巡を手で組む（run_round.sh を使う。判定を2箇所で再計算するとズレる）
• ループの途中で人間へ戻る（人間ゲートはループの外に1つ。SPEC-eval-loop-shared-protocol 決定3）
• 作った本人に採点させる。単発利用でも審査員は別 subagentとして立てる
• 読者評価にサイド情報（設計意図・仕様書・過去版）を渡す。画像段階は画像のみ
• 生の道具（テスト・レビュー skill・審査員）を勝手に混ぜて手順を飛ばす — 方式の選択理由を書かずに回さない