reviewing-document-set

reviewing-document-set — SKILL.md

バリアント： standard · 使用場面： 完成した一連の文書を1つのコーパスとして評価し、相互に整合していて計画の立案に使える状態かを確認したうえで、文書ごとの所見を添えて VERDICT: approve|revise を出力します。

概要

このスキルは、完成した関連文書一式を対象とするコーパスレベルの受け入れゲートです。文書一式をすべて把握しているレビュアーが使用し、次の1つの問いに答えます。これらの文書は、プロジェクトの意図を引き継ぐ、整合性のある一連の文書を構成しており、計画の立案や構築に十分な内容を備えていますか？ 固定の8次元の文書間チェックリストを適用し、機械で解析できる単一の判定と、作成者が対処できる文書ごとの所見を出力します。

これは、単一文書レビューを補完するものです。各文書の品質ゲートはすでに実施済みです。このスキルでは、個々の文書の内部品質を再審査することはありません。一式としての文書どうしの関係性だけを評価します。レビュー専用であり、内容の作成、修正、書き換えは行いません。

有効化するタイミング

• 下流の計画に進む前に、関連するプロジェクト文書一式について、相互整合性に基づいて承認または修正を判断する必要がある場合。
• 各文書がそれぞれの文書種別レビューに合格した後に、コーパス全体を独立した立場から審査する場合。
• 変更後にコーパスを再レビューする場合。作成者が以前の revise 判定に対処した場合も、1つ（または少数）の文書が独立して変更された場合も該当します。どちらの場合も、**第7次元（修正／変更差分に限定した再レビュー）**を実施し、コーパス全体ではなく、変更が影響した関係のみを再検証します。

次の場合は有効化しないでください：

• 単一文書の内部品質を評価する場合。該当する文書ごとのレビュー（例：単一の設計文書に対する設計レビュー）を使用してください。
• 文書を作成または修正する場合。これはレビュー専用です。
• 文書が1つしかない場合。評価する文書間の関係がありません。

ワークフロー

手順は、8つの次元の評価と、その後の判定です。まず、すべての文書を読んでください。

コーパスの規模に応じて監査の範囲を調整してください（比例性）。 文書間監査の深さと、適用する次元は、コーパスの規模に応じて変わります。小規模で整合性のある文書一式（2～3文書で、文書間の関係が少ない場合）は承認とします。修正判定の根拠として、RTMのような形式的な手続きを無理に持ち込まないでください。よくあるケースでは、いくつかの次元は明示的に**該当なし（n/a）**となります。第7次元（修正）は、過去のバージョンや明示された変更がない、グリーンフィールドの初回レビューでは該当なしです。第8次元（バージョンの不一致）は、単一バージョンの文書一式では該当なしです。規模の小さいコーパスや初回レビューのコーパスに大がかりな監査を適用すると、誤った修正判定につながります。

ステップ1 — 状況を把握する

最上流の文書（起点となるブリーフ／要件文書）を特定します。これは、下流への「引き継ぎ」状況を確認するためのトレーサビリティの起点です。各文書が宣言している上流の依存関係を記録します。各文書はすでに個別のゲートに合格しているものとし、文書間の欠陥のみを探してください。渡された文書一式を評価してください。「含まれるべき」文書の別リストは必要ありません。また、文書一式とともに渡された明示的な変更（差分、バージョン更新、変更履歴）があれば記録してください。それがある場合は修正の再レビュー（第7次元）が必要です。ない場合はグリーンフィールドの初回レビューとみなし、第7次元は該当なしです。

ステップ2 — 8つの次元を評価する

各次元について、所見を集めます（欠陥は常に文書間に存在します）。

