report-with-html

report-with-html

作成者の実装チェックリストではなく、読者の疑問に沿った情報設計の HTML アーティファクトを作成します。

トリガーの境界

依頼されたアーティファクト自体が、視覚的な HTML レポートまたはインタラクティブな情報ツールである場合に、このスキルを使用します。典型的な出力には、次のものがあります。

• システム、アーキテクチャ、ジャーニー、因果関係、意思決定、比較、ギャップの各ビュー；
• クライアント向けのデータレポートまたは 1 ページ資料；
• データ／アーカイブのブラウザーまたはレビュー用ワークベンチ；
• 明示的に依頼された HTML／ウェブプレゼンテーション。

通常の状況報告、一般的なレビュー、コード差分、課題リスト、Markdown ドキュメントでは使用しないでください。ユーザーが結果を視覚的な HTML アーティファクトにするよう明示的に依頼していない限り、これらのタスクはチャットで報告できます。

デフォルトでは、検証済みの HTML をブラウザーで開いて納品します。PNG は QA 用のアーティファクトであり、ユーザーが画像を求めた場合にのみ納品します。編集可能な PowerPoint が必要な場合は、まず HTML を完成させて検証し、その後 deck-creator（Route C）を使用します。

SSOT マップ

可視化の判断は別のスキルが担います。チャートや図形のデザインに取りかかる前に読み込んでください。 data-visualization-discipline:data-visualization-discipline は、コンテンツに適した形式、使用するチャートの種類と要約統計量、セグメントを集約してよいかどうか、使用できるカテゴリ別の色数、ビュー間での色の一貫性、テーブルの規律、アンチパターンの一覧、納品前のセルフチェックのゲートを定めています。このスキルではこれらのルールを繰り返しません。二重に記載すると、内容にずれが生じるためです。このスキルが担うのはレポートページそのものです。レジスターの調整、コンポーネント集、承認済みコーパス、ページの順序、意思決定カードの契約、インタラクションの契約、ブラウザーでの検証です。

• 読者向けの原則、コンテンツの範囲、意思決定カードの契約、アクセシビリティ： references/design-principles.md
• レイアウトの密度（キャンバスを隙間なく埋める）、物語のリズムとしてのページ順序、HTML テーブルの詳細仕様、形式 → コンポーネントの実装： references/visualization-patterns.md。 形式をすでに選んでいることは前提ではありません。大半の内容は、何を描くかに関係なくすべてのページに当てはまります。この項目は以前「形式を選んでから →」で始まっており、前提条件のように読めました。2026-08 の納品では、このファイルが「該当コンポーネントを作る場合に参照する実装ガイド」として扱われ、開かれないまま、そのルールを3つ欠いたページが納品されました。後の手順に隠れているゲートが、まだ実行していない手順であってはなりません。
• 承認済みコーパスとレジスターの調整： references/approved-examples.md
• 再利用可能なインタラクションとキーボード操作の契約： references/interaction-components.md
• パラメーターの探索、選択したレコードの詳細確認、復元可能なワークベンチの状態： references/interactive-analysis.md。これらのインタラクションを作成する前に読み込んでください。静的なレポートは通常の手順で進めてください。
• 番号付きのホバー／フォーカス時の出典プレビューと、元コンテンツ向けアダプター： references/citation-source-preview.md（候補／試験運用版。引用にプレビューを使う場合に読み込んでください）。
• 写真、スクリーンショット、説明図：references/visual-evidence.md。 対象物、実物に関する選択、視覚的な欠陥、関係性を目で確認する必要がある場合は、作成前に読み込んでください。画像を選定してからでは遅すぎます。
• 長期運用／生成ページのメンテナンス： references/long-lived-report-maintenance.md
• 新しいコンテキストでのレビュー用ペイロード： references/independent-review-prompt.md
• ウォームペーパーのスターター実装： assets/report-template.html

作成前にこれらを読んでください — 原則、patterns ファイル、最も近い承認済み事例、および data-visualization-discipline です。それ以外は、成果物に実際に含まれるものに応じて読み込みます。

「有効になったものだけ読む」という判断で、上記の必須資料を決めないでください。そのフィルターが対象にするのは、すでに必要だと分かっているものです。そのため、存在を知らない手順を見つけることは構造上できず、しかもスキップにもっともらしい理由を与えてしまいます。これは単に忘れるよりも悪いことです。これらの資料が、どの手順が存在するかを教えてくれます。

プロダクト契約

読者と根拠を最優先する

コンポーネントを選ぶ前に、対象読者、このページで可能にする判断や理解、信頼できる情報源を記録します。このセッション中に最新情報を取得します。すべての数値には、単位、日付または対象期間、追跡可能な情報源が必要です。不明な値は不明のままにします。

画面上の文言には、同じページ内でデータ、仕組み、または一次資料によって目に見える形で裏付けられている場合、事実に基づく要点を含められます。裏付けのない価値判断、スローガン、格言、最上級表現、実証されていない因果関係の主張は削除します。不是.*是 のような grep パターンで見つかるのは、あくまで 候補 です。パターンに該当するだけでは、決して問題にはなりません。design-principles.md §3 のテストに従って候補を一つずつ判断します。その文を削除して、読者がこのページで確認できる事実が失われるのか、それとも意見だけが失われるのかを考えます。前者なら残し、後者なら削除します。

読者が理解できる、完全な表現を使います。内部コード、非公開の略記、説明のないアルゴリズムスコアや略語をページに載せてはいけません。

問いに応じて構成を選ぶ

• 「どのように機能しますか？」→ 一連の流れ、アーキテクチャ、または仕組み。
• 「何を決めるべきですか？」→ 選択肢、トレードオフ、決定に不可欠な不明点、推奨事項。
• 「なぜ起きたのですか？」→ タイムスタンプ付きの因果関係の連鎖と、反証となる証拠。
• 「どちらが優れていますか？」→ 共通の基準に基づく、対象 × 評価基準。
• 「このコレクションを詳しく確認したい」→ 一覧／詳細、検索／フィルター、状態、出所、詳細へのリンク、レビュー結果を返す経路。

実装状況は、この構成に付けるバッジであり、構成そのものではありません。依存関係の不足、未検証の結果、不明点は見える状態に保つ必要があります。

技術選定や購入の比較では、セクションを配置する前に references/visualization-patterns.md の具体的なプランに沿った読み進め方を使います。次に何を調査するかの選択と、購入やデプロイの承認は区別します。

