ship-pr

PR を提出する

PR を開くことはゴールではありません。ゴールは、ビルド済みパッケージで検証され、新たな視点でレビューされ、すべてのチェックが成功し、すべてのボットのスレッドに対応したうえで、Ready for Human Review ラベルが付いた PR です。人間が時間を費やすのは、判断が必要な部分だけであるべきです。

すべての手順を実行してください。実行できない手順がある場合は、黙って飛ばさず、引き継ぎ時にどの手順を実行できなかったか、その理由とともに伝えてください。

1. チェック

重要： まず、変更が触れるすべてのガイドページ（docs/reference/ 以外の docs/**/*.mdx）で、authoring-docs の短縮パスを実行してください。段落が 1 つだけの編集でも実行します。変更が触れるリファレンスページには、代わりにauthoring-docs、リファレンスページを適用します。最初に ## Reference を置き、概要テーブルは最小限にし、すべての事実を残してください。以下のチェックでは、どちらかのパスで壊れたアンカーも検出します。

変更した箇所について CI で実行される内容をすべて実行し、問題があればすべて修正してください。

pnpm check                    # lint, dead code, typecheck, error codes, peer ranges, docs
pnpm test                     # or the touched package: pnpm --filter e2e run test:unit
pnpm --filter @e2e-dev/testbed test
pnpm test:web-benchmark       # when the runner, web engine, or benchmark changed

続いて、リポジトリのルールのうち pnpm check では検出できないもの（AGENTS.md の「Contracts」）を確認します。

• 公開済みパッケージにユーザーから見える変更を加える場合は、.changeset/ エントリーを追加してください。0.x では、機能追加であっても patch を上げます。minor にするのは、変更が破壊的な場合（概要が **Breaking:** で始まる場合）か、メンテナーが大規模リリースを指定した場合（**Release:**）に限ります。
• 動作を変更する場合は、対応する docs/**/*.mdx ページも同じ変更で更新してください。「not implemented yet」の注記も含みます。また、skills/e2e/ が変更箇所について説明している場合は、そこも更新してください。
• パブリック API を変更する場合は、生成された .d.ts をレビューし、packages/e2e/tests/types/sdk-types.ts を更新してください。ワイヤ形式を変更する場合は、スキーマ、両方のフィクスチャ、プロデューサーをまとめて編集してください。
• 新しいビルド入力やベンチマーク依存関係は .github/filters.yml に追加してください。
• 新しいインテグレーション、CI サービス、移行ガイドを追加する場合は、それへのリンクがあるすべてのカードにベンダーのロゴを付けてください。Font Awesome の代替アイコンは使わず、セクションの概要ページにもカードを追加してください（authoring-docs、ベンダーのロゴ）。パッケージの PR でも、ドキュメントの PR と同様に必要です。

2. 検証

変更が及ぶ対象に応じて、verify スキルを使って変更を実証してください。テストベッドまたはベンチマーク上でビルド済み CLI を検証する、MCP サーバーを検証する、init 用のスクラッチプロジェクトで検証する、またはドキュメントサイトを検証します。バグ修正では、main とブランチの結果を記録してください。出力と動画があれば、PR 用に保管してください。

3. 新たな視点でセルフレビューする

変更を書いたエージェント自身が、その変更を評価してはいけません。この会話の記憶がないレビュアー（サブエージェント、または新しいセッション）を起動し、ベースブランチを記入した references/review-prompt.md を渡してください。同意できる critical と important の指摘はすべて修正し、修正が触れた箇所について手順 1 と 2 を再実行してください。却下する指摘ごとに、PR 本文または引き継ぎ用の 1 行の理由を残してください。

レビュアーを起動できない場合は、同じプロンプトを使って、先入観のない状態で差分全体を読み直し、その旨を引き継ぎ時に伝えてください。

4. コミットして PR を開く

• 最新の origin/main からブランチを作成してください。コミットは Conventional Commits に従ってください。
• writing-pr スキルに従ってタイトルと本文を作成してください。本文には手順 2 の検証結果を記載してください。
• ドラフトではなく、レビュー可能な状態で開いてください： gh pr create --base main --title ... --body-file <file> --attach <each screenshot and video> （gh 2.99+）。本文には、writing-pr の説明にある ## Verified セクションを必ず含めてください。内容が不十分な場合は、gh pr edit --body-file <file> --attach ... で修正してください。
• 複数の PR に分かれる変更では、各レイヤーが 1 つ下のレイヤーをベースとするようにし、監視を始める前にすべての PR を開いてください。

5. 状況を見守る

PR を babysit スキルに引き継ぎ、最後まで実行してください。すべてのチェックを成功させ、スレッドに対応し、Ready for Human Review ラベルを付けます。スタックの場合は下から順に見守り、各レイヤーが単独でレビュー可能になった時点で、そのレイヤーにラベルを付けてください。

引き継ぎ

人間には次の内容を返信します。

• PR の URL とラベルの状態
• 検証方法（対象、実行した内容、確認した内容、メディア）
• レビューで修正した点、却下した点とその理由
• 対応が必要な事項：エスカレーションしたスレッド、検証できなかった部分、対応範囲外とした内容