レビュー・修正依頼・コミット

in_review 状態のタスクについて、変更内容をレビューし、合格したらコミットする。

引数

• 第1引数: タスクID。省略時は state.json の最初の in_review タスク

手順

1. レビュー材料の収集

• git diff / git status で変更全体を取得
• tasks.md の該当タスク(受け入れ基準)を読む
• .agents/workflow/runs/<タスクID>-<試行回数>/report.md(最新の試行回数のもの)の完了報告(テスト結果を含む)を読む

2. テスト結果の検証(親は実行せず報告を検証する)

テストの実行は子エージェントの責務。親は以下で報告の信頼性を検証する:

• 完了報告にテストコマンドと結果(全件パス)が明記されているか
• タスクがテスト追加・変更を要求している場合、diff にテストコードが含まれているか
• 報告内容と diff に矛盾がないか(例: 「○○を修正」と報告しているのに該当ファイルに変更がない)
• 子の「既存エラー」報告は鵜呑みにせず、必ず親側で再実行して検証すること(増分コンパイル不整合による誤診の可能性があるため)

報告が欠落・曖昧・矛盾している場合は不合格とし、「テストを実行し結果を報告せよ」を
指摘事項に含めて手順4へ。

3. コードレビュー

受け入れ基準を1項目ずつ diff と照合し、加えて以下の観点で確認する:

• 正しさ: ロジックの誤り、エッジケース、エラーハンドリング
• スコープ: タスク外の無関係な変更が混入していないか
• 規約: AGENTS.md・周辺コードのイディオムとの整合
• セキュリティ: 入力検証、秘密情報のハードコード等

判定は 合格 / 不合格(指摘事項リスト付き) の二択で出す。

4. 不合格時: 修正依頼

不合格の原因(コードレビュー指摘 / 品質ゲート FAIL)にかかわらず、同一タスクの
修正依頼は state.json の同じ retries カウンタを消費する(上限は max_fix_retries)。
修正依頼には不合格の原因種別を明記すること。

state.json の retries を確認し(状態の更新はすべて task-state スクリプトで行い、
state.json を直接編集しない):

• retries < max_fix_retries(config.json): 指摘事項をまとめて 子エージェントに再依頼する。
  再依頼の前に、指摘事項リストを runs/<タスクID>-<次の試行回数>/fix-notes.md に
  親が保存する(ここだけは親のLLM出力。要件の例外事項)。「次の試行回数」とは
  現在の試行回数+1であり、例えば試行1が不合格なら runs/<タスクID>-2/fix-notes.md に
  保存する(/agent-dispatch <タスクID> を -Attempt <次の試行回数> でリトライ実行した際、
  生成スクリプト dispatch-prompt-gen がこのファイルを読み込んでプロンプト冒頭に結合する。
  ファイルが無い状態で -Attempt 2 以上を実行すると dispatch-start が止まる。前の試行の変更が
  作業ツリーに残っていれば exit 20 reason=dirty-tree で stderr に fix-notes.md not found を出し、
  作業ツリーがクリーンなら exit 43 reason=prompt-gen になる)。
  fix-notes.md にはタスク固有の指摘だけを書き、一時ファイルの置き場所・管理ファイルの扱い・
  プロジェクト外の禁止など、dispatch-prompt-template.md の「実装ルール」が定める事項を
  書き直さない(言い回しの違いが矛盾に見え、子が迷うため。規則は実装ルールの1か所に置く)。
  指摘が複雑でテンプレートに収まらない場合は、fix-notes.md を作らず、親が
  runs/<タスクID>-<次の試行回数>/prompt.md を直接作成して生成スクリプトをバイパスしてよい
  (/agent-dispatch §1 のフォールバック手順に準ずる)。
  再依頼の前に task-state <タスクID> retry を実行する(retries を +1 して status を
  in_progress に戻す)。その後 /agent-dispatch <タスクID> をリトライモードで実行する
  (修正後のテスト再実行も指示に含まれる)

  .agents/workflow/scripts/task-state.ps1 T1 retry

  .agents/workflow/scripts/task-state.sh T1 retry

  task-state が exit 4(retries が max_fix_retries に達している)を返した場合は
  再依頼せず、下の「上限超過」に進む
• 上限超過: 親のサブエージェントまたは親自身で修正する。それでも受け入れ基準を
  満たせない場合は task-state <タスクID> fail で status を failed にし、経緯をまとめて
  ユーザーにエスカレーションする(ユーザー判断でやり直す場合は task-state <タスクID> reset
  で pending に戻す)

5. 合格時: 品質ゲートと理解確認質問の生成

