review

レビュースキル

概要

統合済みの差分全体（フィーチャーブランチと main の比較）に対して、敵対的なレビューを1回実施します。新しいコンテキストでレビューする担当者が、仕様への準拠、コード品質、テストの十分性をまとめて判断します。仕様と品質を別々の段階で審査することはありません。このレビューでは、判定結果（reviews.review.status）を1つ出力します。

**姿勢：**あなたは敵対的なレビュアーです。正しいことを確認するのではなく、誤っている点を見つけるのがあなたの役目です。

**必須：**十分な検証を行わずに承認することを正当化する説明を受け入れる前に、references/rationalization-refutation.md を参照してください。よくある言い訳と、それに対する反論および適切な対応がすべて記載されています。

実行コンテキスト

このスキルは、インラインではなくオーケストレーターが起動したサブエージェント内で実行されます。作成時のトランスクリプトを持たないクリーンなレビュアーに、差分と仕様が渡されます。

オーケストレーターは次の処理を行います。

1. 統合済みの差分を一度だけ生成します：exarchos_orchestrate({ action: "review_diff", baseBranch: "main" })（または git diff main...HEAD）。
2. 差分の内容、アーティファクトを解決するための状態ファイルのパス、および意図の根拠情報をディスパッチプロンプトに渡します。

サブエージェントは状態ファイルから仕様を読み取り、作業ツリーに対してゲートを実行し、敵対的なウォークスルーを行い、構造化されたJSON判定を1つ返します。

意図の根拠（意図と実装の照合）

オーケストレーターは、意図された変更を artifacts.intent として記録し、intentGrounding ディレクティブとしてディスパッチに渡します。これがある場合、実装された差分と照らし合わせて確認します。

• 意図されているが未実装 — 意図で求められているのに、差分で実現されていない対象領域や結果です。spec の問題として報告してください。
• 意図されていない実装（スコープクリープ） — 仕様上の根拠がないまま、意図された対象領域の範囲外で行われた変更です。spec の問題として報告してください。

intentGrounding が渡されていない場合は、差分のみを基準にレビューしてください。意図をでっち上げてはいけません。

このレビューで確認する内容

まずアプローチを選択します：exarchos_orchestrate({ action: "runbook", id: "review-strategy" }) — 差分のサイズと過去の修正サイクル数に応じて、シングルパスか2パスかを選びます。

すべてのタスクの統合された差分を一度に確認します。これにより、タスク間のインターフェースの不一致、個別には見つけにくいバグ、一貫性のないパターンを検出できます。1回のレビューで、次の3つすべての観点を確認します。

1. 仕様への準拠 — 機能の完全性、仕様との整合性、意図と実装の照合。references/spec-compliance-checklist.md を参照してください。
2. テストの十分性 — テストファーストの順序ではなく、結果に基づき、階層に応じて評価します。Settlement では、検証対象の各タスクについて、カプセルが固定したベースからキルプローブをすでに実行しています。記録された判定を読み取り、プローブを再実行しないでください。

   exarchos_event({ action: "query", stream: "<featureId>", filter: { type: "gate.executed" }, limit: 200 })
   

   gateName: "test-adequacy" を持つ各行は、1つのタスクの判定です。内容は details.taskId、passed、および details.verdict です（details.skipped はポリシーによるスキップを示します）。passed: false の判定は、そのタスクに対する指摘事項です。この行がないタスクについてのみ、タスクのフォーク元ブランチから自分でプローブを実行してください。ベースがないとゲートは base-missing でブロックされます。repoRoot: "auto" と、そのタスクのワークツリーを指定してください。プローブは、実行対象のツリーのソースを元に戻してから復元します。次の2つのフィールドを指定しない場合、対象のツリーはサーバーのディレクトリになり、通常は自分のチェックアウトになります。

   exarchos_orchestrate({
     action: "check_test_adequacy",
     featureId: "<featureId>",
     taskId: "<taskId>",
     branch: "<branch>",
     baseBranch: "<integration branch>",
     repoRoot: "auto",
     worktreePath: "<worktreePath>",
     riskTier: "<low|medium|high>",
     phase: "review"
   })
   

