ship-pr

PR を出す

PR を作成しても、まだ完了ではありません。完了とは、PR に Ready for Human Review ラベルが付いた状態です。ビルド済みパッケージで 検証され、新たな視点でレビューされ、すべてのチェックが成功し、すべての ボットスレッドに対応済みであることが条件です。人間が時間を使うべきなのは、 判断だけです。

すべての手順を実行してください。実行できない手順があれば、黙って飛ばすのでは なく、引き継ぎ時にどの手順が、なぜ実行できないのかを伝えてください。

1. チェック

**重要：**まず、変更が及ぶすべてのガイドページ （docs/reference/ 以外の docs/**/*.mdx）に対して、 authoring-docs の 短縮パスを実行してください。段落ひとつの編集でも対象です。変更が及ぶ リファレンスページには、代わりに authoring-docs, Reference pages を適用してください。## 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 のプレースホルダーは使いません。インテグレーションページまたは CI ページには、概要ページのカードも追加します （authoring-docs, Page icons）。 パッケージの PR でも、ドキュメントの PR と同様にこれが必要です。

2. 検証

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

3. 新しいコンテキストでセルフレビュー

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

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

4. コミットして PR を作成

• 最新の origin/main からブランチを切ります。コミットは Conventional Commits に従います。
• writing-pr スキルを使ってタイトルと本文を作成します。 本文には手順 2 の検証結果を記載します。
• ドラフトではなく、レビュー可能な状態で PR を作成します。 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 に分ける変更では、後続の対応を始める前に、下位の PR をベースに 各階層の PR をすべて作成します。

5. PR のフォローアップ

babysit スキルに PR のフォローアップを任せ、すべての 条件が満たされるまで実行します。チェックがすべて成功し、スレッドに対応済みで、 Ready for Human Review ラベルが付いている状態にしてください。積み重ねた PR では下位から順にフォローアップし、単独で準備が整った階層にだけラベルを付けます。

引き継ぎ

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

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