review-reply

name	review-reply
description	review-fixで対応したコミットをpushし、各レビューコメントのスレッドに対応内容を返信する。
disable-model-invocation	true
allowed-tools	Bash(git:*), Bash(glab:*), Read, Grep, Glob

Merge Request レビューコメントへの返信

レビューコメントへの対応（コード修正・コミット）が完了した状態で、変更をpushし、各レビューコメントのスレッドへ対応内容を返信する。

手順

1. 情報収集（並列実行）

以下を並列で実行する:

• git status — 現在のブランチ名とリモートとの差分コミット数を確認
• git log --oneline @{upstream}..HEAD — 未pushのコミット一覧を取得（upstreamが未設定の場合は origin/main..HEAD）
• glab mr list --source-branch $(git rev-parse --abbrev-ref HEAD) — 現在のブランチに紐づくMRを特定
• git remote -v — リモート情報を取得

検証

• 未pushのコミットが0件の場合は「pushするコミットがありません」と通知して終了
• MRが見つからない場合は「MRが見つかりません」と通知して終了
• 複数のMRがある場合はユーザーに選択してもらう

2. レビューコメントの取得

glab api でMRのノートを取得する:

glab api projects/<project-path>/merge_requests/<mr-iid>/notes

• <project-path> はリモートURLから判別する（/ は %2F にエンコードする）
• "system": true のノートは除外する
• "type": "DiffNote" のものがレビューコメントである
• レビューコメントが0件の場合は、pushのみ行うかユーザーに確認する

3. コミットとコメントの対応付け

未pushのコミット一覧とレビューコメントの内容を分析し、どのコミットがどのレビューコメントに対応しているかを推定する。

対応付けの判断基準:

• コミットメッセージの内容とコメントの body の関連性
• コミットで変更されたファイルとコメントの position.new_path の一致

対応付けの結果をユーザーに表形式で提示し、確認を取る:

レビューコメント	ファイル	コメント内容	対応コミット
Note #ID	パス	bodyの要約	コミットハッシュ + メッセージ

4. push

確認が取れたらリモートにpushする:

git push origin <current-branch>

5. レビューコメントへの返信

各レビューコメントのディスカッションスレッドに返信する。

5-1. ディスカッションIDの取得

glab api projects/<project-path>/merge_requests/<mr-iid>/discussions

レスポンスから各ノートIDに対応するディスカッションIDを特定する。

5-2. 返信の投稿

各ディスカッションに対して返信を投稿する:

glab api --method POST projects/<project-path>/merge_requests/<mr-iid>/discussions/<discussion-id>/notes -f body="<返信内容>"

返信メッセージのフォーマット:

<対応内容の要約>（コミット: <short-hash>）

• 返信内容は日本語で簡潔に書く
• 対応コミットのショートハッシュを含める
• 複数コミットで対応した場合はすべてのハッシュを記載する

6. 完了報告

すべての返信が完了したら、結果を表形式でユーザーに報告する:

コメント	ファイル	コメント内容	対応	返信内容
Note #ID	パス	bodyの要約	コミットハッシュ	投稿した返信の要約

次のアクションをサジェストする:

• /review-fix — 追加のレビューコメントが付いたらコードを修正
• /resolve-conflicts — コンフリクトが発生した場合に解消
• /sync-main — MRがマージされたらmainに切り替えて後片付け

注意事項

• 未コミットの変更がある場合は、先にコミットするようユーザーに案内する
• 対応するコミットが見つからないレビューコメントがある場合は、ユーザーに確認する
• 返信内容の投稿前に、内容をユーザーに確認する必要はない（対応付けの確認を手順3で済ませているため）
• review-fix スキルでコード修正を行った後に、このスキルでpush・返信するのが典型的なワークフロー