1. ドキュメント間の一貫性（重要用語を含む）。 同じ事実、数値、決定、範囲の境界、または固有名詞は、それに触れるすべてのドキュメントで同じように記述されています。指摘の種類は2つあります。実質的な不一致（値、決定、範囲が異なる形で記載されている）と、重要用語の不一致（同じ中核的な対象が、あるドキュメントでは「メンバー」、別のドキュメントでは「アカウント」と呼ばれ、同一であるとの説明もない）です。両方を指摘してください。文章のスタイル、口調、問題のない同義語は指摘しないでください。
2. 完全性と追跡可能性（ルート文書を基準にする）。 ルート文書の各目標／要件は、詳細化または実現するはずのドキュメントに引き継がれており、暗黙のうちに抜け落ちていないこと。欠落した要件（ルート文書にあるが、下流のドキュメントにはない）、孤立したドキュメント（どのドキュメントからも参照されず、上流も参照していない）、未解決のTBD／プレースホルダーの意図を指摘してください。
3. 矛盾の検出。 どの2つのドキュメントも、両立し得ない事実／決定を主張していないこと。これは一貫性における最も厳しい基準であり、単に表現が異なるのではなく、論理的に両立しないことを意味します。
4. 依存関係の整合性。 各ドキュメントは、上流として宣言したドキュメントを忠実に詳細化していること。同じ対象、決定、範囲を維持しつつ、詳細を追加し、矛盾や暗黙の範囲変更をしていないこと。
5. 不要な重複がないこと。 1つのドキュメントに記載すべき事実／決定／定義は、そのドキュメントに一度だけ記載して参照し、複製した内容が乖離する可能性をなくすこと。乖離する重複（同じ内容が複数箇所に記載されているが、互いに食い違っている、または将来食い違うおそれのある、管理主体の不明確な大幅な重複）を指摘してください。
6. 計画策定の準備が整っていること。 ドキュメント群を総合したとき、計画担当者が確認を求めずに、妥当なマイルストーンを導き出せるだけの十分な一貫性と情報があるでしょうか。具体的な「計画準備完了」の基準として、計画を妨げる条件の判定に以下を適用してください。依存関係が特定されていること（ドキュメント群が前提とする、ドキュメント間または外部との依存関係がすべて、そのセット内のどこかで特定されていること。名前が挙がっているのに詳細が定義されていない依存関係はブロッカーです）、どこかに検証可能な受け入れ条件があること（重要な要件ごとに、ドキュメント群のいずれかに検証可能な受け入れ条件があること。条件を担うのは個々のドキュメントではなく、ドキュメント群です）、計画を妨げる未解決のTBDがないこと（後続フェーズが依存する未解決の決定事項がないこと）。さらに、参照されているが存在しない重要なドキュメントも指摘してください。これは、提出されたセット自体が参照しているのに、そのセットに含まれていないドキュメントを指します（api-specが「data-modelを参照」と記載しているがdata-modelが存在しない、または3つのドキュメントが、どのドキュメントにも仕様がないセキュリティモデルを前提としている、など）。この欠落は、セット内にある参照先の宙ぶらりんから推定してください。プロジェクトに必要ないかもしれない「理想の一覧」にあるドキュメントを、外部から求めてはいけません（ステートレスなCLIツールにdata-modelがないことは欠陥ではありません）。これがapproveとreviseの違いです。
7. 修正／差分に範囲を絞った再レビュー。 これは、セット内のドキュメントが変更された場合に限って適用します（変更内容、バージョン更新、または変更履歴が提示されている場合）。新規作成の初回レビューセットでは該当なしです。きっかけは2つありますが、方法は同じです。変更は、(a) 作成者が以前のreviseに対応した場合、または (b) 上流ドキュメントが独立して変更された場合があります。どちらの場合も、(1) 変更されたドキュメントを特定し、(2) そのドキュメントを上流として宣言しているドキュメント（依存先、つまり影響を受ける可能性のあるエッジ）まで変更の波及を追跡し、(3) 波及の確認 — 影響を受ける各エッジについて、変更が依存先に反映されたか、依存先が古い状態のままかを確認し、(4) 差分に範囲を絞る — 影響を受けるエッジと、そこから二次的に波及する部分のみを再検証し、変更されておらず、すでに整合している関係を再審議しないでください。変更の波及が届いていない依存先は指摘事項です。「変更されたが、差分が提示されていない」場合： セットが明らかに変更されているのに差分が提示されていない場合、動的な追跡は該当なしとし、全体レビューで次元8（静的なずれの確認）を使って、古い状態のままの依存先を検出してください。
8. バージョンの不整合（古い相互参照）。 明示的な相互参照（ドキュメントAがドキュメントBの決定／値／対象／バージョンを参照しているもの）ごとに、AがBの現在の状態を反映していることを確認してください。すでに置き換えられた状態を反映していてはいけません（AがBのv1での決定を詳細化しているが、Bはv2に移行している、またはAがBで名称変更された対象を記載している、など）。重複判定の防止（同じ指摘を重複して挙げない）： 次元8が対象とするのは、古さ／現行状態との不一致のみです。ドキュメントが別のドキュメントの置き換えられたバージョン／決定に基づいている場合に限ります。バージョンの観点がない単なる値の不一致は次元1、明らかに両立しない内容は次元3、暗黙の範囲変更は次元4で扱います。次元1／3／4ですでに指摘した問題を、次元8で再び指摘しないでください。単一バージョンのセット（すべてのドキュメントが初版で、古さの比較対象となる以前の状態がない場合）では該当なしです。次元8は、次元7の動的な波及確認に対する静的な対になる基準です。次元7は変更の通知があった際に新たに生じた不整合を検出し、次元8は変更の通知があるかどうかにかかわらず、任意のレビューで不整合を指摘します。

