Chachamaru127 Claude Code Harness 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: レビュー結果出力

{
  "schema_version": "review-result.v1",
  "verdict": "APPROVE | REQUEST_CHANGES",
  "reviewer_profile": "static | runtime | browser",
  "calibration": {
    "label": "false_positive | false_negative | missed_bug | overstrict_rule",
    "source": "manual | post-review | retrospective",
    "notes": "観察メモ",
    "prompt_hint": "few-shot に使う要点",
    "few_shot_ready": true
  },
  "critical_issues": [],
  "major_issues": [],
  "observations": [
    {
      "severity": "critical | major | minor | recommendation",
      "category": "Security | Performance | Quality | Accessibility | AI Residuals",
      "location": "ファイル名:行番号",
      "issue": "問題の説明",
      "suggestion": "修正案"
    }
  ],
  "recommendations": ["必須ではない改善提案"]
}

browser review の場合は scripts/generate-browser-review-artifact.sh が browser_mode と route / required artifacts を決め、その後に scripts/write-review-result.sh で .claude/state/review-result.json に正規化して保存する。 このファイルは commit guard と後続フローの共通入力になる。 calibration が付くレビュー結果は scripts/record-review-calibration.sh で .claude/state/review-calibration.jsonl に追記し、scripts/build-review-few-shot-bank.sh で few-shot bank を更新する。

Step 3.5: --dual フラグ時の Codex 並行レビュー

--dual フラグが指定されている場合、Step 3 の Claude レビューと並行して Codex レビューを実行し、結果をマージする。

1. Codex の利用可否を確認する（scripts/codex-companion.sh setup --json）
2. 利用可能であれば scripts/codex-companion.sh review --base "${BASE_REF:-HEAD~1}" を起動
3. 両方の verdict を Verdict マージルールで統合する
4. 最終レビュー結果に dual_review フィールドを付加する

詳細な手順・出力スキーマ・フォールバック仕様は ${CLAUDE_SKILL_DIR}/references/dual-review.md を参照。

Step 3.6: --security フラグ時のセキュリティ専用レビュー

--security フラグが指定された場合、通常の 5 観点レビューを スキップし、セキュリティ専用フローを実行する。

Read-only 制約: このフロー中は Write / Edit / 書き込み系 Bash を一切実行しない。

1. セキュリティプロファイルを読み込む:

   Read: ${CLAUDE_SKILL_DIR}/references/security-profile.md
   

2. OWASP Top 10 全カテゴリを変更差分・関連ファイルに対して確認する
3. 認証・認可フロー、秘密情報取り扱い、依存パッケージ脆弱性をチェックする
4. reviewer_profile: "security" を設定して結果を出力する（Step 3 の JSON スキーマに準拠）
5. Security モードの verdict 判定基準（security-profile.md 末尾参照）を適用する

通常の Code Review と --security の使い分け:

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 — レビュー通過後にリリース

Converted and distributed by TomeVault — claim your Tome and manage your conversions.