consensus-summary-html

合意サマリー HTML

モデルを選ぶ前に、ブランチを選択します。割り当てられた役割で、ビジュアル成果物を組み立て、検証し、確認します。このスキルはワーカーをディスパッチしません。

読者が1分以内に評議会の結果を理解し、その後、生のトランスクリプトを開かずに証拠を確認できる HTML ページを1つ作成します。

成果の軸

• 結果： インライン CSS と JavaScript を含む、自己完結型の .html ファイル1つです。
• 次の利用者： 推奨事項を採用するか、異議を唱えるか、次のワークフロー手順に引き継ぐ必要がある人です。
• 完了条件： 出力が存在し、同梱のバリデーターが終了コード 0 で終了し、表示されるすべての主張に出典または明示的な証拠の不足が示され、ページにテンプレートトークンが含まれていないことです。
• 意図： 意思決定サーフェスを構築します。意思決定サーフェスは、まず結果を示し、次に読者が主張から証拠、意見の相違、確信度、アクションへと掘り下げられるようにします。

作業を説明するときは、キーワード「意思決定サーフェスは結果を先頭に示し、未解決の証拠を見える状態に保ちます。」を使います。結果を先頭に示すことを、後半の要約ではなく、最初のレイアウトルールにします。

入力契約

完了済みの models-consensus 結果を使用します。別の評議会を実行したり、評議会の決定を修正したりしないでください。

1. 保存された report_path の Markdown ファイルを、主要な説明資料として使用します。
2. 存在する場合は、保存された state_path の JSON ファイルを使用します。ステータス、モード、ラウンド、シートの忠実性、有効なプロバイダーとモデル、独立性の計算、確信度の値が記録されています。
3. 結果がインラインの場合は、提供されたレポートと状態のセクションを使用します。フィールドが欠けている場合は Not reported と表示し、証拠の不足を明記します。
4. 必須カテゴリの不足を補う場合に限り、生のラウンド出力ファイルを読みます。デフォルトではトランスクリプト全体を読み込まないでください。
5. 成果物のモード、レポートの形式、または状態キーが不明な場合は、正規化の前に、このスキルのディレクトリにある references/input-contract.md を読みます。

装飾より証拠を優先します。欠落したシート、不正な形式の出力、タイムアウト、プロバイダーの共有、未解決の相違は、見える状態に保つ必要があります。シートの忠実性に従います。結果に有効なプロバイダーまたはモデルが記録されている場合に限り、シート名を示します。要求された名前や自己申告からモデルを推測してはいけません。

ワークフロー

1. 結果を見つけて固定する

結果オブジェクト、またはユーザーが提供したコンテキストから、レポートと状態のパスを見つけます。セッション ID、質問、ステータス、モード、成果物のモード、レポートの日付を記録します。ステータスが complete でない場合は、ページに「部分的」「失敗」「人間の入力待ち」「キャンセル済み」または「上限到達」と表示します。部分的な結果を最終決定として提示しないでください。

2. エビデンスを正規化する

HTML を作成する前に、簡潔な内部マップを作成します。出典が失われないよう、各項目にソースパスを添えてください。

• 質問とステータス： タスク、現在のステータス、モード、ラウンド数、およびモードの切り替え。
• 判定： まず平易な言葉で示します。採用に関する質問では、Adopt、Trial、Hold、Reject、Not our problem のうち、グレードを正確に1つだけ含め、そのグレードを平易な説明に添えます。それ以外の質問形式では、グレードを独自に作らず、直接的な推奨を示します。
• 合意事項： 評議会が支持した3〜6項目。最も強いエビデンスを先に示します。
• 意見の相違： 重要な意見の相違ごとに、主な立場と、その解決状況または未解決の状態を示します。フラグを立て、上書きしないでください。多数派の人数が多いという理由で、少数派の見解を隠してはいけません。
• 盲点とエビデンスの不足： 評議会が確認できなかった事実、不足しているコンテキスト、形式に不備のある議席、および実行上の制限。
• 確信度： 回答への確信度と多様性への確信度を、それぞれ別の値として示します。各段階の理由を添えてください。一方を他方に置き換えてはいけません。
• 議席とラウンド： 選択された議席、省略された議席、利用不可の議席、重複した議席。記録されている場合は、実効プロバイダーとモデルも示します。ラウンドの結果と収束状況も記載します。
• 次のステップ： 具体的なアクションを1つだけ示します。評議会から複数のアクションが提示された場合は、最も効果の高いものを選び、残りはフォローアップの注記に記載します。

圧縮より選択を優先してください。エビデンス、留保、異論ではなく、繰り返しの説明を削除します。

3. 意思決定サーフェスを組み立てる

このスキルのディレクトリにある assets/template.html を、合意した出力先にコピーします。マークされたすべてのスロットを置き換え、すべてのプレースホルダーを削除します。

report_path が保存されている場合は、既定で <report directory>/<session_id>-summary.html を使用します。レポートパスがない場合は、docs/consensus/<slug>-summary.html を使用します。その成果物を更新する明示的な依頼があれば、対象範囲内での編集が許可されます。既存の出力先が置き換え対象として選択されていない場合は、新しいパスを使用するか、どの成果物を更新するか確認します。無関係な内容は保持してください。

次のセクション順を使用し、id は変更しないでください。

