harness-review

name	harness-review
description	エージェントハーネス（ツール設計・コンテキスト管理・マルチエージェント構成・失敗設計）の設計をレビューし、重大度付きの指摘を出すスキル。設計書・構成ドキュメント・リポジトリを入力に、7観点のチェックと根拠付き指摘・良い点・情報不足を報告する。「ハーネス設計をレビューして」「エージェント構成のレビュー」「この構成で暴走しないか見て」「マルチエージェント設計の妥当性確認」と言われたとき、またはエージェントシステムの実装前・本番化前の設計確認で使用。

ハーネス設計レビュー（harness-review）

エージェントハーネスの設計を7観点でレビューし、事故につながる欠陥を実装前・本番化前に検出する。 FeelFlow の書籍『ハーネスエンジニアリング』『AIマルチエージェント開発』『AIオーケストレーター』の方法論を蒸留したもの。

成果物

harness-review-{対象slug}-{YYYYMMDD}.md（YYYYMMDD はレビュー実施日＝実行日〔実行環境のローカルタイムゾーン〕）— 以下の構成:

1. レビューサマリー（対象・スコープ・総合所見〔3〜5行〕・指摘件数の内訳。直下にメタ情報欄〔入力の種類・slug の由来〕）
2. 指摘一覧（重大度順。各指摘に: ID〔C-1/W-1/S-1 形式〕 / 該当箇所〔設計書のセクション・ファイル〕 / 問題 / 根拠〔観点とアンチパターン名〕 / 何が起きるか / 推奨対応）
3. 観点別チェック結果（7観点 × 判定〔OK / NG / 情報不足 / 対象外〕の表。NG は指摘 ID、情報不足は HR-n を参照）
4. 良い点（保持すべき設計。誤検知でないことの証跡にもなる）
5. 情報不足・確認事項リスト（ID 採番〔HR-1, HR-2, …。本文出現順〕。設計書に書かれていない事項を「未実装」と断定せずここへ。それぞれ「誰に確認するか」の提案付き）

※ 設計レビューのスキルであり、修正の実装・設計書の書き直しは対象外（推奨対応の提示まで）。

参照ファイル（progressive disclosure）

ファイル	読むタイミング
references/review-criteria.md	レビュー実施時（Step 2）。7観点のチェックリストと重大度判定基準
references/antipattern-catalog.md	指摘の裏付け時（Step 3）。検出サイン→影響→推奨対応のカタログと「良い設計のサイン」

実行手順

Step 1: 対象とスコープの確認

1. レビュー対象（設計書のパス / リポジトリのディレクトリ / 構成説明）を確認して読む
2. スコープを確認する: 設計書のみか、実装コードも含むか（不明なら渡された入力の範囲のみとし、メタ情報欄に明記）
3. 対象 slug: 対象システム・プロジェクト名から導出する（英語名はそのまま kebab-case、日本語名は法人格等を除いた読みのヘボン式ローマ字 kebab-case〔長音は省略（しょう→sho・ちゅう→chu・おう→o）、促音は子音重ね〕。読みが不明な場合は最も一般的な読みで「読みは推定」と明記）

Step 2: 7観点チェック

references/review-criteria.md を読み、観点1〜7 を順に検査する。

• 各チェック項目を OK / NG / 情報不足 / 対象外 の4値で判定する
• 設計書に書かれていないことを「未実装」と断定しない。書かれていない、または「別途検討」等と詳細未定が明記されている事項は情報不足として HR-n に送る（未定の明記自体は誠実さであり指摘対象ではない。記載も言及もないまま運用開始する設計は観点6で NG にできる）
• 例外（HR に逃がさない）: 自律稼働・本番運用・副作用のある操作（送信・書き込み・削除）が設計に明記されているのに、安全系の必須制御（停止条件・リトライ上限・タイムアウト・承認ゲート）の記載がない場合は、情報不足ではなく NG（重大度は review-criteria の基準どおり Critical〜Warning）とする。安全制御の不在は「未定」では済まない
• 判定に使った該当箇所（セクション名・引用）を記録する

Step 3: 指摘の作成

references/antipattern-catalog.md を参照し:

1. NG 項目を指摘に起こす。各指摘に**根拠（観点番号 + 該当するアンチパターン名）**と「何が起きるか」「推奨対応」を付ける
2. 重大度（Critical / Warning / Suggestion）を review-criteria の基準で判定する。事故直結（停止不能・無限リトライ・全権限・無承認の破壊的操作）は Critical
3. 好みの問題（命名・書式・文体）は指摘しない
4. 「良い設計のサイン」に該当するものを指摘にしない。良い点セクションに記録する（単純さを保った構成・段階導入・やらないことの明記などは美点であり欠陥ではない。ただし段階導入の拡大段階で承認ゲートを全廃する計画は美点に含めない）

Step 4: レポート生成と保存

「成果物」構成でレポートを生成し保存する。

• 保存先: ユーザー指定の場所。指定がなければカレント作業ディレクトリに保存しパスを報告する
• 対話できない場合（バッチ実行等）:
  • 対象・スコープの不明点は問い合わせずに、渡された入力の範囲でレビューし、前提をメタ情報欄に明記する
  • 確認事項の「誰に確認するか」は役割名（設計責任者・運用責任者等）で書く（実名・組織構成を推測しない）
  • 保存後の案内文は、確認事項リストの後に番号なしの付録節「次のアクション」として成果物末尾に追加する（文書として自然な文面に書き直す。この場合、下記のチャットでの案内は不要）
• 指摘は設計者が読んで行動できる粒度で書く（抽象的な「検討が必要」で終わらせない）

対話できる場合は、保存後にユーザーへ以下を案内する:

レビューレポートを保存しました。Critical 指摘は実装前の解消をおすすめします。「情報不足・確認事項リスト」は設計書の追記対象の候補です。構成設計書そのものの作成が必要であれば genai-consultant の architecture-doc スキルと組み合わせられます。

注意事項

• 保存前のセルフチェック: 本スキルの ID リスト（未確定・未合意・未確認・未解決・確認事項）の全 ID が、リスト自身を除く本文に少なくとも1回出現することを確認する（双方向参照の破れ防止）
• 入力にない事実を捏造しない。設計書にない実装詳細・運用実態を推測して指摘の根拠にしない（情報不足として扱う）
• 指摘には必ず根拠と推奨対応を付ける。「なんとなく危ない」という指摘を書かない
• レビューの目的は設計の改善であり、指摘件数を稼ぐことではない。同根の問題（同じ設計判断に由来するもの）は1つの指摘にまとめてよい。分割・統合のどちらでも、重大度と該当箇所が明確であれば可
• 良い点の記録を省略しない（何を保持すべきかはレビューの成果物の一部）
• 本スキルの方法論の出典は references/ 各ファイル末尾の「出典」セクションを参照