open-pr

PR を作成する

変更範囲を絞った、マージ可能なプルリクエストを準備し、レビュー可能な状態で作成して、マージ可能になるまで対応します。その URL と最終ステータスを返します。

ワークツリー

リポジトリの指示を読み、想定されるベースブランチ、ブランチの運用方針、PR のツール、コミットと PR の規約を確認します。リポジトリでコミット規約や PR テンプレートが定められている場合は、以下の規約ではなく、そちらに従います。現在のワークツリーの変更が PR に含める変更である場合は、必要に応じてそこで想定されるブランチを作成して作業します。それ以外の場合は、ベースブランチから分離したワークツリーを優先します。承認なしにユーザーの作業を修正、リセット、破棄、上書きしてはいけません。ワークツリーに PR の変更と無関係な作業が混在している場合や、状況が整理できない場合は、作業を停止して確認します。

ステータス、ステージ済みと未ステージの差分、未追跡ファイルすべて、ブランチの祖先関係、コミット範囲、リモートの状態を確認します。すべての変更が依頼された PR に含まれることを検証します。範囲が曖昧な場合、マージコンフリクトがある場合、機密データが含まれる場合、権限が不足している場合、安全でない履歴の書き換えが必要な場合は作業を停止します。

コミット

ストーリーが伝わるよう、小さく順序立てたコミットを計画します。各コミットは、それぞれ単独でレビューでき、マージ可能である必要があります。直近に作成した未共有コミットに修正を含める場合は amend し、分けられる変更であれば新しいコミットを作成します。共有済みの作業をリベースしたり、強制プッシュしたりする前には確認を求めます。

各コミットの前に、対象となる差分そのものに対して deslop を実行します。レビューの前に、PR 全体の差分に対して no-comments を実行します。コメントの指摘を受け入れて変更が生じた場合は、計画を立て直し、その変更に対して deslop を再実行します。

コミットの件名には Conventional Commits を使用します。変更箇所をスコープとして指定します。件名は短く命令形にし、有用であれば実際のシンボル名を含め、末尾にピリオドを付けません。コミット本文には件名に含まれていない事実を説明し、件名の内容を繰り返してはいけません。Conventional Commits の構文を変えずに、件名と本文のそれぞれに unslop を適用します。

各コミットとプッシュには ship を使用し、そのコミットに含まれる変更を明記します。

プルリクエスト

PR タイトルにも Conventional Commit 形式を使用します。冠詞を残し、各アクションには一般的な単語を 1 つ使い、直接的な動詞が使える場合は -ing を避けます。構文を変えずに、タイトルに unslop を適用します。

見出しを付けず、問題と、具体的な失敗例がある場合はその例、そして変更による解決方法を述べる段落から始めます。主要なシンボル名を挙げます。対象外の内容、または名前変更の前後の両方について説明する必要がある場合は、その文を加えます。差分を順に説明しないでください。

続けて、次のセクションをこの順序で追加します。

• ## トレードオフ。実際の選択、却下した代替案、既知の制限、壊れる可能性のあるものを記載します。レビュアーが疑問に思う可能性がある場合は、変更されない点も明記します。ベースブランチで修正なしだと失敗する場合は、その状態が続くことによるコストを記載します。記載事項がない場合は、このセクションを省略します。
• ## 検証。各チェックの実行方法と、その厳密さを記載します。CLI コマンド、UI の操作手順、対象を絞ったテストなど、実際の実行経路を明記します。コマンド名だけでなく、各チェックの結果も記載します。

これらのセクションの後に、主張を裏付けるスクリーンショットや動画があれば添付します。定型文の ## Summary や ## Test plan は追加しないでください。完成した説明に unslop を適用します。

大きな PR を 1 つ作るよりも、範囲を絞った PR を 5 つ作ることを優先します。リポジトリで設定されているスタック管理ツールを使い、順序付きのスタックがレビュアーに見える状態を保ちます。独立した作業に限り、ベースブランチからブランチを作成します。スタックでの作業を本格的に始める前に、最新のベースブランチにリベースします。

すべての PR はドラフトではなく、レビュー可能な状態で開きます。クラウドエージェントの PR ツールはデフォルトでドラフトになるため、すべての PR 作成時に draft: false を設定します。それでもドラフトとして開かれた場合は、gh pr ready <number> など、ホストの ready コマンドを実行します。PR のステータスに言及する前に、gh pr view <number> を実行します。

各 PR を開いた後、その PR に対して babysit-pr を実行し、レビュー可能な状態になるまで、またはブロッカーを報告するまで対応します。スタック内の PR を含むすべての PR でこれを行います。PR を開くだけでは、このワークフローは完了しません。

PR を開くサブエージェントは deslop と no-comments を実行し、その後、PR の監視も行います。人間からのフィードバックや判断が曖昧な指摘は、ユーザーに伝えるため親エージェントに報告します。PR の URL と最終ステータスを返します。