Pattern declaration

Primary pattern: Reviewer Secondary patterns: Inversion Why: レビューコメントの重要度分類と対応方針整理がチェックリスト型の主タスクだが、レビューコメントが存在しない場合は実行不要

Review Comment Triage (No-Code-Fix Mode)

Pre-execution Gate / 実行前ゲート

このスキルは以下の条件がすべて満たされない限りNO_REVIEWを返す。

• PRにレビューコメント（issueコメントまたは行コメント）が存在する
• inputContextにdiffが含まれている

ゲート不成立時の出力: NO_REVIEW: review-comment-triage — トリアージ対象のレビューコメントが検出されない

AI はコード修正や具体的なパッチ提案をしてはいけない。コメント整理・重要度付け・対応方針（自然言語）・返信案だけを出力すること。 すべての出力と返信文案は日本語で行うこと。PR 本文（説明）と PR コメントの文案も日本語で書く。レビューコメントが英語でも、日本語で整理・回答する。

重要度 (severity) の基準

• critical: セキュリティ/データ損失/システム障害につながる恐れ。必ず修正。
• major: 保守性・信頼性・性能を大きく損なう恐れ。開発サイクル内で修正が望ましい。
• minor: 軽微なコードスメル/スタイル/小さなリファクタ。品質維持のためにそのうち修正。
• info: 情報提供・学び・将来改善の示唆。今すぐのアクションは不要。

対応状況 (status) の基準

• 対応済み: 差分やスレッド返信から明確に対応が確認できる場合のみ。
• 未対応: 対応が見当たらない場合。
• 要確認: 情報不足や判断が曖昧な場合。Outdated/折り畳みなどで不明な場合もここに倒す。

手順

1. コメント取得・件数確認
   • 取得した全コメント（issue＋行コメント）を対象にし、件数を明示する。
   • 取得漏れの疑いがあれば警告し、該当を「要確認」に倒す。
2. コメント一覧の作成
   • ID: C1, C2… の連番。種類（全体/行）、ファイルパス・行番号（不明なら「-」）、原文、スレッド状況（返信有無など）をテーブル化。
3. 重要度＋対応状況の付与
   • severity を critical/major/minor/info から選び、status を 対応済み/未対応/要確認 から選ぶ。根拠を必ず書く。
4. 未対応・要確認への対応方針（自然言語のみ）
   • 具体コードやパッチは禁止。何をどう見直すか、観点レベルで示す。必要なら「チームで相談」など補足。
5. 対応済みコメントの返信案
   • 対応内容を自然言語で要約し、丁寧な返信文案を日本語で作る（コードなし）。
6. 総括
   • 件数集計（総数/Severity別/Status別）。取得漏れリスクがあれば明示し、該当 ID を「人間による最終確認が必要」と書く。開発者への次アクションを添える。

出力フォーマット

このスキルの出力は “スレッド整理と返信案” が目的です。以下のルールで短く出力します。

• すべて日本語。
• コード修正やパッチ提案は禁止（自然言語のみ）。
• 1 行 = 1 コメント（または総括）として、<file>:<line>: <message> 形式で出力する。
  • 行コメントなら <file>/<line> を使う。
  • 場所が特定できない場合は (summary):1: や (pr-comment):1: のような形式を使う（:1 は形式を合わせるための固定値）。
• <message> には severity と status を含め、対応方針/返信案を短く書く。

例:

• (summary):1: 合計 5 件（未対応 2 / 要確認 1 / 対応済み 2）
• src/foo.ts:42: [severity=major][status=未対応] 方針: 例外握りつぶし回避を検討。返信案: 修正方針を共有します。

評価指標（Evaluation）

• 合格基準: 指摘が差分に紐づき、根拠と次アクションが説明されている。
• 不合格基準: 差分と無関係な指摘、根拠のない断定、抑制条件の無視。

人間に返す条件（Human Handoff）

• 仕様や意図が不明確で解釈が分かれる場合は質問として返す。
• 影響範囲が広い設計判断やトレードオフは人間レビューへ返す。