ship-it

リリースする

「コードが完成」してから「人間がマージできる状態の PR」になるまで、作業を担当します。パイプラインを順番に実行します。各ステップで、そのステップが行った編集に責任を持ち、パイプラインは前に進むだけです。マージは必ず人間が行います。

ティア

デフォルトでは prod ティアを使用します。ティアの引数（/ship-it wip または /ship-it prod）で、この実行のティアを指定します。ティアの引数なしで再開する場合は、## Review マーカーのティアを使用します（「再開」を参照）。

• prod：本番環境で稼働しているプロジェクトです。すべてのステップを実行します。
• wip：個人用または作業途中のプロジェクトです。– が付いたステップはスキップします。

パイプライン

#	ステップ	prod	wip	詳細
1	意図	ユーザーが確認	記述するが、未確認	steps/intent.md
2	リベース	✓	✓	以下を参照
3	レビュー	正確性＋品質	正確性、重大な問題のみ	steps/review.md
4	テスト	✓	–	steps/test.md
5	ドキュメント	✓	–	以下を参照
6	リント	✓	✓	以下を参照
7	コミットとプッシュ	✓	✓	以下を参照
8	PR	本文全体	Summary、Intent、Review	steps/pr.md
9	CI とボット	CI、その後ボットループ	CI のみ	steps/ci.md

各ステップの詳細ファイルは、そのステップに到達したときに読みます。それより前には読まないでください。

ステップ 4 から 9 では、レビュー後にコミットを追加する場合があります。テスト修正、ドキュメント、リント、CI の修正、ボットによる修正が該当します。ステップ 8 で PR を作成または更新する前、および完了を報告する前に、HEAD と最後にレビューした sha を比較します。その後にコミットがある場合は、steps/review.md に従って <sha>..HEAD を再レビューします。その後、## Review マーカーに新しくレビューした sha を記録します。prod では、これらのコミットによって実際のシナリオで対象となる動作が変わった場合、steps/test.md に従ってそのシナリオを再実行し、完了を報告する前に PR 本文のエビデンスを差し替えます。

完了とは、PR がオープンでマージ可能な状態（ドラフトではない）であり、## Review マーカーが HEAD を示し、CI がグリーンで、prod ではボットループがルールに従って停止していることを指します。ユーザーに報告し、レビューとマージを依頼してください。そこで終了します。

再開

状態ファイルはありません。ブランチ、コミット、PR が記録になります。実行のたびに、最初に未完了のステップを見つけます。

1. ベースブランチより先のコミットがなく、未コミットの変更もない場合 → リリースするものはありません。その旨を伝えます。
2. この意図に関する未コミットの変更がある場合 → まず、ステップ 7 に従って論理的なまとまりごとにコミットし、メッセージを付けます。プッシュはしません。他の作業が混在している変更は、「実行場所」の説明に従って、先に確認します。
3. このブランチの PR を読む（gh pr view --json number,body,headRefOid,isDraft）。
   • PR がない → ステップ 1 から開始します。
   • PR 本文に ## Intent がある → それが意図です。ユーザーが新しい意図を提示していない限り、ステップ 1 をスキップします。
   • ## Review の `` マーカーが最後にレビューしたコミットを示しています。その後にコミット（ローカルまたはプッシュ済み）がある場合 → <sha>..HEAD のみを再レビューし、その後は先に進みます。
4. この実行のティアが prod で、マーカーが tier=wip を示している場合 → ステップ 1 に戻ります。wip では意図を確認しておらず、レビューの一部だけを実行し、テストとドキュメントのステップもスキップしています。ステップ 3 で変更全体を再レビューし、ステップ 8 で prod 用の本文全体を書き、マーカーを tier=prod に設定します。
5. それ以外の場合：未プッシュのコミットがある → ステップ 7。PR がドラフト → ステップ 8。CI が失敗または実行中 → ステップ 9。CI がグリーン → ステップ 9 のボットループ（prod）または完了（wip）。

どのステップから再開するのか、その理由とともに 1 行でユーザーに伝えます。

実行場所

• その場で実行：チェックアウトが機能ブランチまたはワークツリーで、未コミットの変更がすべてこの作業に属する場合。
• 先に確認：デフォルトブランチにいる場合、または未コミットの変更にこの作業以外の変更が混在している場合。この作業を新しいワークツリーに移すことを提案してください。ユーザーが同意した場合にのみ作成します。
• bench 内の Frappe アプリ：通常の git worktree は bench から認識されません。その場で実行してください。

サブエージェント

すべてのレビュー担当者と修正担当者は、この会話を見ていない新規のサブエージェントです。プロンプトには、作業の意図、記録された決定事項、差分の範囲、確認するレビューファイルなど、必要な情報をすべて含めます。修正担当者には、問題を報告したレビュー担当者とは別のエージェントを使います。再レビューも新しいサブエージェントで行います。