(手順5.1 の品質ゲートで FAIL(blocking) になった場合はここから不合格に転じ、手順4へ戻る)

1. config.json の verify_before_commit が true の場合のみ、最終ゲートとして
   親が品質ゲートを1回実行する:
   • quality_gate が定義されていれば /agent-quality-gate(quality-gate スクリプト)を実行する。
     typecheck/lint/test をまとめて検証し、blocking ステップの失敗のみ不合格
     (Next: escalate reason=quality-gate が FAIL(blocking))
   • non-blocking ステップの失敗が formatter/linter の自動修正で解消できる見込みが
     ある場合は、コミット前に --fix 付きで再実行してもよい(自動修正で生じた
     差分もコミット対象に含め、報告に明記する)
   • 未定義なら従来どおり test_command を1回実行する
   • FAIL(blocking)なら不合格扱いで手順4へ。non-blocking の失敗は
     コミット可だが、報告の「残課題」に品質ゲートの結果を必ず記載する
2. config.json の comprehension_check.enabled が true の場合のみ、理解確認質問を生成する
   (質問ファイルを手順6の task-commit が行う状態ファイルのコミットに含めるため、
   コミットの前に行う):
   1. .agents/workflow/comprehension/ ディレクトリがなければ作成する
   2. レビューで把握済みの diff・受け入れ基準・完了報告のみから質問を生成する(追加のファイル読み込みは行わない)
   3. 質問数は comprehension_check.questions_per_task に従う
   4. 以下の観点テンプレートからバランスよく質問を作成する:
      • 設計判断: なぜこの実装方針か、トレードオフ
      • 動作の仕組み: 変更したコードの処理フロー、エッジケース
      • 依存の理解: 実装で利用した既存モジュール・外部ライブラリ・フレームワーク機能について、その大まかな役割と仕組み
      • 影響範囲: この変更が他のどこに影響しうるか
   5. agent-comprehension-check/SKILL.md の質問ファイルフォーマットに従い、
      .agents/workflow/comprehension/<タスクID>.md に保存する
      • 質問ファイルに ## 解説 見出しは含めない(未解説判定のため)
   6. 保存したファイルパスを会話に出力する

6. 合格時: コミット(task-commit)

task-commit を実行する(PowerShell: .agents/workflow/scripts/task-commit.ps1 -TaskId <ID> -Type <type> -Description "<説明>" /
POSIX: .agents/workflow/scripts/task-commit.sh <ID> <type> "<説明>")。
親が決めるのは type(conventional commits の type)と説明(タスクタイトルに基づく1行)だけ。
説明は .agents/workflow/runs/refine/commit.md に書き、agent-workflow/references/report-template.md の
「日本語の推敲」の手順(場面 commit)で推敲してから task-commit に渡す(type は推敲しない)。
次の処理はスクリプトが行う:

• branch-check(コミットしてよいブランチかの判定)
• 本体コミット(ワークフロー状態ファイルを除く。タスク単位で1コミット)
• task-state done(status を done にし、commit を記録)
• 状態ファイル(state.json・tasks.md・comprehension ファイル等)の chore コミット

出力の最後の行が Next: continue 以外なら、コミットが済んだと見なさず中断し、
Next: 行の reason と stderr の内容をユーザーに報告する。
Next: continue の場合、進捗表示用のタスクを登録していれば(agent-task-plan §4。任意)完了に更新する。

ユーザーへの報告

• 報告・説明はすべて日本語で行うこと(AGENTS.md の再掲。このskillは実行のたびに
  読み込まれるため、ここに明記しておくことで日本語指定の効きを強くする)
• 報告の書き方は agent-workflow/references/report-template.md に従う(状況・起きたこと・次にすること。
  内部語は言葉に直し、必要なら括弧で補足してよい)。この skill では次の場面を使う
• レビュー結果(手順3完了時。テンプレートの「レビュー結果」)に入れる事実:
  • 合格 / 不合格の判定
  • 不合格の場合は指摘事項の件数と概要(原因種別: コードレビュー指摘 / 品質ゲート FAIL)
• コミット完了時(手順6完了時。テンプレートの「コミット完了」。task-commit の出力から)に入れる事実:
  • コミットハッシュ
  • コミットメッセージ(タイトル行)
  • 品質ゲートの結果(non-blocking の失敗があれば残課題として明記)
  • 状態ファイルを別コミットにした場合は、そのハッシュ(追跡しないリポジトリでは書かない)
• 修正再依頼時(手順4)に入れる事実:
  • 現在の retries 回数 / max_fix_retries
  • fix-notes.md の保存先パス(または直接作成した prompt.md のパス)