Harness Review

Harness Review (v3)

Harness v3 の統合レビュースキル。 以下の旧スキルを統合:

• harness-review — コード・プラン・スコープ多角的レビュー
• codex-review — Codex CLI によるセカンドオピニオン
• verify — ビルド検証・エラー復旧・レビュー修正適用
• troubleshoot — エラー・障害の診断と修復

Quick Reference

レビュータイプ自動判定

Code Review フロー

Step 1: 変更差分を収集

# BASE_REF が harness-work から渡された場合はそれを使用、なければ HEAD~1 にフォールバック
CHANGED_FILES="$(git diff --name-only --diff-filter=ACMR "${BASE_REF:-HEAD~1}")"
git diff ${BASE_REF:-HEAD~1} --stat
git diff ${BASE_REF:-HEAD~1} -- ${CHANGED_FILES}

Step 1.5: AI Residuals を静的走査

LLM の印象だけで判定せず、再実行できる形で残骸候補を拾う。scripts/review-ai-residuals.sh は stable な JSON を返すので、その結果をレビュー根拠として使う。

# 差分ベース
AI_RESIDUALS_JSON="$(bash scripts/review-ai-residuals.sh --base-ref "${BASE_REF:-HEAD~1}")"

# 対象ファイルを明示したい場合
bash scripts/review-ai-residuals.sh path/to/file.ts path/to/config.sh

Step 2: 5観点でレビュー

Step 2.2: AI Residuals の severity 判定表

AI Residuals は、まず scripts/review-ai-residuals.sh の JSON を確認し、その後に diff 文脈で「本当に出荷リスクか」を最終判断する。

Step 2.5: 閾値基準による verdict 判定

各指摘を以下の重要度に分類し、この基準のみで verdict を決定する。

重要: minor / recommendation のみの場合は 必ず APPROVE を返すこと。 「あったほうが良い改善」は REQUEST_CHANGES の理由にならない。 AI Residuals でも同じ。major に入るのは「出荷事故や誤設定に直結しやすいもの」だけで、単なる残骸候補は minor または recommendation に留める。

Step 3: レビュー結果出力

{
  "verdict": "APPROVE | REQUEST_CHANGES",
  "critical_issues": [],
  "major_issues": [],
  "observations": [
    {
      "severity": "critical | major | minor | recommendation",
      "category": "Security | Performance | Quality | Accessibility | AI Residuals",
      "location": "ファイル名:行番号",
      "issue": "問題の説明",
      "suggestion": "修正案"
    }
  ],
  "recommendations": ["必須ではない改善提案"]
}

Step 4: コミット判定

• APPROVE: 自動コミット実行（--no-commit でなければ）
• REQUEST_CHANGES: critical/major の指摘箇所と修正方針を提示。harness-work の修正ループで自動修正後に再レビュー（最大 3 回）

Plan Review フロー

1. Plans.md を読み込む
2. 以下の 5 観点 でレビュー:
   • Clarity: タスク説明が明確か
   • Feasibility: 技術的に実現可能か
   • Dependencies: タスク間の依存関係が正しいか（Depends カラムと実際の依存が一致しているか）
   • Acceptance: 完了条件（DoD カラム）が定義され、検証可能か
   • Value: このタスクはユーザー課題を解くか？
     • 「誰の、どんな問題」が明示されているか
     • 代替手段（作らない選択肢）は検討されたか
     • Elephant（全員気づいているが放置されている問題）はないか
3. DoD / Depends カラムの品質チェック:
   • DoD が空欄のタスク → 警告（「完了条件が未定義です」）
   • DoD が検証不能（「いい感じ」「ちゃんと動く」等） → 警告 + 具体化提案
   • Depends に存在しないタスク番号 → エラー
   • 循環依存 → エラー
4. 改善提案を提示

Scope Review フロー

1. 追加されたタスク/機能をリスト化
2. 以下の観点で分析:
   • Scope-creep: 当初スコープからの逸脱
   • Priority: 優先度は適切か
   • Feasibility: 現在のリソースで実現可能か
   • Impact: 既存機能への影響
3. リスクと推奨アクションを提示

異常検知

Codex Environment

Codex CLI 環境（CODEX_CLI=1）では一部ツールが利用不可のため、以下のフォールバックを使用する。

検出方法

if [ "${CODEX_CLI:-}" = "1" ]; then
  # Codex 環境: Plans.md ベースのフォールバック
fi

Codex 環境でのレビュー出力

Task ツール非対応のため、レビュー結果は標準出力にマークダウン形式で出力する。 Lead エージェントまたはユーザーが結果を読み取り、次のアクションを判断する。

関連スキル

• harness-work — レビュー後に修正を実装
• harness-plan — 計画を作成・修正
• harness-release — レビュー通過後にリリース