mcpField
C
ce-doc-review

ce-doc-review

github.com/everyincドキュメント25.8k3.7k 回インストール今日更新
リポジトリ

ce-doc-review について

ce-doc-review は、要件文書や計画文書が合意済みの作業を正しく導けるか確認するドキュメントレビュー用スキルです。選定したレビュアーの根拠を集め、プロジェクトの事実と照合して指摘を検証し、許可された修正を適用したうえで未決事項や改善点を報告します。

主な機能

  1. 01要件文書と計画文書の分類
  2. 02レビュアーの選定と調整
  3. 03プロジェクトの事実に基づく指摘検証
  4. 04許可された修正の適用
  5. 05レビュー範囲、判断、改善点の報告

活用シーン

  1. 01実行前のプロジェクト計画レビュー
  2. 02要件における重要な不足の確認
  3. 03確定済みの判断に基づくレビュー意見の検証

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/everyinc/compound-engineering-plugin --skill ce-doc-review

インストール後、Claude Code で/ce-doc-reviewを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
bulk-preview.md
cross-model-review.md
decision-primer.md
dispatch.md
document-intake.md
findings-schema.json
modes.md
open-questions-defer.md
persona-selection.md
rendering-floor.md
review-output-template.md
subagent-template.md
synthesis-and-presentation.md
walkthrough.md
references/personas/
adversarial-document-reviewer.md
coherence-reviewer.md
design-lens-reviewer.md
feasibility-reviewer.md
product-lens-reviewer.md
scope-guardian-reviewer.md
security-lens-reviewer.md
whole-doc-reviewer.md
scripts/
cross-model-doc-review.sh
packs-resolve.py
peer-job-runner.py

詳細

翻訳後に原文が更新されています。最新の内容は原文をご確認ください。

ドキュメントレビュー

作者が合意済みの作業を遂行するために使える、確かなドキュメントを完成できるよう支援します。その作業の結果を変えてしまう問題や、実行を実質的に妨げる問題を見つけ、すでに与えられた権限の範囲内で解決してください。詳細の量ではなく、正しい作業を導けるかどうかでドキュメントを評価します。欠陥が小さくても、重大な影響につながるなら注意が必要です。十分なドキュメントに変更は不要です。

レビュアーのペルソナは根拠を提示します。判断するのはあなたです。レビュアーの指摘を、ドキュメント全体、プロジェクトの事実、確定済みの決定事項と照らし合わせて確認してください。統合リファレンスに記された編集権限とレビュアーの要件の範囲内で、既存の決定事項の遂行を妨げる、立証済みの誤りを修正してください。許可がまだ必要な、価値のある改善点、重大な選択事項、またはユーザーにしか提示できない必須情報、および有用な所見のみを返してください。

完了条件: 選択したすべてのレビュアーから回答を受け取るか、Coverage で失敗として明記し、保持した指摘には合意済みの作業に対する検証済みの影響があり、Apply に割り当てられた、許可済みの修正をすべて実施して確認していること。最終状態は、対話モードでは対話型の承認または決定プロセスを通じて報告し、非対話モードでは構造化テキストとして返してください。

対話モードのルール

何よりも先に references/modes.md を読んでください。 モードの判定方法、非対話モードの引数仕様、質問ツールのルールが記載されています。質問ツールは、現在のツールリストにすでにあるホストのブロッキング型質問ツールに合わせてください(ユーザー向けの質問ツールを呼び出して探してはいけません)。リストにはあるものの読み込まれていない場合は、対話フローの冒頭で事前に読み込んでください。ハーネスに質問ツールが実際にない場合に限り、番号付きリストに切り替えてください。

いずれの場合も、ユーザーの判断を求める質問では、ツールを呼び出すか、代替手段に切り替えることを明示してください。単なるテキストで質問したつもりになるのは不具合です。

成果物ルート

<root> の解決は、<root>/plans/ の最新の計画を見つける、パス指定なしの対話分岐でのみ行います。それ以外の実行では、渡されたパスにあるドキュメントを読み込みます。したがって、絶対パスまたは非対話のレビュー(/tmp/plan.md など)は、リポジトリのルートや、必要のない CE 設定に依存しません。

成果物のパスを組み立てる前に、CE 成果物ルート <root> を解決してください。

  • <repo-root>/.compound-engineering/config.yaml からのみ docs_root を読み取ってください(<repo-root> は git rev-parse --show-toplevel で取得します)。config.local.yaml から読み取ってはいけません。未設定の場合、従来どおり <root> は docs です。
  • 設定値がある場合は検証してください。リポジトリ相対のディレクトリであり、シンボリックリンク解決後の実パスがリポジトリ内にあり、リポジトリのルートでも .git/ 以下でもないことが条件です。それ以外の場合は docs_root と設定値を示すエラーを出して停止し、docs にフォールバックしてはいけません。
  • <root> を唯一の成果物の場所として使用してください。存在しない場合は作成し、各パスをこのスキル固有のサブディレクトリを使って <root>/<subdir> として組み立て、docs を併せて読み込んではいけません。

フェーズ 1:ドキュメントの取得と分析