形状と実際の根拠

重要な定量比較には、位置と長さを使います。色はカテゴリや状態を示すために使い、独立した別の指標を表すために使ってはいけません。図形には明示的なエンコーディングの凡例と、データに裏付けられた読み取り結果が必要です。

同じ対象の集合を、装飾的な形式を変えて複数回描き直してはいけません。各セクションでは、それぞれ異なる問いに答える必要があります。UI や視覚的なプロダクトのレビューでは、実際のスクリーンショットを主要な証拠とします。不具合の箇所を周囲の状況が十分わかる範囲で正確に切り抜き、修正前後で同じ範囲を切り抜きます。

統計グラフには、インストール済みの成熟したグラフ作成機能か、現在のプロジェクトで宣言されているグラフ作成スタックを使います。どちらもない場合は、実装前に調査して保守されているライブラリを選定し、グラフエンジンを手作りしてはいけません。

インタラクションとアクセシビリティ

読者のパラメーターや選択内容を引き継ぐ計算ツールや作業用ワークベンチでは、コントロール、状態の復元、会話への復帰を実装する前に、references/interactive-analysis.md を読み込んでください。コンテキストの準備、状態の保存、明示的なメッセージ送信は、それぞれ区別してください。単独のブラウザーでは、手動で引き渡してください。

根拠は読者のもとに届けます。読者が根拠まで移動するのではありません。 ページで条項、スクリーンショット、原文の一節を引用する場合は、引用箇所に埋め込んでください。インプレースのオーバーレイやドロワーを使い、読者が元の位置に戻れるようにします。読者をページ内の別の場所へ飛ばし、そこから自分で戻るよう求めるアンカーは、単に推奨されないのではなく、禁止です。このルールとユーザー自身の言葉は design-principles.md §13 に記載されています。ハッシュアンカーは、ナビゲーションや外部からのディープリンクには引き続き適切です。禁止されているのは、読み進めている途中で強制的に移動させることです。

インタラクションを作り直すのではなく、承認済みのものを assets/components/ からコピーしてください。動作はコンポーネントの契約の一部です。レジストリ固有のスタイルは変更できます。各コンポーネントは、契約全体に従ってコピーしてください。

1. コンポーネントファイルのヘッダーにある契約を読みます。そこには、レジストリの表に記載されていない前提条件（必須の CSS トークン、必須の DOM 構造、スキャン対象となる要素の種類）が記されています。たとえば citation-drawer は <section> 要素内だけをリンク化し、ジェネレーターが生成した #s9 を必要とします。
2. ページでこれらの前提条件を満たします。
3. 納品前に、実際のブラウザーでコンポーネントの主要なインタラクションをクリックして確認してください。 コンポーネントが配置され、ID が一意で、タグの対応も正しくても、完全に動作しないことがあります。静的チェックはすべて通っても、機能が何も起こらない場合があります。この2つの状態を見分けられるのは、クリックして確認することだけです。

すべてのインタラクションは、ポインターなしで操作できなければなりません。

• 使用可能な場合は、ネイティブのボタン、リンク、ダイアログを使用します。
• モーダル画面には視認可能な閉じるコントロールを用意し、Escape キーで閉じられるようにします。
• モーダルが開いている間はフォーカスをその中に維持し、閉じたときは起動元に戻します。
• セマンティック HTML と ARIA を使って、名前、状態、関係性を伝えます。
• 視認可能なフォーカス、論理的なタブ順序、狭い画面でも使いやすいレイアウトを維持します。

ワークフロー

1. 成功の条件を定義します。 対象読者、質問、情報源の集合、必要な根拠、納品形式、成果物が失敗と見なされる条件を記録します。ゲートのテンプレート（ステップ 5）には、常に 读者已知清单 の欄もあります。対象読者を「すべての読者」より狭く設定する場合（見知らぬ人ではなく、内部の事情をすでに知っている読者）は、その読者がすでに知っていると想定する具体的な用語、スクリプト、システムを、検証可能なバッククォート付きの形式で記入します。対象読者が本当に見知らぬ人である場合は、不适用: <why> と記入します。この欄も空欄にはせず、その回答を記入してください。ステップ 9 の最初のレビューより前に記入してください。レビューで指摘が返されてからではいけません。この順序が重要な理由と、ステップ 9 でこのリストをどう使うかについては、references/audience-triage.md を参照してください。 元の依頼、その後の修正、および現在のプロジェクト契約から、実際の読者と想定される用途を特定してください。公開可能なドラフトと、実際の外部公開とを区別してください。その用途に応じて証拠の精度を設定します。非公開の調査では、公的な編集済み版に黙って置き換えるのではなく、追跡可能な元の識別子、パス、ログを保持してください。認可されたプロジェクトの既存の納品ディレクトリまたはドキュメントライブラリに従ってください。スクラッチディレクトリは作業場所です。保存先が定まっていない場合は、可逆的なローカルの既定値を選び、それを明示してください。結果に実質的に影響し、妥当に既定値を適用できない不足入力についてのみ質問してください。調査の場合、完全な可読性と中核的な因果的主張の証明を、別々の受け入れ結果として記録してください。読みやすいレポートであっても、必要な認可された行動によってその主張をなお前進させられる間は調査を完了させません。利用できない過去の証拠は不明のままです。

2. 調整する。 必須の情報源 — design-principles.md、references/visualization-patterns.md、approved-examples.md の最も近い項目、および data-visualization-discipline — を読み、次にその成果物が有効化するコンポーネント参照を読んでください。最も近い承認済みのレジスターを使用してください。外見を盲目的にコピーしないでください。（このステップは以前「有効化されたパターン参照」と書かれていたため、パターンファイルをまだ不要として脇にやり、スキップすることが可能でした。上記の SSOT マップは、そのフィルターがここでは機能しない理由を説明しています。）