エージェント	起動方法
Claude Code	Agent ツール。
Codex	spawn_agent。Codex は指示がある場合にのみ起動するため、明示的に起動します。
T3 Code（t3-code MCP tools が利用可能な場合）	delegate_task に mode: "wait" を指定します。orchestrator_capabilities からプロバイダーとモデルを選びます。

すべてのサブエージェントに、利用可能な最も強力なモデルを使用します。別のプロバイダーのモデルを起動できるエージェントがいる場合は、正確性のレビュー担当者にそのモデルを割り当てます。別のモデルファミリーを使うことで、最初のモデルと作成者が見落とした誤りを検出できます。

指摘事項とユーザーへの確認

レビュー担当者は、review/verdict.md に記載された形式で指摘事項を返します。auto-fix の指摘事項は確認せずに修正します。各ステップの ask-user の指摘事項はすべてまとめ、review/ask.md に示された形式で一度にユーザーへ確認します。回答は決定事項となり、実行中に覆されることはありません。

インライン手順

2. リベース

git fetch origin を実行します。origin/<branch> が存在する場合は、その SHA をステップ 7 用に記録し、ローカル履歴にないリモートの変更を取り込みます。このクローンが最後にプッシュしたコミットを確認します：git reflog show --format='%H %gs' origin/<branch> | grep -m1 'update by push'。その SHA は、ローカルブランチ自体の reflog にある場合にのみ使用します（git reflog show --format=%H <branch> | grep -qx <sha>）。これは、このブランチがそのコミットにあったことを示します。それ以前のコミットは、以前のリベースで書き換えられている可能性はありますが、すでにローカル履歴に含まれています。それ以降の <pushed sha>..origin/<branch> のコミットは、他のユーザーがプッシュしたものです。たとえば git cherry-pick を使って、それぞれ取り込みます。その SHA が origin/<branch> の祖先でない場合（git merge-base --is-ancestor <sha> origin/<branch> が失敗する場合）、プッシュ後に他のユーザーがリモートブランチを書き換えています。停止してユーザーに確認してください。そのような SHA がない場合は、HEAD..origin/<branch> を取り込みます。HEAD にすでに変更が含まれているコミットはスキップします。その後、origin/<base> にリベースします。競合は両方の変更と作業の意図を尊重して解決します。競合の解決にプロダクト上の判断が必要な場合は、確認してください。リベース後にベースとの差分が空になった場合は停止します。出荷するものはありません。

5. ドキュメント（本番環境）

変更によって古くなったものを探します：README、ドキュメントページ、AGENTS.md、変更箇所付近のコードコメント、例。古くなった情報は、それぞれの正規の記載場所で修正します。解決できなかった内容は ask-user の指摘事項として報告します。

6. Lint

リポジトリ独自のフォーマッターとリンターを、修正モードで実行します。package.json のスクリプト、pyproject.toml、.pre-commit-config.yaml、CI ワークフローを確認し、CI で実行される処理を特定します。残った問題は最大 3 回まで修正します。リポジトリにリンターの設定がない場合はスキップします。

7. コミットしてプッシュする

論理的なまとまりごとに、慣例に沿ったメッセージ（feat:、fix:、refactor:、docs:、test:、chore:）でコミットします。修正のレビューは、steps/review.md の修正ループにあるコミットのルールに従います。tidy: コミットは動作変更と分けます。コミットメッセージには変更内容のみを記述します。

安全にプッシュします。

• この実行で origin/<branch> の sha を記録していない場合（手順 7 からの再開時）は、フェッチして記録し、手順 2 と同様にリモートの変更を取り込みます。それ以外の場合は git fetch origin を実行します。
• origin/<branch> と記録済みの sha を比較します。更新されている場合、まだ取り込んでいないリモートの変更があるため、手順 2 に戻ります。
• origin/<branch> が存在しない場合、または HEAD の祖先である場合は、通常のプッシュを行います。それ以外の場合、今回または以前の実行で HEAD がプッシュ済みのコミットを書き換えているため、--force-with-lease=<branch>:<recorded sha> を指定してプッシュします。
• フェッチ後にリモートが変更されたためにプッシュが拒否された場合（non-fast-forward、fetch first、または stale info）、手順 2 に戻ります。それ以外の拒否（権限、ブランチ保護、サーバー側のフック）はリベース後も解消されません。停止して、エラーをユーザーに示します。
• プッシュ後、新しい記録済み sha としてプッシュした sha を記録します。これにより、後続の手順 9 からのプッシュでこの sha と比較できます。
• プッシュ時刻を記録します。steps/ci.md のボットループで使用します。