ステップ 3 — 判断して出力する

所見を総合してください。一貫性があり、完全で、追跡可能で、最新（バージョンのずれがない）で、変更が関連箇所にすべて反映されており、計画を始められる状態のコーパスは 承認 してください。細かな指摘を理由に、整合した一式を誤って 要修正 と判定しないでください。また、相応に該当しない観点（7、8）が欠けていることを理由に、薄い（エッジが少ない）一式、単一バージョンの一式、またはグリーンフィールドの初回レビューの一式を誤って要修正と判定しないでください。実在する、具体的な文書間の欠落があれば 要修正 としてください。以下の出力仕様に従って出力してください。

ルール

厳守事項（決して違反しないこと）：

• コーパス全体に対して最終判定は 1 つだけ。 最後は、VERDICT: approve または VERDICT: revise のどちらか 1 行だけ で締めくくってください。一式全体に対する判定を出してください。文書ごとに判定してはいけません（呼び出し元は通常、最後の VERDICT: 行だけを読み取るため、複数の判定を出すと結果が壊れます）。
• 文書ごとの帰属を角括弧で示す。 所見の各行は、影響を受ける文書 ID を角括弧で囲んだ表記から始め、その文書間で何が問題か、どう整合させるべきかを記してください。例：- [d-prd, d-arch] 認証モデルが異なります（PRD：OAuth、アーキテクチャ文書：SAML）— どちらかに決め、両方を揃えてください。 1 つの不整合に複数の ID を記載してかまいません。どの文書を変更すべきか判断してください。これにより、呼び出し元は影響を受ける各文書に修正を割り当てられます。
• 文書間のみを対象とする。 単一文書内の品質を改めて評価してはいけません。それは以前の別のゲートで確認済みです。
• 提出された一式を評価する。 想定される文書の別リストを要求してはいけません。渡された一式そのものをレビュー対象とします。
• 誤って要修正と判定しない。 整合したコーパスは承認してください。要修正とするのは、実在する具体的な欠落があり、所見が一度の修正で対応可能な場合に限ります（何が問題か、どの文書か、どう整合させるかを示す）。
• レビューのみ。 文書を作成、修正、書き換えしてはいけません。所見を報告し、作成者が修正します。

注意点

• 名称の不一致を矛盾とみなさない。 同じ実体に異なる名称が使われていること（観点 1）は、両立できない記述が 2 つあること（観点 3）とは異なります。正しく分類してください。必要な修正は異なります。
• 単一文書のレビューに逸れない。 PRD の内容が 優れているか を評価するのは文書単位のゲートの役割です。ここでは、PRD が他の文書と 整合し、他の文書に反映されているか だけを評価してください。
• 「各文書に問題がないので、一式にも問題はない」と考えない。 個々には正しい文書でも、互いに食い違うことがあります。一貫性は各文書の性質ではなく、文書間の 関係性 によって決まります。
• 文書をペアごとに確認するだけでは、欠落した要件を見落とす。 下流のすべての文書から要件が抜け落ちている場合、それと矛盾するペアは存在しません。根本文書を起点とした追跡可能性の確認だけが、このケースを検出できます。
• 文書ごとに判定しない。 文書ごとの所見を出すと判定も文書ごとに出したくなりますが、最後の判定行を読み取る呼び出し元に支障が出ます。判定は 1 つだけにし、所見に帰属先を示してください。
• バージョンのずれを二重に指摘しない（観点 8 の重複）。 古くなった相互参照は最新性の欠陥（観点 8）です。単なる不整合（1）、矛盾（3）、依存関係の欠陥（4）として重ねて指摘しないでください。1 つの欠陥は 1 つの観点で扱います。「廃止されたバージョン／決定」のケースは観点 8 の対象です。
• 改訂実行を全面的な再レビューとして扱わない。 文書が変更された場合、変更が及んだエッジだけでなく、コーパス全体を再検証するのは無駄であり、誤って要修正と判定するリスクもあります。観点 7 は 差分を対象とします。逆に、一式が明らかに変更されたのに差分が提示されていない場合、動的な追跡確認は該当しません。変更履歴を作り上げず、観点 8 を基準にしてください。
• 外部リストにある文書を要求しない。 「文書がない」という所見が妥当なのは、一式自体が欠落文書を参照している場合（観点 6、参照されているが存在しない場合）に限ります。プロジェクトに不要かもしれない文書（ステートレスな CLI のデータモデルなど）を要求するのは捏造です。ここにマニフェストはありません。