3. 視覚的証拠と造量纲を計画する — HTML を一行も書く前に。 まず、具体的な対象、物理的な選択、視覚的欠陥、または関係についてのセクションでは references/visual-evidence.md に従ってください。代表的な画像を関連する選択肢のところに置き、図でつながりを説明してください。利用できない証拠は明示的に特定してください。選択したビジュアルは、2 つ目の目録ではなく、既存のページ意図に記録してください。セクションごとに、コンテンツの中で何が 順序を持つ / 大きさを持つ / 方向を持つ / 対応物を持つのかを挙げ、その量を書き留めてください。それぞれの幾何はそれをマークアップ内で運びます:

   <div data-geometry="退款家数刻度轴"
        data-derived-from="退款家数（0–30 家线性，共同基线；位置=家数÷30）"> … </div>
   

   裏付けのある量や関係がなければ、幾何をでっち上げないでください。 そのコンテンツは散文のままにしてください。検証済みの写真やスクリーンショットは、依然として対象や証拠を示すことができます。文を色付きのボックスで包んでも、それは図にはなりません。

   数値とそれを符号化する座標は、同じスクリプトから出力されます。 何らかの幾何が計算値によって配置されるようになったらすぐに — バーの長さ、left:30.80% の目盛り、軸ラベル、線の端点 — 依存関係のない小さなスクリプトを書いて、発見と座標の両方を出力させ、その出力から貼り付け、そのスクリプトをページの隣に同梱してください。散文で値を計算してから SVG 属性を手書きすることは、grep ではそのずれを捉えられない二重コピーの事実です。同じ量が 2 つのセクションで 2 通りに丸められてしまうのはこのためであり、軸ラベルがより小さな数値の位置に落ち着いてしまうのもこのためです — 嘘係数に反対するまさにそのページが生み出す嘘係数です。スクリプトを同梱すれば、その図面は監査可能にもなります。読者が再実行して差分を取ることができます。ステップ 5 のゲートはそのスクリプトのパスを求め、ファイルを stat するので、このルールにはマシンの消費者が存在し、あなただけが裁定するもう一つの項目にはとどまりません。（それはちょうど 1 つのバージョンの間だけ散文のみであり、独立した監査はそれを次にスキップされそうなルールとして名指ししました — ステップが生き残るかどうかを決める変数は「成果物を生み出すか」ではなく、「その成果物を下流で消費する何かがあるか」です。視覚的規律のゲートは、スキップされた時点ですでに成果物ステップでした。） これが原則ではなく番号付きの手順になっている理由：このルールはすでに design-principles.md §2 と data-visualization-discipline にあり、どちらも 直前に読まれていたにもかかわらず、文章のセクションが8つ、図形が1つだけの成果物が納品されました。 判断の手順で、その唯一の判定者が手順の作成者自身である場合、実行されずに理解されただけになります。 次の2つの属性によって、スクリプトで手順が実行されたかどうかを確認できます。

4. 作成します。 呼び出し元の Skill が、ユーザー承認済みのローカルレポート書式を提供し、それがこのレポートの出力要件を満たす場合は、その書式を出発点として使います。それ以外の場合は、 assets/report-template.html または承認済みのサンプルから始めます。テンプレートの承認と保管は呼び出し元の Skill が担当し、レポートの生成とビジュアル QA はこの Skill が担当します。 顧客に関する事実と結論は現在の証拠に基づくものとし、呼び出し元のテンプレートを、この Skill の更新対象である assets/ にコピーしないでください。実際の棚コンポーネントを使用してください。ページに変更可能なソース文書を埋め込む場合は、長期運用レポートのリファレンスに従い、生成領域と作成者が記述する領域を分けてください。

5. 納品ゲートを実行します — 判定手順を実行しない場合に抜け落ちる成果物が、ここで生成されます。

   uv run <skill-dir>/scripts/delivery_gate.py init  page.html [--height 9600]
   #   → renders page.png AND page--masked.png (all text transparent — the squint test,
   #     headless; see the script header for the technique's provenance)
   #   → scans for ≥120 CSS px whitespace voids (visualization-patterns.md 版面填充纪律)
   #   → writes page.html.gate.md: the delivery gates + the stage-1 questions
   #     (`STAGE1` in delivery_gate.py owns the exact list), every slot empty
   # Read the masked PNG segment by segment, fill every slot, then:
   uv run <skill-dir>/scripts/delivery_gate.py check page.html   # exit 1 until it passes
   

   check は、マスク済みレンダリングが存在しない、または古い場合（証拠なしに遮字自测を主張できないようにするため）、割合に基づくビジュアルに data-geometry／data-derived-from がない場合（造量纲を省略できないようにするため — 純粋なレイアウト用ボックスは data-layout で明示的に対象外にできます）、未入力のスロットがある場合、ゲートファイルがページより古い場合（「チェックリストを埋めてから編集を続けた」状態を通過させないため）に失敗します。これにより、各手順が実行されたことは検証できますが、結論が正しいかどうかについては何も判断しません — それは引き続き手順9と10の役割です。

