github-pr-reply-guardlisted

# GitHub PR Reply Guard ## Goal PR review thread への返信誤爆を防ぎ、返信結果を検証可能な形で残す。 ## Workflow 1. PR と対象コメントを特定する - 入力として PR 番号と対象コメント URL かコメント本文を受け取る。 - URL がある場合は `discussion_r<id>` から候補 ID を抽出する。 2. Review comment の一次情報を取得する - 必ず `gh api repos/<owner>/<repo>/pulls/<pr>/comments` を使い、`id`, `in_reply_to_id`, `path`, `body`, `html_url` を取得する。 - `pull_request_read.get_review_comments` のみで完結させない。ID が欠落する可能性がある。 - URL が `discussion_r<id>` の場合も、最終的な親 comment ID はこの一覧で確定する。 3. 返信先 ID を確定する - 優先順位: - `html_url` 完全一致 - `id` 一致 - `path` + 本文冒頭一致（最終手段） - 候補が複数ある場合は推定返信しない。候補一覧を出してユーザー確認する。 - GraphQL fallback を使う可能性があるため、必要なら review thread ID も取得する。 - `reviewThreads { nodes { id comments { nodes { databaseId url } } } }` - `databaseId == parent comment id` を含む thread を返信先 thread とする。 4. 返信を投稿する - 既定は review comment への reply API を使う。 - ただし `user_id can only have one pending review per pull request` などで REST reply API が失敗した場合は、GraphQL の `addPullRequestReviewThreadReply` を使う。 - reply body は `\n` 文字列を埋め込まない。actual newline を渡す。 - 推奨: here-doc で body を組み立てて `-F body="$body"` で渡す - 非推奨: `-f body='line1\n\nline2'` 5. 投稿結果を検証する - REST reply API を使った場合: - 返却の `in_reply_to_id` が意図した親コメント ID と一致することを確認する。 - GraphQL thread reply を使った場合: - 返却の `comment.url` を記録する。 - thread 再取得で、意図した thread に reply が追加されていることを確認する。 - `author`, `body`, `url` を再取得して thread 取り違えがな��ことを確認する。 - `html_url` または `comment.url` を必ず記録して、ユーザーへ共有する。 ## Guardrails - 推測 ID で返信しない。 - PR 全体コメント (