assign-briefing-evaluator

Runtime root contract

実行場所は execution-contract.md の「1. どちらのホストでも同じ呼び方」を正本とし、要点は次のとおり。

• runtime_root_policy: host-skill-path を適用する。
• Claude Codeでは CLAUDE_PLUGIN_ROOT をplugin rootとして使用する。
• Codexではホストが提示したこの SKILL.md のabsolute pathから、plugin manifestを持つ祖先を上方探索して論理 PLUGIN_ROOT を解決する。
• cwd からplugin rootを推測せず、literal placeholderをshellへ渡さない。各shell invocation内で解決済みabsolute pathを PLUGIN_ROOT に設定する。
• prompts/ 配下はこのowner Skill契約を継承する。

Purpose & Output Contract

確認点で利用者が light / standard / detailed を選んだときだけ、run-briefing から呼ばれる。 資料を作った文脈とは別の文脈 (briefing-reviewer) に、正確さ・言葉・見た目・シンプルさを確かめさせ、指摘を返す。資料は編集しない。

受け取るもの

引数	値	見る対象
--stage	requirements	要件定義.md (と ヒアリング.md)
	spec	仕様書.md (と 要件定義.md)
	pages	briefing.json の pages (と 仕様書.md)
	boards	_src/NN_*.html と NN_*.png
--depth	light / standard / detailed	下の「深さ」
--dir	資料フォルダ
--materials	素材フォルダ	正確さの突き合わせ先

boards は確認点ではない。確認点3 で light 以上が選ばれていたとき、run-briefing が工程5 のあとに同じ深さで呼ぶ。

深さ

深さ	見る観点	素材との突き合わせ
light	決定論検査の結果 + 下の表の観点 1 つ	見出しと表の先頭だけ
standard	正確さ・言葉・見た目・シンプルさ の 4 つ	名前・数字・列名を抜き取りで
detailed	4 つ全部	表の全行を素材と 1 つずつ

stage	light で見る観点
requirements	シンプルさ
spec	正確さ
pages	シンプルさ
boards	見た目

返すもの

briefing-reviewer が返す指摘 JSON 1 個。

• 形は briefing-reviewer.md の「Layer 7: UI / 提示層」を読む。
• 重さ (severity) の決め方は quality-rules.md の「重さの決め方 (独立レビュー)」を読む。
• 保存は呼び出し元がする (_check/review-<stage>.json)。このスキルはファイルを書かない。

手順

1. 決定論検査を通す。結果の数だけを控える。

node "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/validate-briefing-docs.mjs" --dir "<資料フォルダ>" --stage <stage>

stage が boards のときは --stage all を通す (--stage all が足すのはボード HTML の有無と言い換えの検査だけで、まとめ HTML は見ない)。続けて見た目の検査を PNG を作り直さずに通す。

node "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/render-board-png.mjs" --dir "<資料フォルダ>" --check-only --allow-warn

validate の exit 3 は execution-contract.md の「3. 終了コード」のとおり呼び出し元へ伝えて止まる。render の exit 3 (validate を通ったあとなのでブラウザが無いとき) だけは正本と違い、render_exit: 3 として見た目の観点を PNG の目視だけで進める。

2. briefing-reviewer に次だけを渡す: stage、depth、資料フォルダ、素材フォルダ、手順 1 の終了コードと _check/docs.json の場所、light のときの観点。 boards のときは、--check-only の stdout の JSON (ボードごとの errors と warnings と notices) も「render の結果:」の行で渡す。--check-only は _check/boards.json を書かないので、そのファイルは 工程5 の本番の render の結果で、直したあとには古いことがある。
3. 返ってきた JSON の形を確かめる (schema、findings の 4 項目 severity / 場所 / 理由 / 直し方、summary と findings の数の一致、verdict が high か medium があれば fix で無ければ ok)。形が崩れていたら 1 回だけ形の直しを頼む。中身は変えない。2 回目も崩れていたら JSON を直さずに、形の誤りの一覧を添えて呼び出し元へ返す (run-briefing は利用者に相談する)。
4. JSON をそのまま呼び出し元へ返す。

Key Rules

• 独立を保つため、作り手の意図、前の指摘、何回目か、利用者とのやりとりは渡さない。
• 資料 (文書、ボード、briefing.json) を編集しない。検査スクリプトが _check/ に書く結果だけは上書きされる。
• 指摘の数を減らしたり重さを変えたりしない。並べ替えもしない。
• 素材や資料を、公開リンクを作るサービスや、関係のない外部のサービスへ上げない (execution-contract.md の「5. 守ること」)。

Gotchas

• render の exit 3 で止まらずに進めるのは、このスキルだけの例外 (手順 1)。
• 素材に Excel しか無く CSV が無いときは、正確さの突き合わせができなかった範囲を finding (low) として返す。
• detailed は素材が多いと長くかかる。

Additional Resources

• briefing-reviewer.md: 観点ごとの見方と出力の決まり
• quality-rules.md: 4 観点の基準と重さの決め方
• plain-language.md: 言葉の観点の基準