6. 新しい成果物をレンダリングします。 手順5ですでに、指定した高さで page.png が生成されています。以降にページを変更した場合にのみ、ここで再レンダリングし、同じ高さを指定してください — render_report.sh はその場で上書きするため、H を短くすると、正常なレンダリング結果が切り詰められたものに気づかないまま置き換わります。

   <skill-dir>/scripts/render_report.sh page.html page.png 1300 2400   # H is an example, not a default
   

   <skill-dir> はこの Skill 自身のディレクトリです — Skill の読み込み時に、その絶対パスが渡されます。report-with-html/scripts/… のような単なる相対パスは、特定の親ディレクトリからしか解決できず、それ以外の場所では終了コード127で失敗します。

   新しく有効な PNG が生成されない場合、レンダラーは失敗し、既存の出力を成功とは見なしません。CI または共有ブラウザー環境では、CHROME_BIN に管理対象の Chrome／Chromium 実行ファイルの明示的なパスを設定してください。無効な値を指定すると、即座に失敗します。

   次に分割し、すべてのセグメントを読み取ります — 縦長の PNG は、1回の Read では読み取り可能な範囲を超えます。

   uv run <skill-dir>/scripts/crop_segments.py page.png --segments 5
   

   切り詰めもこの手順で検出します。 Chrome は指定された --window-size ちょうどのサイズでスクリーンショットを撮り、ページに合わせて拡張することはありません。一方、レンダラーの PNG チェックで確認できるのは、バイト列が有効な画像であることだけです — そのため、ページの高さが H を超えると末尾が気づかれないまま失われます。また、design-principles.md の §6 では、最も重要な結論を最後に置いています。スプリッターはコンテンツがキャンバスの最終行まで達している場合に警告します。これは、ページが途中で終わったのではなく、キャンバスがページを途中で切り取ったことを意味します。ここで確認するのは、ページの高さを変更せずに測定する唯一の方法が、2回目の --dump-dom 呼び出しだからです。この方法は一部のページでハングします — 測定できないゲートは、必ず検査を省略してしまいます。 この警告には誤検知が1つあり、明白な対処法はその状況では解決しないため、再レンダリングする前に警告自体の2つの分岐を確認してください。 ページ内で何かを vh でサイズ指定している場合（スクロールパネルの max-height:78vh がよくあるケースです）、ヘッドレス環境では 1vh が H/100 となるため、Hを大きくするとその要素も大きくなり、コンテンツはあらゆるHでキャンバスの下端に張り付いたままになります。Hを明らかに変えて一度レンダリングし、報告されたコンテンツの下端を比較して判別してください。変わっていなければ実際の切り詰めが起きており、今は修正されています。新しいキャンバスの高さとほぼ同じなら、それは vh のループです。Hを倍々に大きくし続けないでください。3000でも40000でも同じ警告が出ると知った担当者は警告を無視するようになり、ノイズに埋もれたゲートは、本来検出するための実際の切り詰めを見逃すようになります。

   実際のデバイスエミュレーションを使って狭い画面のレイアウトもテストし、オーバーフローを測定してください。デバイスエミュレーションは、単なる表現上の選択肢ではありません。ヘッドレス Chrome は --window-size を最小幅約500 CSS pxに制限します（2026-09-17に測定：390を指定しても innerWidth=500 となり、--force-device-scale-factor でもCSSビューポートは狭くなりません）。390クラスのスマートフォン幅には、Playwright/CDP の Emulation.setDeviceMetricsOverride（またはEgo）を使ってください。--window-size=390 で実行したものを、スマートフォン幅のテストとして報告してはいけません。

   比率ゲート用に描画済みバーの幅を測定する場合は、コンテナを基準にしてください（まずトラックのボックスを見つけ、その内側の暗いピクセルを測定します）。コンテンツのピクセルを全体からクラスタリングしてはいけません。エッジのアンチエイリアスで見せかけのクラスタができ、長いバーによってトラックの行自体が隠れることがあります（2026-09-17に実際に発生した2つの失敗）。

7. 一連の操作を実際に試してください。 実際のブラウザーで、クリック項目のリストをなぞるだけでなく、読者の導線に沿って操作します。理解しやすい順序、次に行うべき明確な操作、キーボード操作、モーダルのフォーカス、ディープリンク、フィルター、エラー状態や空の状態をテストしてください。細部・全体・意図のレビューには frontend-visual-qa を使います。組み込んだ棚コンポーネントはすべて、ここで主要なインタラクションをクリックし、確認した内容を記録してください。「ドロワーが開き、条項7が強調表示された」は証拠になりますが、「コンポーネントが存在する」は証拠になりません。画像が実際に読み込まれること、重要な詳細が読みやすいこと、キャプションがビジュアルの隣に表示されること、納品するローカルファイルにアセットの欠落がないことを確認してください。

8. 内容を照合して検証してください。

   マージまたは現行状態の更新では、references/long-lived-report-maintenance.md §6.1 のセマンティック受け入れ基準を適用してください。情報ポイントの対応関係をゲートの証拠とともに保持してください。ソースリンクのインデックスは、求められている統合ではありません。

   • 書き換えまたはマージでは、次を実行します。

     uv run --python 3.12 python <skill-dir>/scripts/reconcile_content_diff.py old.html new.html
     

     Chrome で両方のページを開き、初期状態で計算された読者に表示される テキストを比較します。これはタブやアコーディオン、その他の操作によって 生成される状態を走査するものではありません。それらの状態は Journey／ブラウザ ハーネスでカバーしてください。

   • 生成される長期間存続するページについては、ページジェネレーターを実行してから その --check モードを実行します。アンカーの欠落／重複や古い出力は失敗と みなします。

   • 古くなった事実、省略表記、裏付けのない主張、壊れたファイルパス、重複した バージョン／ステータス値を検索します。

