ship-it

ステップ 1 — スコープとプロジェクトのルールを確認する

プロジェクトの調整および成果物の提出に関する指示を読みます。リポジトリの設定とユーザーの意図に基づいて、依頼された成果、現在のブランチ、対象のリモート、PR のベースを確認します。ベースが不明な場合に main と決めつけてはいけません。

プロジェクトで既に使用されている成果物の提出に関するドキュメントを使います。ほかに指定がなければ、delivery-status.md を探します。古いプロジェクトでは delivery-plan.md にも対応します。最初の数行だけでなく、現在のフェーズ、期待される成果、受け入れ要件を確認します。差分が合意済みのスコープと矛盾する場合は、提出する前にユーザーと判断をすり合わせます。この確認のためだけにステータスファイルを作成してはいけません。

delivery-plan.md が存在する場合は、以前のステータスの移行ルールに従い、保存された決定を確認します。未解決の場合はユーザーに尋ね、ステータスの運用方法を変更する前にユーザーの選択を記録します。

作業ツリーの変更と、リモートにまだ送信されていないコミットを確認します。意図された作業だけを含めます。すでに承認されているコミットは再度尋ねずに進めます。無関係な変更を黙って退避、破棄、または含めてはいけません。ベースブランチで作業している場合は、既存の作業をリセットせず、適切な PR ブランチを用意します。

コミットを作成する場合は、メッセージを書く前にコミットメッセージのルールに従います。

検証済みの値を _SHIP_REMOTE、_SHIP_BASE、_SHIP_BRANCH に設定した後：

git status --short
git diff "$_SHIP_REMOTE/$_SHIP_BASE...HEAD" --stat
git log "$_SHIP_REMOTE/$_SHIP_BASE..HEAD" --oneline

ステップ 2 — 必要に応じて同期する

対象のベースをフェッチし、同期が必要か確認します。プロジェクトのマージまたはリベースの慣例に従います。すべてのブランチにベースを自動的にマージしてはいけません。許可なく共有履歴を書き換えないでください。

git fetch "$_SHIP_REMOTE" "$_SHIP_BASE"

意図された動作と両方の変更を踏まえて競合を解決し、その解決内容を検証します。利用可能な根拠から重要な動作やスコープの判断ができない場合に限り、質問します。

ステップ 3 — 動作を検証し、最終差分をレビューする

変更内容とリスクに応じたテストを実行します。プロジェクトのルールに従って、全テストスイートを実行します。以前の結果を再利用できるのは、現在のコードと関連する環境を対象としている場合に限ります。その後に編集や競合解決を行った場合は、影響を受けるチェックを再実行します。

重要な動作、境界条件、エラー処理が網羅されているか確認します。新しいコードパスのすべてにテストを要求したり、実装の詳細だけをテストしたりするのではなく、根拠が不足している動作には有意義なテストを追加します。

このブランチで発生した失敗を修正します。既存の失敗や環境上の障害について根拠を確認し、プロジェクトの提出ルールに従います。残っているゲートがあれば報告し、部分的な結果を合格として示してはいけません。

既存のレビューが同じ差分を対象としていない限り、送信予定の差分に対して diff-inspector を実行します。その後の変更と、その影響もレビューします。確認済みの指摘事項は重要度とプロジェクトのルールに従って解決し、未解決の疑問点と確認済みの不具合を区別します。

ステップ 4 — プッシュして PR を作成または更新する

プッシュする前に、送信するコミットと差分をスキャンし、キー、 トークン、認証情報、機密性の高い接続文字列などのシークレットがないか確認します。見つかった場合は、プッシュを中止し、 シークレットの値を再掲せずに、その場所を報告します。

git push "$_SHIP_REMOTE" "$_SHIP_BRANCH"

PR を作成する前に、そのブランチに既存の PR がないか確認します。リポジトリの PR テンプレートに従います。テンプレートがない場合は、 PR 本文のテンプレートを使用し、実際の変更内容と 検証結果を記入します。変更内容に応じて詳細度を調整し、該当しないセクションは削除します。

PR のタイトルや説明に、共同作成者のクレジット、Co-authored-by トレーラー、エージェントの署名を 追加しないでください。

認証済みの GitHub CLI を使用できる場合は、完成した本文を一時ファイルに保存し、そのパスを _SHIP_PR_BODY に設定します。実際の変更内容から _SHIP_TITLE を設定します。

gh pr create --base "$_SHIP_BASE" --head "$_SHIP_BRANCH" \
  --title "$_SHIP_TITLE" --body-file "$_SHIP_PR_BODY"

既存の PR がある場合は、完成した本文ファイルを使って gh pr edit で更新します。 CLI を利用できない、または認証されていない場合は、利用可能な認証済みの代替手段を使うか、 手動で送信できるよう、完成したタイトルと本文を提示します。 実際に成功した操作を報告します。

ステップ 5 — CI を確認し、教訓を記録する

作成された PR のチェックを読み取り、合格、失敗、保留中、または利用不可のいずれかを報告します。

gh pr checks "$_SHIP_PR_URL"

依頼された成果物の一部として必須の CI を待つ必要がある場合は、チェックが結果に至るまで積極的に監視し、 範囲内の失敗に対処します。

gh pr checks "$_SHIP_PR_URL" --watch

デプロイの検証が依頼されている場合は、対象のリビジョンと環境に対応するデプロイワークフローの実行を特定します。 検証済みの実行 ID を _SHIP_RUN_ID に設定し、明示的に監視します。

gh run watch "$_SHIP_RUN_ID" --exit-status

失敗したチェックやジョブを調査し、範囲内の失敗を解決します。成功を報告する前に、 デプロイで求められる結果を検証します。無関係なワークフローの合格は、デプロイの証拠にはなりません。 監視が妨げられた、または中断された場合は、最後に確認した状態、PR または実行の URL、 未検証の項目を報告します。

このまとめのチェックポイントで project-memory を実行し、その記録基準に従います。 該当するプロジェクト固有の教訓を保存し、保存した項目を報告します。 該当するものがない場合は、報告する必要はありません。

提出レポート

ブランチと変更範囲、実際のテストおよびレビューの結果、PR の URL、CI の状態、 未解決の要件を報告します。証拠に基づいて、プッシュ済み、PR 作成済みまたは更新済み、 マージ済み、デプロイ済みを区別します。PR を作成しただけでは、マージやデプロイが行われたことにはなりません。