今すぐ references/document-intake.md を読んでください。 各モードでドキュメントを取得する方法、ドキュメントが見つからない場合の対応と伝え方、分類の判断材料について説明しています。

以降のすべてのステップに適用されるルールが 2 つあります。

ディスパッチの前に必ず確認してください。 解決された各パスは、ディスク上で読み取り可能でなければなりません。そうでないパスが 1 つでもあれば、ペルソナを一切ディスパッチしないでください。レビュアーはファイルシステムから読み取るため、チェックアウトされていないブランチにしか存在しないパスにはアクセスできません(issue #925)。

準備状況を示すラベルやファイルパスではなく、内容に基づいて分類してください。 Product Contract のみを含む統合アーティファクトは unified-requirements です。実装セクションが不足していても問題ありません。実装の計画が含まれていれば、未完成またはレビューが必要なブロック状態の計画も含めて unified-plan です。それ以外のアーティファクトには、従来どおり requirements / plan の区分を使用します。

HTML の統合アーティファクトも同じ経路をたどります。修正はすべてドキュメント本来の形式で行い、Markdown を HTML に挿入しないでください。このリファレンスでは、ID を持つ項目についても説明しています。分類結果は、各ペルソナの {document_type} スロットに渡してください。

フェーズ 2:ペルソナの告知とディスパッチ

references/document-intake.md に記載されているレビュー完了結果の再利用条件を満たす場合に限り、ディスパッチを省略してください。その場合は、その根拠をフェーズ 3 に引き継ぎます。

各条件付きペルソナの有効化シグナルと告知形式について、references/persona-selection.md を読んでください。このシグナルのうち 2 つは、妥当と思われる根拠があれば有効化されすぎます。security-lens-reviewer の機微データに関する基準と、adversarial-document-reviewer の検証対象の基準です。次に、ペイロード変数、分割方法、モデルの階層化、レビュアーの失敗への対応について references/dispatch.md を読んでください。

チームには、常に coherence-reviewer と feasibility-reviewer を含め、さらに有効化された条件付きペルソナを加えます。ディスパッチする前に、ペルソナごとの選定理由を添えてチームを告知してください。

プラットフォームのサブエージェント機能を使用し、並列数を制限して汎用サブエージェントをディスパッチしてください。それぞれに references/personas/<reviewer-name>.md の全文を渡してください。種類や名前を指定した単独エージェントをディスパッチしてはいけません。

キャパシティによる拒否はバックプレッシャーであり、レビュアーの失敗ではありません。待機して再試行してください。キャパシティが回復せず、選定されたレビュアーが未ディスパッチのままの場合は、references/cross-model-review.md の説明に従って、開始済みのクロスモデルジョブを収集してクリーンアップしてから、統合、修正、成功の引き継ぎを行わずに未完了として停止してください。収集済みの結果を保持し、どのレビュアーが完了したか、失敗したか、実行できなかったかとその理由を報告してください。

クロスモデル判断パス

条件付き判断担当の 3 ペルソナ(adversarial-document-reviewer、product-lens-reviewer、security-lens-reviewer)のいずれかが有効化された場合、このパスを実行してください。パス全体の手順を定めている references/cross-model-review.md に従ってください。そこでは、実行ホストの確認、ドキュメント全体で使用する唯一のターゲットと経路、マシンの外に情報を出す前の開示、ピアの起動・結果の収集・取り込み方法について説明しています。

このパスは追加的なもので、ブロッキングではありません。失敗やタイムアウトがあっても停止せず、Coverage に明記してください。チェックアウトの cross_model_review_mode 設定を最初に確認し、設定に応じて理由を明示したうえでパスを省略できます。受信者のフィルタリングは CROSS_MODEL_PEERS が設定されている場合に限って行ってください。未設定は、未承認ではなくフィルタリングなしを意味します。明示されたモデルや受信者を、黙って変更してはいけません。

フェーズ 3〜5:統合、提示、次のアクション

ディスパッチしたすべてのエージェントから、クロスモデルの<reviewer-name>-<provider>.jsonの返却を含め、結果が返るまで待ちます。その後、references/synthesis-and-presentation.mdを読みます。ここでは、統合、確信度と修正クラスに応じた各指摘の振り分け、修正の適用、非対話形式の結果フォーマット、ルーティングの質問への引き継ぎについて定義しています。合意を採用する場合、独立したレビュアーとして数えるのは、independence_verified: trueのアーティファクトのみです。

対話モードのみ。 グループ化された確認、ルーティングの質問、指摘ごとのウォークスルーについては、references/walkthrough.mdを読みます。最善の判断によるルーティング、「未解決の質問への追加」、自動解決に伴う一括アクションのプレビューについては、references/bulk-preview.mdを読みます。新たに収集したものでも、有効な形で再利用したものでも、レビューの証拠が揃う前にこれらを読み込んではなりません。また、非対話形式の実行ではこれらを一切読み込まず、構造化されたレビュー結果で終了します。


現在のレビューで選択されたペルソナのプロンプトのみを読みます。ディスパッチのペイロードに適用するテンプレートとスキーマ:

@./references/subagent-template.md

@./references/findings-schema.json

コメント