project-review について
project-reviewは、承認済みの目標と範囲を限定した実装を評価し、PASS、FAIL、BLOCKEDのいずれかを返すプロジェクトレベルの受け入れスキルです。受け入れ基準を固定して読み取り専用のレビュー担当を調整し、修正は権限を持つProducerに委ねます。
主な機能
- 01受け入れ基準とプロファイルの固定
- 02読み取り専用レビュー担当の調整
- 03指摘と範囲内修正の検証
- 04PASS、FAIL、BLOCKEDの判定
- 05レビュー再開用の状態記録
活用シーン
- 01リリース前の実装確認
- 02スキルとその証拠の評価
- 03記録済みの未完了レビューの再開
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/project-reviewを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
agents/openai.yamlreferences/acceptance-charter.mdattribution.mdevidence-protocol.mdfinding-schema.mdmigration.mdmission-center-compatibility.mdreview-rubric.mdstopping-rules.mdsubagent-protocol.mdWORKFLOW.mdreferences/profiles/agent-skill.mdgeneric.mdmanuscript.mdsoftware.mdspecification.mdtests/test_agent_skill_profile_contract.pytest_generic_profile_contract.pytest_manuscript_profile_contract.pytest_software_profile_contract.pytest_specification_profile_contract.py詳細
プロジェクトレビュー
project-review はプロジェクトレベルの最終受け入れ機能です。モデルから呼び出されるほか、手動でも呼び出せます。受け入れベースラインを固定し、review-loop を通じて読み取り専用のレビュアーを実行し、最終的な PASS、FAIL または BLOCKED を発行します。Producer は認可された修正を行いますが、project-review 自体が成果物を修正することはありません。
使用する場面
- プロジェクトに承認済みの目標（SPEC、ブリーフ、チケットグラフ）があり、確認対象となる実装範囲が明確な場合：
light-implementまたはチケットの一括処理後、release-workflowの前。 - スキルの審査：受け入れ基準がパッケージの
SKILL.mdとそのエビデンスである場合。
docs/agents/light-project.md が存在する場合は、レビューのプロファイルと受け入れ戦略に従って開始し、その後、実際の受け入れ基準を固定します。
コア動作
- 受け入れベースラインを固定し、プロファイルを選択します：generic.md、 software.md、 manuscript.md、 agent-skill.md または specification.md。
review-loopを通じてレビュアーを呼び出します。通常の成果物にはgeneric-review、ソフトウェアの差分にはlight-code-review、該当する場合は承認済みのドメインレビュアーを使用します。レビュアーが返すのは指摘事項のみです。- 指摘事項を検証し、範囲が限定された対象内の修正のみを指示して、新たに独立した評価者に確認を依頼します。
- 停止ルールを満たした時点で判定を発行します。
開始モード
次の3つのモードのいずれかを使用します。詳細は WORKFLOW.md を参照してください。
init：レビューの前に受け入れベースラインとプロファイルを固定します。review：エビデンスの収集、批評、検証、修正、評価を、範囲を限定して1ラウンド実行します。resume：過去のエビデンスを書き換えずに、記録された未完了のアクションを次に続行します。
引き継ぎと停止
PASS：固定されたすべての基準に適切なラベル付きエビデンスがあり、新たな評価者がベースラインを承認しています。FAIL：固定された条件が満たされておらず、確認済みで対象範囲内の限定的な修正では解決できません。BLOCKED：必要なベースライン、権限、環境、エビデンス、アクセス、または独立したコンテキストを利用できない場合、記録に矛盾がある場合、または修正の上限により安全な収束ができない場合です。
デフォルトの最大ラウンド数は3回です。永続化する状態は
.project-review/ に記録します。正確な状態ツリーと再開ルールについては、WORKFLOW.md を参照してください。受け入れ基準がトラッカーのチケットである場合、PASS の後にチケットを完了し、FAIL または BLOCKED の後にブロッカーをコメントします（チケットのクローズ処理）。
オプション機能
Cause: directionを伴うFAIL→ チケットのクローズ処理後、verdict.mdのパスを指定してlight-redirectを呼び出します。利用できない場合、または呼び出しが断られた場合は、チケットのFAILコメントを引き継ぎとします。.scratch/<feature>/plan.htmlが存在する場合 → 判定とチケットのクローズ処理後、light-html-planを呼び出して更新します。ページまたは機能がない場合はスキップします。
参考資料
- WORKFLOW.md — init/review/resume、役割ごとのパケット、状態ツリー。
- acceptance-charter.md — 固定されたベースラインとプロファイルの項目。
- evidence-protocol.md — エビデンスのラベルと記録。
- finding-schema.md — 指摘事項の識別情報、処置、レジストリ。
- review-rubric.md — コアチェックとプロファイルの評価項目。
- subagent-protocol.md — 批評者／評価者のパケットと独立性。
- stopping-rules.md — 判定の遷移と修正の上限。
- migration.md — 履歴のみ。実行時には不要です。