9. 独立した読者レビュー — そして実施したことを示すファイルを残す。 レビュアーは 引き継いだ会話や著者の推論なしで開始しなければなりません。Codex では fork_turns: "none" を使用します。Claude Code では、フォークではない別の general-purpose エージェントを起動し、必要な読者コンテキストをすべてその プロンプトに含めます。そのレビュアーには HTML とそのレンダリング済み スクリーンショットを渡し、それ以外は何も渡しません（以下の表には「ページのみ、 それ以外は何も」とあります。スクリーンショットはページです。テキストのみの レビュアーはソースを読んで視覚的な質問に答えますが、それは実際に目を通した 場合と書き上げた内容では区別がつきません）。references/independent-review-prompt.md をそのまま使用します。読者の理解に関する失敗は欠陥です — ただし例外が一つあり、 以下に示す 读者已知清单 は、狭い対象読者を宣言していないページが主張することは 決してできません。提案された実装変更は仮説として扱い、成果物を変更する前に 再現してください。

   ページを送る前に、レビュアーが実際にブラウザを開けることを確認してください — レビューの質問のいくつかはフォーカス、Escape、キーボード順に関するものであり、 テキストのみのレビュアーはソースを読んで答えることになります。サブエージェントを 起動する前にその能力を内省することはできないため、レビュアー自身の最初の アクションにしてください。ブラウザのステップを試みるよう指示し、できない場合は 出力に「browser unavailable — items 7 and 8 answered from source」と報告する ように伝えてください。印のないソース読み取りの回答は失敗です。印が付いたものは、 別の方法でカバーできる既知のギャップです。その回答は、クリックして生成された ものと書き上げた内容では区別がつかず、まさにこのスキルが警告している盲点に 該当します。すべての静的チェックが通る一方で、機能は何もしていないのです。

   結果をページの隣のファイル（またはレビューアーカイブ内）に書き出します。 レビュアーをどのように起動したか（エージェントの種類、およびフォークで なかったこと）、与えたプロンプト、各指摘とその対応および理由、確認できなかった ことを記録します。起動の詳細を記録するのは、フォークの書き上げた内容が独立した ものとまったく同じように読めるためです — 両者を区別する唯一のものは、どのように 起動されたかという事実であり、それが決して書き残されなければ、上記の独立性の 要件はあなたを含む誰によっても検証できません。ファイル自体が要点です。何も 残さないレビューは、実施しようとして実施しなかったレビューと区別がつかず、 それがこのステップが実際に抱える失敗モードです。著者がこのステップに同意して いないのではありません。納品のプレッシャーの下で、このステップが最も安価に 黙って省略されるものなのです。 「理解できない」という指摘は、カウントする前にすべて 读者已知清单 と照合してください。 ただし、これは暫定的な判定です。ステップ 10 で独立して再判定するため、自己点検ではありません。 レビュアーが前提知識を持たないという設定は意図的なもので、変更しません。しかし、ステップ 1 で確定したリストに載っている用語は見せかけの問題（Sauro、MeasuringU）です。レビュアーがその用語を知らないのは当然ですが、宣言された対象読者は実際には混乱していません。レビュアーの指摘を一字一句そのまま、照合するリスト項目の隣に引用してください。「既知の用語に帰着する」は解釈を伴う主張であり、ファイルの存在確認ではありません。その引用があれば、自分以外の人も、その帰着が誠実なものだったか判断できます。引用と理由を添えて、判定を audience-declared-known として記録してください。この判定は、以下の同一軸再発テストの対象にはなりません。指摘された用語がリストに載っていない場合は、これまでどおり実際の指摘として扱うか、ここでリストに追加します。追加する場合は、元のリストに黙って混ぜ込むのではなく、ゲートファイルの該当項目の隣に 补记于 cycle N 审阅之后 と明記してください。日付をさかのぼらせてはいけません。init --force が保持する「上一轮的答案」付録には、このサイクル開始前のリストがすでに記録されています。そのため、現在のリストと付録を差分比較すれば、黙って追加した項目は簡単に見つかります。誰かが差分を確認することを当てにせず、正直に明記してください。詳しい仕組みと、この確認が最終判定ではなく暫定判定である理由の根拠は、references/audience-triage.md にあります。

   再実施するかどうかの判断は、自己評価ではなく、変更内容の確認に基づきます。 前回の記録されたレビュー以降に、ページの骨格、コンポーネント、意思決定カードの内容、数字、またはレビュアーが解釈しなければならなかった用語やラベルに変更があったか確認してください。1 つでも該当すれば、新しいレビュアーを依頼します。前回とは異なるページを読むことになるためです。用語の変更については、個別に言及する必要があります。これはレビュアーからの「理解できなかった言葉」という指摘に対する標準的な修正で、文言の変更として処理しがちです。しかし、新しい言葉を読んだのはあなた以外にいません。それこそ、このレビューで解消しようとしている状況です。誤字や句読点の修正なら、再実施は不要です。代わりに、完了報告でその旨を伝えてください。変更が「構造的に感じられたかどうか」を自問して判断してはいけません。文面としてレビューされたページが、その後グラフィックとして再構築されたという、記録済みの失敗があります。再構築のたびに、レビュー済みのページを磨き上げているだけだと感じられ、その結果、誰にも読まれていないバージョンが 3 回連続で公開されました。

   このトリガー自体に上限はありません。予算を組み合わせてください。そうしなければ、「実質的な変更はすべてレビューが必要」というルールは、新たなラウンドを際限なく生み出します。 本質的な修正はどれも、定義上、上記のトリガーが新しいレビュアーを必要とする変更です。そのため、1 回のラウンドの中からは、収束するレビューと暴走するレビューを見分けられません。この失敗は、小規模なケース（重要度の低い修正 1 件を終えるのに全 3 ラウンド）と大規模なケース（実際の意思決定文書に対して 21 ラウンド、人間が理由を尋ねて初めて中止）の両方で確認されています。これは claude-code-hooks の SKILL.md ルール 7 にあるループ契約――「フックが修正を要求するなら、ループが終了することを証明する」 （daymade-claude-code/claude-code-hooks/SKILL.md（daymade/claude-code-skills）。一般的なフレームワークと失敗事例については、こちらを参照してください）――を、フックではなくこのステップ向けに具体化したものです。

   LOOP KEY: this delivery's lineage (the HTML frozen at round 1 plus every descendant
             edit) + one failure axis: can a fresh, uninformed reader use this page?
   FIRE T:   after audience triage (above), a review still answers review-prompt item 9
             "no" — or surfaces any finding that amounts to the same thing (the reader
             could not actually make the decision this page exists to produce) — on that
             same axis, using only findings that survived triage
   REMEDIATION R: reproduce the finding, apply one bounded fix, re-run the review once
   VARIANT V: 2 - completed review cycles for this lineage
   BUDGET:   2 cycles total — the initial review plus one narrowly scoped re-review.
             A third reviewer on this lineage is never automatic.
   SUCCESS EXIT: the re-review answers item 9 "yes" on that same axis, with nothing else
             reopening it
   AUDIENCE-MISMATCH EXIT: EVERY SINGLE post-triage reason behind a cycle's "no" disposes as
             audience-declared-known — ship, log the disposition table, do not report this
             to the user as blocked. "Every" means every: a "no" with two reasons, one
             audience-related and one a genuine unrelated defect (a chart missing a unit, a
             broken cross-reference), is not this exit — the unrelated reason alone routes
             through ordinary REMEDIATION/CAPPED EXIT, same as if it had appeared by itself.
             This can fire after cycle 1 alone: if nothing survived triage, there is no
             finding for REMEDIATION to reproduce and fix, so a mandatory cycle 2 would just
             re-review an unchanged page for a second phantom verdict.
             (see `references/audience-triage.md`)
   CAPPED EXIT: at least one post-triage finding is real and recurring across two cycles —
             stop, report the remaining findings as a backlog, do not ship silently, and do
             not dispatch a third reviewer on your own authority
   

   このスキル独自のレビュー出力には、判定に使える重大度の語彙がありません。レビュー プロンプト（references/independent-review-prompt.md）が返すのは回答済みの質問であり、 BLOCKER／MAJOR と評価された指摘ではありません。また、ステップ 10 の受け入れに関する 語彙は PASS／FAIL／CANNOT-CHECK です。そのため、上記の FIRE T と SUCCESS EXIT は、 ルール 7 の例示的な重大度ラベルではなく、レビュー用プロンプトの項目 9 にある「最后一问」 の回答（読者は他に説明がなくてもこのページを読んで行動できるか？）を基準にしています。 ルール 7 の例示的な重大度ラベルは別種のレビューを示すもので、このスキル内の他の箇所には 登場しません。

   同じ軸での再発と、新たな無関係の指摘は、サイクル 2 で異なる扱いをします。 この 2 つを混同すると、上限のあるループが拡大し続けるループに変わってしまいます。まず、上記の オーディエンスによるトリアージを各サイクルの指摘に適用してください。以下はすべて、 トリアージ後に残った指摘についての説明です。サイクル 1 の指摘がすべて、オーディエンスが 既知と判断したものとして処理された場合は、そこで AUDIENCE-MISMATCH EXIT に進んでください。 サイクル 2 で再レビューするものは何もありません。

   • サイクル 2 で、サイクル 1 ですでに指摘されたのと同じ軸に関する理解の問題が再発する （具体的な表現が変わっていても、読者が依然としてページを使えない）→ 指摘がトリアージを 生き残った場合に限り、上記の CAPPED EXIT に進みます。両サイクルの指摘理由がすべて オーディエンスが既知と判断したものとして処理された場合は、代わりに AUDIENCE-MISMATCH EXIT に進みます。公開して、ブロックされたとは報告しないでください。 トリアージ後も実際の指摘が再発した場合は、そこで停止してください。blocked と報告します。 「しかし、この指摘は実際に問題だ」と理由づけて 3 回目のディスパッチを行ってはいけません。 指摘が実際に問題かどうかは、もともと不足していた確認事項ではありません。不足しているのは、 予算があらかじめ定められた、ユーザーが承認する新しいタスクです。それを開始できるのは ユーザーだけです。
   • サイクル 2 で、真に新しく無関係な問題が見つかった場合（サイクル 1 では判断カードの 明確さが問題になり、サイクル 2 でたまたま無関係な色の問題が指摘された場合など）→ 別タスク用の独立したバックログ項目として記録します。その項目は、この系列の予算を消費せず、 それだけを理由にこの系列でサイクル 3 を行う根拠にもなりません。収束したものを公開し、 ユーザーが今すぐ対応を希望する場合は、独自の予算を設定して新しいレビューとしてその項目を 開始してください。 同じ交差は、この系譜がすでに一度ステップ 10 を通過した後にも当てはまります。 正式な受け入れは再開に対して免疫があるわけではなく、それは上記とは別種の失敗です — 途中の個々の指摘がすべて本物であり、かつ新しい軸上にあったとしても、それは再発します（一つの系譜上で三度の通過した受け入れがそれぞれ個別に本物である、というのが記録されている最悪のケースです）。もしステップ 10 がこの系譜に対してすでにクリーンな判定を返しており、それでも何かが別のステップ 9/10 のラウンドを発行しようとしているなら、その交差 — それ自体が、新しい指摘が本物かどうかを判断する前に — が、立ち止まってユーザーに尋ねるべきシグナルであり、黙って再開するべきではありません。