3. コード品質 — 正確性、SOLID、エラー処理、セキュリティ、パフォーマンス、保守性、およびテストに求められる特性（振る舞いを検証すること、構造に依存しないこと、決定的であること、具体的であること）。references/code-quality-checklist.md、references/security-checklist.md、references/typescript-standards.md を参照してください。

ゲートの実行

runbook を使って品質評価ゲートを実行します — exarchos_orchestrate({ action: "runbook", id: "quality-evaluation" }) — その後、MCP が提供する品質チェックカタログを実行します。シグネチャについては references/gate-execution.md を参照してください。

1. check_static_analysis — lint + 型チェック（D2）。必ず合格させてください。
2. check_security_scan — セキュリティパターンの検出（D1）。
3. prepare_review — 決定的なチェックカタログ（grep / 構造 / ヒューリスティック）と pluginStatus を返します。変更されたファイルに対して各チェックを実行し、検出結果を pluginFindings として収集します。
4. D3–D5 の任意ゲート（check_context_economy、check_operational_resilience、check_workflow_determinism）— 助言用です。収束ビューに反映します。

mutation-adequacy（HIGH ティアのみ）： /review の境界で HIGH リスクティアを判定する別個の必須ディメンションです — @skills/mutation-adequacy/SKILL.md を参照してください。このスキルではミューテーションテストを実行しないでください。スコープ内で最も近い代替指標は、テストの望ましい特性である Specific と、委譲時の check_test_adequacy ゲートです。

不変条件への適合 — 監査モードの判断はあなたが行います

.exarchos.yml: invariants.catalogs の下にカタログが登録されている場合は、差分に対して check_invariant_conformance を実行します。mode: check の不変条件を機械的に判定し、findings に含めます。ただし、mode: audit の不変条件は一切判定できません — それらにはレビュー担当者、つまりあなたの判断が必要です。

exarchos_orchestrate({
  action: "check_invariant_conformance",
  featureId: "<id>",
  phase: "review",
  diff: "<integrated diff>"
})

応答には、監査モード用の次の 2 つの要素が含まれます。

• auditPrompt — 適用される監査モードの不変条件ごとに 1 ブロックずつ表示される、判断のための質問です。
• auditInvariantIds — そのプロンプトに含まれる ID です。これはあなたのチェックリストであり、あなたが説明責任を負う対象の分母です。
• auditProjection — rendered、no-audit-entries、または no-subject です。no-subject は監査がクリーンであることを意味しません。投影で適用対象のエントリが 0 件と判定されたため、何も評価されていません。未解決のゲート（カタログ未登録、投影範囲が狭すぎる）として扱い、判定結果でその旨を述べてください。合格として扱ってはいけません。

auditInvariantIds のすべての ID に回答してください。 それぞれについて、auditPrompt 内のブロックを読み、差分を照らし合わせて判断し、次のように対応します。

• 違反あり → 検出結果を出し、check_review_verdict の pluginFindings に渡します。dimension には不変条件の ID を設定し、severity には不変条件自体の重大度を設定します（blocking → HIGH、advisory → MEDIUM）。
• 満たしている → 判定サマリーに記録し、該当 ID について明確に説明します。

回答していない監査モードの不変条件は、合格した不変条件ではなく、未実行のチェックです。auditPrompt を読まずに済ませると、カタログの監査モード部分全体が形骸化します。まさにそれを防ぐために、このカタログが存在します。

判定と修正ループ

統合した指摘セット全体に対して、一度だけ判定を行います。判断ランブック経由でルーティングします — exarchos_orchestrate({ action: "runbook", id: "review-escalation" })。references/convergence-and-verdict.mdを参照してください。

check_review_verdictは指摘の件数とpluginFindingsを受け取り、ゲートイベントを出力して、APPROVEDまたはNEEDS_FIXESを返します。

exarchos_orchestrate({
  action: "check_review_verdict",
  featureId: "<id>",
  high: nativeHighCount,
  medium: nativeMediumCount,
  low: nativeLowCount,
  pluginFindings: catalogFindings,
})

