review-it

レビュー

1. ピン留め

影響を受けるチェックを実行し、新しいファイルも含めてすべてコミットし、対象ブランチを取得して、<merge-base with origin/<target>>..HEADをピン留めします。レビュアーが確認している間、HEADは固定したままにします。

対象ブランチをレビュー中のブランチにマージまたはリベースしても、レビュー対象のコードは変わらないため、PR独自の変更に変化がなければ再レビューは不要です。land-itはツリーを比較してこれを確認します。PR独自の変更が変わった場合にのみ、再度レビューします。

意図と受け入れ基準を、チャットのみのものも含めて書き留め、変更を作成したモデルファミリーを記録します。委任されたワーカーも対象です。write-prのVisible:の値を決めます。変更によってユーザーが見る、または使う画面が変わる場合はyesです。yesの場合は、ピン留めしたHEADからwrite-prのスクリーンショットを今すぐ撮影し、レビュアーがそれを評価できるようにします。動画は修正後、マージするHEADで一度だけ記録します。

2. グレード

• skip：ドキュメント、コメント、文言のみの場合。実行されるコードもエージェントへの指示もありません。
• high：具体的な危険性を示せる場合。差分によって認証、権限、支払い、シークレット、マイグレーション、保存データの動作が変わる場合、またはリバートでは元に戻せない形で公開コントラクトや保存形式が変わる場合です。これらの領域にあるファイルでも、動作が変わらないなら危険性には該当しません。
• standard：それ以外のすべての変更です。影響するファイルやサブシステムの数は問いません。

具体的なhighの危険性を示せない限り、グレードはstandardです。ユーザーが指定したグレードは下限として扱います。skipの場合は、直接レシートに進みます。グレードはレビュアーの作業量を決めます。land-itがユーザーの介在なしにマージするかどうかは、グレードではなくwrite-prのDoor行で決まります。リバートでは元に戻せないhighの危険性がある場合、PRはDoor: one-wayになります。

3. レビュー

ピン留めした範囲に対して、interrogateを一度実行します。pstack-models.mdのinterrogate reviewers行から2人のレビュアーを並行して選び、t3-capacityでモデルを解決します。まず、リードモデルが変更を作成していない席から始め、モデルのキャパシティが不足している場合は各席で次のティアに進みます。standardではレビュアーをhighで、highではxhighで実行します。各ブリーフには、意図と受け入れ基準、ピン留めした範囲、レビューブリーフの絶対パス、ワークツリー、仕様書、イシュー、リポジトリの指示ファイルのパス、およびVisible:の値を記載します。noとされているのに変更によってユーザーが見る、または使う画面が変わるとレビュアーが判断した場合は、指摘として報告します。yesの場合、各ブリーフにはデモのパスと、ユーザーが承認したプロトタイプがある場合はそのプロトタイプも記載し、frontend-designやemil-design-engなど、インストール済みのデザインスキルを使って、ユーザーの視点からデモを評価するよう依頼します。プロトタイプに合っているか、余計な要素、欠落した要素、位置ずれのある要素、不均等な間隔、ユーザーに不要なテキスト、壊れて見える状態がないかを評価してもらいます。Act Onの指摘が、対処する指摘です。適用しないConsiderの指摘は、理由を添えてrejectedとして扱い、レシートにすべての意見の相違が表示されるようにします。Dismissedの項目はレビュアー自身による却下であり、どこにも計上されません。

各レビュアーには、読み取り専用のブリーフを使い、ランタイムモードfull-accessのdelegate_taskを通じて参加してもらいます。ヘッドレス実行では承認する人がいません。行に記載されたすべてのモデルがキャパシティ不足の場合は、ブロッカーとして報告します。サブエージェントのようにdelegate_taskを利用できない場合（parent_not_activeなど）は、ピン留めした範囲をブロッカーとして親に返します。レビュアーの手配後はターンを終了します。完了通知によって再開されます。

ピン留めしたHEADについて実質的な判定が返れば、レビューは完了です。参加を断られた場合、クォータエラー、結果が空の場合は、レビュアーを改めて手配します。~/.agents/skills/poteto-mode/references/t3-execution.mdの説明に従い、すべてのGrok席で実行の_停滞_がないか確認します。停滞した席の最終判定もレビューとして数えます。具体的なhighの危険性を示す指摘があれば、レシート上のグレードをhighに引き上げますが、レビューラウンドは追加しません。リバートでは元に戻せない危険性を示す指摘があれば、その危険性を取り除く修正を行わない限り、Door: one-wayに設定します。

4. 修正

指摘事項を検証して重複を除き、構造の簡素化も含め、スコープ内の妥当なものを一括で適用します。指摘事項によって生じる設計上の判断は自分で決定し、その選択を PR の「What and why」に記録します。新たな設計が必要な修正、または差分が約 2 倍になる修正は、今回の差分における正確性またはセキュリティのバグでない限り、理由を follow-up #<issue> として後続の課題にします。

影響を受けるチェックを再実行してコミットします。ユーザーが目にする画面を変更する修正を行った場合は、変更した画面のスクリーンショットだけを撮り直し、指摘事項と照らし合わせて自分で確認します。その後、必要に応じて、マージされる HEAD のデモをユーザーが承認できるよう、最終 HEAD から write-pr の動画を記録します。

各修正を指摘事項と照らし合わせて自分で確認し、コミットしてください。修正によって、指摘事項に記載されていた範囲を超えて動作が変更された場合に限り、確認レビューを実施します。interrogate reviewers の行から high の新しいレビュアーを 1 人選び、できれば修正を書いていないレビュアーに、以前の指摘事項とともに、最後にレビューされた HEAD から新しい HEAD までの修正範囲だけを読んでもらいます。その妥当な指摘事項を適用し、確認して、コミットします。この確認レビューを 1 回行った後も未修正の正確性およびセキュリティに関する指摘事項は open として扱い、ユーザーに引き渡します。PR に対する全体レビューは 1 回だけです。確認レビューでは修正箇所のみを読みます。

5. 結果の記録

write-pr の Review セクションに記載する以下の行を返し、ブロッカーがあれば、その次の手順も記載します。land-it が解析するため、形式を正確に保ってください。rejected はレビュアーが挙げ、作成者が却下した指摘事項の数です。open はユーザーに引き渡した指摘事項、ブロッカー、および判定を返さなかった担当者の数です。reviewed には、ベースブランチと、最後のレビューで対象となった HEAD を記載します。確認レビューを行わなかった場合は、指摘事項に照らして確認した修正後の HEAD を記載します。

**Review.** <skip | standard | high> by <models>; <n> fixed, <n> rejected, <n> open; reviewed <short SHA> on <base branch>

その下に、却下した指摘事項ごとに 1 行記載します。

- Declined: <finding> (raised by <model>): <specific reason>

その指摘事項を挙げたすべてのモデル名を記載してください。2 人のレビュアーが挙げた指摘事項は却下できません。修正するか、open のままにしてください。正確性またはセキュリティのバグでない場合は、理由を follow-up #<issue> として後続の課題にできます。