10. 独立した受け入れ。 以下の受け入れチェックリスト、ページとその出典、および元のリクエスト、その後の修正、出力契約、必要な受け入れ基準を、二つ目の 新しいコンテキストのエージェントに渡します — ステップ 9 の読者とは別のエージェントです。というのも、両者は異なる問いに答えるからです（そのリストの下の表を参照してください）。これは項目ごとに判定と証拠を返します。その FAIL は、ステップ 9 のものとまったく同じように、あなたが再現して修正する指摘です。その PASS だけが項目をクローズできる唯一のものです。

11. レビュー後に最終化。 受け入れられた修正を適用し、再レンダリングし、ブラウザーのジャーニーを繰り返し、配信ゲートを再実行します — ゲートファイルを埋めた後にページを編集すると、意図的にそれが無効化されるため、ここで check は赤になり、それが設計であって故障ではありません。init --force を再実行し（前回の回答を付録に引き継ぐので、再入力するのではなくレビューして移動できます）、新しい マスクされたレンダリングを再読し、各回答がまだ成り立つことを確認してから初めてそれを上に移動し、その後もう一度 check します。それからようやく、最終的な HTML をユーザー向けに開きます。レビュー前のドラフトを配信成果物として開かないでください。

新しい教訓がどこに行くべきか — これをこのスキルに書き込む前に、この順序で二つの問い。

第一に、その失敗は 「やるのを忘れた」 でしたか、それとも 「やったが、それが間違っていると見抜けなかった」 でしたか? 前者は上記のワークフローに属します。リマインダーで解決します。後者は、他の 誰かが尋ねる問いにならなければなりません。というのも、著者はそれを飛ばしたのではなく — まっすぐ見て、問題ないと判断したからです。色、用語、あるチャートが自身のキャプションを裏付けているか、ある意思決定カードに選択肢が欠けていないか — これらはすべて後者の種類です。それらを著者が答えるリストに載せることこそが、ルールが書き留められそれでもなお違反されるに至る、まさにその経路です — このスキルが苦労して再学習しなければならなかったあらゆるルールに起こったことです。

次に、それが他の誰かの問いであるなら、ページだけから答えられますか? はい → 読者のプロンプト（references/independent-review-prompt.md）。いいえ → 以下の受け入れリスト。この二つ目の問いが、二つのリストが互いのコピーを増やさないようにするものであり、下の表は同じ境界を反対側から述べています。

配信受け入れ — 独立したエージェントがこのリストを実行し、あなたではありません

読者レビューと受け入れは配信をクローズし、そして それらは重複しません: すべてのチェックはちょうどどちらか一方に属するので、それらが食い違う余地はありません。

	ステップ 9 · 読者レビュー	ステップ 10 · 受け入れ
得るもの	ページとそれだけ（スクリーンショットはページとして数えます）	ページ に加えて 元のリクエストと修正、出力契約と必要な受け入れ、あなたの出典、コマンド、レビューファイル、およびゲート成果物
尋ねる	読めますか? それから判断できますか?	要求された結果を届けていますか、そしてページの外にあるものはページの上にあるものと一致していますか?
その問いが存在する場所	references/independent-review-prompt.md — そのすべてが、逐語的に使用されます	以下の項目
権限	ページ上に見えるすべて	元のタスク要件、来歴およびプロセス
追加項目を両方ではなく一方にまとめるための振り分けルール： その質問に答えるには、ページの外部にある情報が必要ですか？ いいえ → 読者の質問です。レビュー用プロンプトに追加します。はい → ここに追加します。 色、表現、グラフがキャプションだけで内容を伝えられるか、判断カードに選択肢が不足しているか、見出しが論旨を構成しているか——すべてページ上で確認できるので、いずれも読者の担当です。以下のチェック項目には、読者が持っていない情報が必要です。