修正ループは共有エスカレーションポリシーによって制限されます（設定で解決可能なescalation.maxIterations、デフォルトは5） — shepherdループと同じ上限です。check_review_verdictはイベントソースの修正サイクル数を読み取り、ループが必ず従うべきエスカレーション判断を返します。

• 自動修正（上限未満で、機械的な指摘の場合） — escalateがない、または偽の場合：指摘とともに実装担当者へ再度ディスパッチし、再レビューします。
• ユーザーにエスカレーション — escalate: trueの場合：指摘とescalationReasonを提示して、どのように進めるかを確認します。これは、上限に達した場合、または指摘が意図に関わる場合（依頼内容を変えるspec上の問題 — ループではなく人間が判断する）のいずれかに該当するときに行います。

**補助プラグイン（プラットフォーム依存）：**スキルに対応するプラットフォームでは、オーケストレーターがフロントエンドの差分に対してimpeccable:critiqueを呼び出す場合もあります。その指摘は追加のpluginFindingsとして渡してください。

ゲートイベント：gate.executedを手動で出力してはいけません — check_review_verdictが出力します。手動で出力すると重複します。

必須の出力形式

サブエージェントは、構造化されたJSON判定を1つ返さなければなりません。それ以外の形式はエラーです。

{
  "verdict": "pass | fail | blocked",
  "summary": "1-2 sentence summary",
  "issues": [
    {
      "severity": "HIGH | MEDIUM | LOW",
      "category": "spec | tdd | coverage | security | solid | dry | perf | naming | test-quality | other",
      "file": "path/to/file",
      "line": 123,
      "description": "Issue description",
      "required_fix": "What must change"
    }
  ],
  "test_results": { "passed": 0, "failed": 0, "coverage_percent": 0 }
}

状態と遷移

判定はstatusフィールドを持つオブジェクトとして記録します（単一の文字列では、ガードによって通知なく無視されます）。

APPROVED：

exarchos_workflow({ action: "update", featureId: "<id>", updates: {
  reviews: { "review": { status: "pass", summary: "...", issues: [] } }
}})
exarchos_workflow({ action: "transition", featureId: "<id>", target: "synthesize" })

続けてsynthesizeを呼び出します。

NEEDS_FIXES：

exarchos_workflow({ action: "update", featureId: "<id>", updates: {
  reviews: { "review": { status: "fail", summary: "...", issues: [{ severity: "HIGH", file: "...", description: "..." }] } }
}})

続けてdelegate --fixesを呼び出します。

ガード：review → synthesizeにはall-reviews-passedが必要です — 必須の各次元のreviews.{name}.statusがすべて合格値（大文字・小文字を区別せず、pass | passed | approved | fixes-applied）でなければなりません。機能の構成はreview（HIGHティアではmutation-adequacyも含む）です。review → delegateはany-review-failedで発生します。

すべての遷移は自動です — これは人間によるチェックポイントではありません。references/auto-transition.mdを参照してください。

アンチパターン

しないこと	代わりにすること
正しい点を確認する	問題点を探す（敵対的な姿勢を取る）
キルプローブを使わずに承認する	各タスクに記録されたtest-adequacy判定を読む（または、settlementが検証しなかったタスクについてcheck_test_adequacyを実行する） — 失敗し得ないテストはカバレッジではありません
回答のない監査モードの不変条件を合格扱いにする	auditInvariantIdsの各IDに回答する。未実行のチェックは問題なしを意味しません
理屈付けをうのみにして承認する	references/rationalization-refutation.mdを参照する
スコープの逸脱を見過ごす	意図と成果物のずれをspec上の問題として指摘する
優先度LOWの細かな指摘でブロックする	記録して追跡し、ブロックはHIGHに限定する

スキーマの確認

現在のパラメータスキーマは、exarchos_workflow({ action: "describe", actions: ["update"] })と exarchos_orchestrate({ action: "describe", actions: ["check_static_analysis", "check_security_scan", "check_test_adequacy", "check_review_verdict", "check_invariant_conformance", "prepare_review"] })を使って確認してください。