PRに「Storyで見出しが切れます」とコメントが付いた。エージェントに修正を頼み、コミットが増えた。ここでスレッドを解決済みにしたくなるけれど、レビュー対象が画像なら、まだ肝心のPNGを見ていない。
これは架空のReact/TypeScript製フロントエンドと、告知用画像を同じPRで扱う場合の検収手順だ。製品の動作検証レポートではない。見るべき単位をPR全体ではなく、ひとつのコメントに絞る。
コメントの文面を、再現条件に直す
「切れている」だけだと、CSSの見切れなのか、元画像の文字が切れているのか、Story枠への変換で欠けたのか分からない。レビュアーには、PRコメントに画像の用途と期待値を足してもらう。
指摘: Instagram Story枠で、右端の「登録する」が読めない
対象: このPRで使う告知画像の保存PNG（元画像とは別）
期待: 9:16のプレビューと保存PNGの両方で全文が読める
確認者: 画像を投稿する担当者
サンプル文面であって、実在のPRへのコメントではない。再現には公開できるダミー画像を使う。手元のリポジトリで画像をどう生成・管理するかは、既存の設定とpackage.jsonのscriptsを見てから決める。存在しない画像生成コマンドを手順に足さない。
枠に通してから、修正範囲を決める
横長のダミー画像をInstagram Story用の9:16枠に入れると、Fillでは端が切れ、Fitでは画像全体を残す代わりに余白ができる場合がある。画像準備の段階なら、Resize Image for InstagramでStoryプリセットとFit/Fillを切り替え、プレビュー後にPNGを保存して比べられる。元画像と書き出したPNGは別物として記録する。
ただ、Fitは万能ではない。元画像の時点で文字が端に寄り過ぎていたら、余白を足しても読みやすくなるとは限らない。StoryのUIが重なる場所も含めて、人が保存ファイルを見て判断する。外部のプレビューがよく見えたことを、PR内の成果物が合格したことに読み替えない。
エージェントにはコメントURLと変更範囲を渡す
AmpはGitHub連携について、PRのコメントやレビューを作業スレッドに戻す仕組みを案内している。新しいissue/PRごとにorbを作り、後続コメントを同じスレッドで扱う説明もある。ただし、コメントが届くことと、修正した画像が合格することは別だ。以下の依頼文は製品固有のコマンドではなく、エージェントに渡す作業指示の例。
このPRの「Storyで見出しが切れる」指摘を確認してください。
コメントURLと対象画像を確認し、原因の候補と変更するファイルを先に示してください。
既存の画像生成手順を調べ、修正後は保存PNGのパスと修正コミットを報告してください。
画像の見え方は人が再確認します。コメントの解決とmergeは行わないでください。
変更範囲に余計なファイルが混ざっていないか、PRのFiles changedとコミットで確かめる。CIを使っているなら、そのPRの実際のチェック結果を別に読む。CIの成功だけでは、保存PNGの文字の見切れは分からない。PRや環境によってはエージェントへのイベント配送条件も異なるので、通知・権限設定は導入時に確認したい。
解決済みにする前の記録
コメントの下に「直しました」と返す代わりに、指摘と再確認を同じ行に残す。次は記入前のひな型。架空の成功結果は入れていない。
| 指摘コメントURL | 修正コミット | 再出力したPNG | 再確認者 | 判定 |
|---|---|---|---|---|
| 未記入 | 未記入 | 未記入 | 未記入 | 未確認 |
再確認者は修正前と同じStory枠で新しいPNGを開き、問題の文字を読む。直っていなければ、その画像と条件を添えて同じPRで再度コメントする。合格なら、確認したファイルとコミットを記録してからスレッドを閉じる。コード変更だけ終わって画像が未確認なら、判定も未確認のままにする。
PRコメントをエージェントに届ける仕組みは、修正の着手を早めてくれる。でも、レビューを終える根拠は通知ではなく、指摘された成果物をもう一度見たという記録だ。
参考
- Amp: You've Got Comments — PRへのコメント・レビューを作業スレッドに戻す連携の告知。設定と配送条件は利用環境で確認する。
- GitHub Docs: Reviewing changes in pull requests — PRの変更ファイルやコメントを確認する際の入口。