このリスト、ページ、そのゲート成果物（page.html.gate.md、page--masked.png）、元の依頼と後から加えられた修正（それぞれの出典位置を含む）、既存の出力契約と必須の受け入れ基準、根拠となる重要な事実の出典、実行したコマンド、ステップ9のレビュー用ファイルを、新しいコンテキストのエージェント（フォークではないもの）に渡します。まず自分で確認してもかまいません。明らかな見落としを手早く見つけられます。ただし、項目に合格を宣言することはできません。

なぜ自己チェックではいけないのか、率直に説明します。納品が近づくほど、チェックを省きたいという衝動が最も強くなるからです。以前のこのリストでは、各項目を「指し示せる」ことを作成者に求めていましたが、作成者はいつでも心からそう言えてしまいます。証拠を貼り付けるよう求める形に改めることで、問題の半分は解決しました。証拠そのものは存在するようになったのです。しかし、もう半分は残りました。自分の証拠で十分かどうかを、依然として作成者自身が判断していたからです。これらの項目に関わる失敗は、どれも同じ性質のものでした。作成者には明快に見えたグラフ、検討して承認した色使い、欠けているデメリットに気づかなかった推奨案です。いずれも手順を忘れたわけではありません。この種の誤りにリマインダーは効きません。別の人の目が必要です。

求めるのは、項目番号、PASS／FAIL／CANNOT-CHECK、および具体的な証拠です。引用した行、件数、コマンドの出力などを示します。確認できない項目は、そのように報告し、合格とはしません。

0. 依頼された成果物 — 既存の受け入れエージェントが、必須の各読者の質問または出力について、納品されたページ内の回答と証拠を対応付け、要件とページ内の位置を引用します。回答がない場合や、必須のレポートの代わりにサンプル／プロトタイプを提示した場合は、操作性、レンダリング、ゲートをすべて通過していてもFAILです。サンプルのみを求める依頼は、その範囲に照らして評価します。依頼されていない完全なレポートまで要求してはいけません。元の要件が欠けている場合はCANNOT-CHECKとし、作成者が定めた、より狭い契約から推測してはいけません。これは意味内容に関する受け入れ確認であり、納品ゲートのスクリプトで確認できるものではありません。

1. 出典 — 根拠となる重要な事実はすべて、ページの外部にある出典と基準日までたどれる必要があります。数値だけでなく、引用した条項、誰かが何に合意したかについての主張、依存関係の状況に関する記述も対象です。読者はページをそれ自体と照合できますが、世界の実情と照合できるのはこの確認だけです。出典をたどれない情報はページから削除するか、不明であることを明示します。 出典のある画像については、実際のファイルを元の公開元と正確なオブジェクト／バリエーションに照合し、キャプションの制限事項と、予定している納品での使用許可を確認します。 図については、根拠となる重要なノード、接続、寸法を出典までたどります。説明用の図は、組み立て済みまたはデプロイ済みのシステムの証拠にはなりません。

2. 最新のレンダリング — レンダリングされたPNGが、ページの最終編集より新しいこと。実際のファイル名に置き換えます。

   [ page.png -nt page.html ] && echo FRESH || echo STALE
   

   find page.png -newer page.html ではなく、こちらの形式を使用してください。PNG が存在しない場合や 名前が誤っている場合、find は stderr にエラーを出力し、「出力があった」ことが 合格と解釈されてしまいます。-nt は、古い、存在しない、名前が誤っている、を一つの STALE にまとめます。

3. コンテンツの完全性 — ページが書き直されたかマージされた場合、 reconcile_content_diff.py の出力を提供する必要があります。それが生成されたものである場合は、生成器の --check 出力を提供します。これらはテキストの欠落や生成出力のドリフトを検出しますが、どちらも 意味的な完全性、矛盾の解消、または現在のビジネス状況を証明するものではありません。 マージや現状更新の場合は、さらに情報ポイントのマッピングと、 デリバリーゲートの 合并与现行事实验收 が要求するエビデンスを確認してください。 長期レポートリファレンスの §6.1 を適用してください。統合として提示されたアーカイブインデックス、 現状として提示された過去のスナップショット、または本番採用として提示された保存済みエビデンスを却下します。 著者がどちらも該当しないと述べている場合（手書き、 初版）、その回答をそのまま記録してください — 明示的なスキップは監査可能ですが、 想定されたスキップは監査できません。 正しく読み取るべき 2 つの出力があります。流し読みしてはいけません。レコンサイラーは実際に比較したフラグメントの数を出力します。ほぼゼロのカウントは「何も失われなかった」ではなく「何も比較できなかった」を意味します。その抽出器は CJK で始まる連続部分をサンプリングするため、中国語でないページではほとんど得られません。また、タイムアウトした場合 — Chrome が制限時間内に完全な DOM を生成しなかった場合 — その項目は未レコンサイルとして記録し、決して合格として記録してはいけません。ジェネレーターの --check には独自の盲点があり、現在はそれに対するガードがあります — これは自己整合性の比較であるため、節アンカーがゼロであれば両側で同じように現れます。したがって、アンカー数を別途アサートし、ゼロの場合には非ゼロで終了します。