アンチパターン

• コーパス全体ではなく、文書ごとに判定すること。
• 括弧付き ID を付けずに「PRD とアーキテクチャ文書の内容が一致しない」といった自由記述で帰属を示すこと。呼び出し側が文書ごとに対応できません。
• 類義語、語調、書式などのスタイルを不整合として指摘すること。
• 文書数が揃っているというだけで、要件を追跡したり決定事項を比較したりせずに問題なしとすること。
• 指摘事項を返す代わりに、文書を書き直すこと。
• 比例して該当なしとなる次元がない（7 は改訂、8 はバージョン間のずれ）ことを理由に、内容の薄い文書、単一バージョンの文書、グリーンフィールドの文書一式を誤って改訂対象とすること。比例性の判断対象はコーパスであり、固定チェックリストではありません。

出力

指摘事項レポートです。文書ごとに帰属を示す指摘行（それぞれ - [id, …] で始まります）が 0 行以上続き、その後に終端の VERDICT: approve|revise が必ず 1 行だけ付きます。revise の場合、指摘事項は呼び出し側が影響を受ける各文書に対する修正に変換できる、実行可能な一覧です。想定される利用者は、修正を振り分けるオーケストレーターと、修正を行う作成者です。

関連項目

• 単一文書の設計レビュースキル — 文書ごとの対応スキルです。このスキルはコーパスレベルの補完として、各文書がそれぞれのゲートを通過した後に実行します。
• 文書タイプ別レビュースキル — 1 つの文書の内部品質を評価します。このスキルは、文書を一式として見たときの相互関係を評価します。
• この運用の基盤となるプラクティス — 要件トレーサビリティ（RTM、順方向／逆方向／双方向）、単一情報源／用語の一貫性、IEEE 830 の一貫性と完全性、アジャイルの Definition of Ready（次元 6）、および変更影響分析（次元 7、改訂による波及）については、references/sources.md を参照してください。

段階的な開示

• references/coherence-bar.md — 8 つの次元それぞれの合格／不足のシグナルと、文書間の指摘例（特に次元 6／7／8 の評価時に読み込んでください）。
• references/sources.md — 8 次元の基準の調査に関する出典情報。

本文の上限

• description は 1,024 文字以下（agentskills.io の上限です。一覧表示では description と when_to_use の合計が 1,536 文字で切り詰められます）。
• 本文は約 500 行／5,000 トークン以下です。毎回のターンでコンテキストに保持されるため、重い内容は references/ に置きます。

変更履歴

• 1.1.0（2026-06-15） — 本番運用向けの大幅な再設計：基準を6 次元から 8 次元に拡張。次元 1〜5 は変更なし。次元 6 を深化（Definition of Ready を基盤に、参照されているが存在しない基盤文書の指摘を追加）。次元 7 を新設（改訂／差分範囲に絞った再レビュー — コーパスレベルの変更影響分析。revise 後と上流変更後の両方のトリガーを対象とし、グリーンフィールドの文書一式では比例して該当なし）。次元 8 を新設（バージョン間のずれ／古い相互参照。次元 1／3／4 との二重指摘を防ぐため、古さの軸が重複する場合のガードを設け、単一バージョンの文書一式では比例して該当なし）。さらに、少数の文書からなるコーパス向けの明示的な比例性ガードを追加。追加的な変更であり、入力と VERDICT の出力契約は変更なし。
• 1.0.0（2026-06-05） — 初回のレビュー済みリリース（6 次元の文書間基準）。