ship

出荷

目標

マージ可能な状態の、クリーンでレビュー済みの PR に変更を反映します。マージはユーザーが行います。

変更の内容は、作業ツリーにすでにあるローカルの変更、Linear チケット、または実装する内容の説明のいずれでもかまいません。

手順

1. 必要に応じて変更を実装します。 変更がすでに作業ツリーにある場合は、手順 2 に進みます。以前に方針が合意されている場合は、そのとおりに実装します。main を基点に新しい worktree で作業します。すでに worktree にいる場合は、そのまま使います。そうでない場合は、新しく作成します。変更全体を、ひとまとまりの変更としてローカルで実装します。まだ PR のことは考えません。変更全体が動作することを確認します。
   • 作業ツリーに probe スキルで作成したスタブがある場合、それらは合意済みのアーキテクチャです。その構造は変更せず、上に詳細を実装します。実装上、構造の変更が必要になった場合は、ユーザーに伝えます。
2. 変更を PR のスタックに分割します。 変更全体が動作してから分割します。まず、インストールされている場合は、作業ツリーに deslop スキルを適用します。このスキルは AI 生成コードによくあるパターンを取り除き、レビュー担当者がクリーンなコードを確認できるようにします。各 PR では、目に見える単位の変更を 1 つだけ行います。分割が簡単で明確な場合は、分割内容をユーザーに伝えて、そのまま進めます。変更が複雑な場合や、複数の分割方法がある場合は、ユーザーが分割を承認するまで待ちます。判断に迷う場合も待ちます。以下のスタック分割ガイダンスを使用します。
3. PR を作成します。 変更前と変更後の証拠を添付します。reproduce スキルで得た証拠がある場合は、より多くの情報が伝わるため、それを添付します。ない場合は、目に見える変更のスクリーンショットを添付します。
4. レビューのループを実行します。 Codex と Devin のレビューのみを使用します。各指摘を以下のレビューの仕分けに従って分類します。無視した指摘はそれぞれ PR に記録します。約 10 分間隔で定期チェックインを設定し、PR を再確認します。ユーザーに促されるまで待たないでください。CI が成功し、最新の指摘がすべて無視するものになったら、ループを終了します。レビュー担当者から問題なしと判定してもらうためだけに、小さな変更をプッシュしないでください。ループを終了したら、定期チェックインを削除します。
5. 報告します。 レビューのループが完了したら、ユーザーに最終報告を行います。

スタックの分割

• コードの構造ではなく、機能ごとに分割します。
• ヘルパーは、最初に呼び出すコードと同じ PR に含めます。足場を追加するだけの PR は作成しません。
• 分割する前に、変更全体のスナップショットを保存します。その後、スナップショットを基点にブランチを 1 つずつ作成します。
• 各 PR は、親 PR の変更を含めた状態でチェックに合格する必要があります。
• 完了したら、スタック全体の差分をスナップショットと比較します。両者は完全に一致している必要があります。
• gh stack 拡張機能を使って GitHub のスタック PR を作成します。拡張機能がインストールされていない場合は、インストールします。リポジトリでスタックを利用できない場合は、1 つの PR で問題ありません。

レビュー担当者の反応

• レビューは各プッシュの後に自動で開始されます。レビューを依頼しないでください。
• Codex はレビュー中に PR の説明へ 👀 を追加します。
• Codex は指摘がある場合、レビューコメントを投稿します。
• Codex に指摘がない場合、PR の説明へ 👍 を追加します。問題が見つからなかったことを伝えるコメントが投稿される場合もあります。
• Devin はレビューコメントとして指摘を投稿します。
• プッシュしても新しいレビューが始まらない場合、レビューするほどの変更ではなかったということです。直前の結果が引き続き有効です。

レビューの仕分け

これらの製品のほとんどは MVP です。レビュー担当者は、各製品を大規模で成熟したシステムと考えています。

• 修正する： 実際のバグ、データ損失、攻撃者が悪用できるセキュリティ上の穴です。金銭と機密データは必ず保護します。
• 無視する： 非現実的なケース、過剰に防御的な変更、アクセシビリティに関する指摘です。たとえば、1 人のユーザーが複数のタブやデバイスを使う場合の競合、製品に存在しない規模への対応、存在しないデータや呼び出し元との互換性、任意の堅牢化、細かな指摘は無視します。
• 保留する： 修正に大規模な再設計が必要となる実際のバグです。自分で修正しないでください。

最終レポート

レポートは ASD-STE100 で作成してください。

1. 判断待ち。 判断待ちの指摘ごとに、問題の内容、発生する可能性、修正の規模を記載してください。
2. PR。 各 PR のリンクとステータスを記載してください。
3. 修正済み。 修正済みの指摘ごとに、問題の内容とコミットを記載してください。
4. 無視。 無視した指摘ごとに、問題の内容とその理由を記載してください。

ルール

• ドラフトを開かないでください。
• 修正ごとに新しいコミットを作成してください。コミットを修正しないでください。強制プッシュできるのは、スタックのリベースを行う場合のみです。
• マージしないでください。
• ユーザーから指示がない限り、Linear チケットのステータスやコメントを変更しないでください。