4. レビューの完了を確認する — ステップ 9 のレビューファイルを開き、レビュアー自身の指摘の 1 つをそのまま引用し、そのレビュアーがどのように起動されたかを記録します。パスはファイルが存在することしか証明せず、そのファイルを書くのは著者です。レビュアー自身の言葉と起動の詳細こそが、レビューが実行されていなければ生み出せないものです。次に、各指摘に処置がなされているかを確認し、その後に加えられたすべての変更を尋ねます。そのリストに文言以外の何か — 骨組み、コンポーネント、意思決定カードの内容、何らかの数値、またはレビュアーが解釈を要した何らかの用語 — が含まれているなら、ステップ 9 は新しいレビュアーを必要としていたので、それが実行されたかどうかを確認します。ページが 读者已知清单(ステップ 1)を宣言している場合、各 audience-declared-known の指摘に対する著者の処置は暫定的な第一パスであり、答えではありません — これがそれを本物にする独立した再導出であり、著者自身の結論を見直すことではありません: レビュアーが引用した指摘と、それが処置された対象のリスト項目を読み、著者が述べた理由を先に読むことなく、独立に判断します — あなたなら同じように分類するかどうかを。リストに挙げられた用語に言及しているだけでありながら、実際の不満が別のこと(グラフの主張、壊れた相互参照、色の衝突)である指摘は、その用語がリストにあるからといって処置されたことにはなりません — レビュアーの文が実際に何について不満を述べているかを確認し、そこにどの語が現れているかではありません。著者の分類に同意できない → 著者が何と書いたかに関わらず、その項目は未処置であり、合格ではありません。また、宣言された用語がページの読者が実際に遭遇するものであるかを確認します — コメント、alt テキスト、aria-hidden の内容、または display:none のマークアップに押し込まれた用語は、「ページに現れる」を機械的に満たしますが、読者がこのページを読むことによってすでに知り得たものであったことは一度もなく、それに対して指摘を処置することは、まさに references/audience-triage.md が名指しする gaming の経路です。最後に、リスト自体の履歴を確認します: 処置された用語のいずれかが、このレビューサイクルより前のゲートファイルの「上一轮的答案」付録に保存された 读者已知清单 のバージョンに存在せず、ゲートファイルがその項目の隣にそれを明記していない場合(补记于 cycle N 审阅之后 または同等の表現)、それはラベルのない後付けです — 合格ではなく未処置として扱います。ラベルの付いた後からの追加は、自動的に失格とはなりません。他の項目と同様に、読者が本当にすでにそれを知っているかどうかを判断します。

5. デリバリーゲートが実行され、その回答がこのページを記述している — 三つのことを求めてください。最初の二つは偽装するのが容易であり、三つ目があって初めてそれらが意味を持つからです: (a) page.html.gate.md と page--masked.png が存在し、check が今この時点で終了コード 0 を返すこと (出力を貼り付けてください)。非ゼロの終了コードはこの項目の FAIL であり、あなたが待っている間に 著者に init --force を再実行させてやり直すよう促すものではありません — ゲートはページがあなたの手に 届く前にグリーンであるべきものです。(b) マスクされた PNG に見える異なるジオメトリをまず数え、その 数字を書き留め、それから初めてゲートの表を開く — 先に表を読むと、そこに列挙された図形を探しにいく ことになり、それは既知の方向を持つ確証バイアスです。次に二つのカウントを比較してください — ここでは マスクされたレンダリングがグラウンドトゥルースです。不一致と断じる前に二つのこと: 長いページには まず crop_segments.py が必要であり(19000px の PNG は一度の Read では読めません)、また 複合ジオメトリは正当に複数の図形として表示されます — 主軸とインセットを持つタイムライン、 対になった before/after バーなど — ですから二重に数える前にゲート行自身の data-derived-from を 読んでください。本当の不一致とは、視覚要素がスキャナから逃れたか(スキャナは静的なマークアップしか 読みません: 短いプロパティリスト上のインラインのパーセンテージスタイル、および <svg>/<canvas> の 要素 — CSS クラスから設定された幅、グラデーションストップ、transform のパーセンテージ、あるいは JS ライブラリが実行時に注入するチャートは、すべてスキャナには見えません。<canvas> という要素は 捕捉されますが、それが描画するものは捕捉されないことに注意してください) 、またはラッパーが複数の ものを一つと主張しているかのどちらかです。(c) 二つの記入済み行を無作為に選び、それぞれの 「遮字后读出的关系」をマスクされた PNG と自分で照合してください。一行では薄すぎます — 単一の行の偽装は 1/N の抽選を生き残ってしまいます。そして正しいことを判断してください。問いは「この文は真実か」では なく、**「その画像を開かずにソースから書けたか」**です。マークアップが述べていることをただ言い換えて いるだけの主張(「6 本のバーが左から右へ上昇している」)は最初のテストには合格し、二番目のテストには 失敗します。それが手に入れたすべてであるなら、そう述べてください。マスクされた PNG がどこから来たか も重要です — それは著者自身の実行によって生成されるので、それについて少しでも怪しい点があれば、 コピーに対して delivery_gate.py init --force で自分で再レンダリングして比較してください。

   この項目が存在する理由を、著者が省略する最も強い理由を持つ項目だからこそ率直に述べます: これがなければ、 ステップ 3 と 5 はオプトインです。2026-08 版の独立したレビューでは、ゲート全体がゼロコストで スキップ可能であることが判明しました — 下流のどの役割もその成果物を要求しなかったため、著者は 3 と 5 を スキップし、6 から 11 を完全に実行しても、誰も気づかないのです。チェックするよう誰も割り当てられていない ゲートは、そもそもやるつもりだった人々のためだけに存在するゲートです。

ある項目に回答できない場合、そのギャップはページが完了したと宣言されるのではなく、率直に書き留められます。 正直なギャップは読者が行動できるものです。決して実行されなかったチェックを覆うグリーンのチェックリストは そうではありません。

依存関係

• 利用可能な場合は、ユーザーの文章作成ルールに従うための content-writing-discipline。
• ブラウザーでの確認とビジュアル検査には frontend-visual-qa を使用します。これはこのスイートではなく、隣接する claude-code-skills スイートに含まれているため、セッションによっては読み込めない場合があります。 利用できない場合は、検査を省略せず、代わりに直接確認してください。レンダリングされた PNG をセグメントごとに確認し、ミクロな観点（タイポグラフィ、配置、コントラスト）、マクロな観点（ページのリズム、セクションのバランス）、意図（各ビューがサブ質問に答えているか）を確認します。
• レンダリングには Google Chrome または Chromium が必要です。ステップ 5 のゲートにも必要です。さらに、uv も必要です（PEP 723 ヘッダーから delivery_gate.py の pillow をインストールします）。以前のワークフローは標準ライブラリだけで最初から最後まで実行できましたが、このワークフローではできません。ゲートの目的は成果物の生成だからです。これらがない場合は、受け入れ項目 5 に理由とともに CANNOT-CHECK と記載してください。項目を合格として報告したり、ステップ 3 と 5 を黙って省略したりしないでください。
• PNG の検証とコンテンツの照合には Python 3.10 以降が必要です。reconcile_content_diff.py は標準ライブラリのみを使用します。delivery_gate.py は PEP 723 で pillow を宣言しており、uv run が自動的にインストールします。 reconcile_content_diff.py は X | None アノテーションを使用しているため、3.9 ではエラーが発生します。
• 自動レイアウト図には、任意で d2 を使用します。
• deck-creator（ルート C）は、HTML デザインの承認後に編集可能な PPTX が必要な場合にのみ使用します。