1. overview：質問、ステータス、モード、セッション、および1段落の要約。
2. verdict：平易な言葉での推奨事項。質問が採用に関するものである場合に限り、採用グレードも記載します。
3. agreements：評議会全体で一致している点。
4. divergences：解決済みおよび未解決の意見の相違と、可能な場合は解決理由。
5. evidence：ラウンドの時系列、席の表、有効なモデルの記録、ソースパス。
6. confidence：回答への確信度と多様性への確信度を分けて記載します。ソースに値が含まれていない場合は Not reported と表示します。
7. next-step：ソースに担当者または対象が示されている場合は、それを含めたアクションを1つ記載します。
8. limits：不足している証拠、省略された席、未解決の質問、実行上の制約。

ページは次の3段階で機能する必要があります。

• ひと目で把握： ヒーロー領域に質問、ステータス、判定、次のステップを表示します。
• ざっと確認： カードとラウンドの時系列で、合意点、意見の相違、席、確信度を示します。
• 詳細を確認： 展開可能な詳細で、ソースパス、解決に関する注記、簡潔なラウンドの証拠を示します。

視覚表現のルール。まず shared/references/html-page-conventions.md を読みます。自己完結性、3段階の情報設計、テキストと色によるステータス表示、エスケープ処理は、同ファイルの規定に従います。以下のルールは、意思決定サーフェスに固有のものです。

• 最初に表示される画面は要点に絞ります。肯定的な合意、注意、未解決の意見の相違には、それぞれ高コントラストの暗色レイアウトと異なるアクセントカラーを使います。
• ソースに存在する値に限り、バーまたはリングを使用します。評議会が報告していない精度を、視覚表現で示してはなりません。
• カードは簡潔にします。長いテキストは <details> パネルに入れます。生のトランスクリプトを貼り付けないでください。
• report.md、state.json、round-2-digest.md など、すべてのソースラベルを読みやすく保ちます。出力ディレクトリから有効な場合に限り、相対リンクを使用します。

言語はユーザーの依頼に従います。英語の場合は、ASD-STE100の簡略テクニカル英語を使用します。ポルトガル語の場合は、平易なブラジルポルトガル語を使用します。証拠として使われている名前、パス、列挙値、評議会からの引用文は変更しないでください。

4. 成果物を検証する

組み立て後にバリデーターを実行します。同じシェル呼び出し内で、SKILL.md を含むディレクトリの絶対パスを SKILL_DIR に設定してください。

SKILL_DIR="<absolute path of this skill directory>"; python3 "$SKILL_DIR/scripts/validate_consensus_summary.py" <output-file.html>

報告されたエラーをすべて修正します。バリデーターは、必須セクションの id、個別の確信度フィールド、席の表、次のステップが1つだけであること、ローカルで自己完結していること、テンプレートのトークンが残っていないことを確認します。

ブラウザーが利用できる場合は、共有規約に記載された検証手順（デスクトップ幅と狭い画面幅、展開操作、すべてのナビゲーションリンクが実在するセクションに到達すること）を実行し、さらに未解決の意見の相違が最初の画面で見えることを確認します。ブラウザーを利用できない場合は、機械的なチェックに合格したものの、視覚的な確認はできなかったと報告します。

5. 納品する

まず絶対出力パスを返します。続けて、評議会のステータス、判定、次のステップ、検証コマンドと結果、視覚的に確認できなかった点を報告します。評議会のステータスが complete でない場合、ページが完成版であると主張してはなりません。

出力仕様

出力は自己完結型の HTML ファイル 1 つです。以下を含める必要があります。

• 保存済みレポートの隣に <session_id>-summary.html、またはインライン結果の場合は docs/consensus/ の下に <slug>-summary.html というデフォルトのファイル名パターンを使用すること。

• title、lang、文字セット、ビューポート。

• 表示される質問見出し 1 つとステータスラベル 1 つ。

• 上記のセクション ID 8 つすべて。

• data-role="next-step" を持つ要素がちょうど 1 つ。

• data-role="answer-confidence" と data-role="diversity-confidence"。それぞれに値または Not reported を指定すること。

• 1 行以上の座席テーブル。座席データが報告されていないことだけを示す行であっても、必ず含めること。

• ソースラベルを 1 つ以上含め、ソースの詳細が欠けている場合は、証拠の不足を明示すること。

• <!-- SLOT コメント、{{...}} トークン、TODO、Replace with テキスト、外部スクリプトまたはスタイルシートへの依存関係を含めないこと。

これは受け入れ仕様です。バリデーターが 0 で終了し、ページがサーバーなしでローカルファイルとして開き、最初の画面に判定が表示され、読者がページ内ナビゲーションから合意点、相違点、証拠、信頼度、次のステップ、制限事項の各セクションに移動できる必要があります。

注意点

• 合意していることは、独立性の証明にはなりません。共有プロバイダーに関する注記や自己ペアリングに関する注記は保持してください。

• 席が 1 つだけの評議会は、複数モデルによるコンセンサスではありません。多様性の信頼度が低下していることを示してください。

• 回答の信頼度が高くても、多様性の信頼度が低いことを補うものではありません。

• 推奨事項があるからといって、未解決の相違点を解決済みのカードに変えないでください。

• 割合、座席名、ソースリンク、解決理由を捏造しないでください。

• 実効モデルの記録として、生のモデルリクエスト名を使用しないでください。

• 不正な形式の座席や利用できない座席を、HTML ページで隠さないでください。観測可能な失敗も結果の一部です。