autoship

Autoship

npm のリリースを最初から最後まで進めます。changeset、修正ループ、プッシュ、CI の監視、Version Packages PR のマージ、公開状況の監視、npm での検証を行います。

• 対象： 既存の changesets ベースの npm パッケージについて、changeset ファイルの作成からレジストリでの新しいバージョンの確認までを行う、リリースパイプライン全体です。リリース実行でバージョン更新や公開が行われなかった原因の診断も含みます。
• 対象外： 機能 PR の作成（pr-creator を使用）、レビュー・競合・CI に関する機能 PR の監視（pr-babysitter を使用）、リリースフロー外での一般的なビルドや型の修正、新しいパッケージのスキャフォールディング（scaffold-cli を使用します。初回リリースは autoship に引き継がれます）。

リリースループ

1 つのワークフローが、連続する 2 回の実行で構成されます。これを 2 つのワークフローだと誤解することが、autoship で起きるミスの主な原因です。

1. 保留中の .changeset/*.md ファイルを含むコミットをデフォルトブランチにプッシュします。
2. リリースワークフローが実行されます。changesets/action は保留中の changeset を検出し、CI で changeset version を実行して、ブランチ changeset-release/<default-branch> に PR（タイトルは「Version Packages」、pre モードでは末尾に「(next)」が付きます）を作成または更新します。この PR には package.json のバージョン更新と CHANGELOG.md のエントリーが含まれます。
3. すべてのチェックがグリーンになったら、その PR をマージします。
4. 同じワークフローが再び実行されます。保留中の changeset がなくなると、アクションは公開スクリプト（changeset publish）を実行して npm に公開します。デフォルトでは、git タグをプッシュし、GitHub リリースも作成します。

ローカルでの作業は「changeset ファイルをプッシュする」時点で終了します。バージョン更新と公開は CI が担当します。

このアクションには、入力名が異なる 2 つの現行メジャーバージョンがあります。@v1 は publish:、@v2 は publish-script: を使用します。バージョン更新は行われたものの公開されなかった実行を診断する場合は、uses: 行を確認してください。

参照ファイル

ファイル	読むタイミング
references/changeset-and-commit.md	ステップ 1～3：changeset ファイルの作成、対話なしでゲートを特定して実行する方法、リリースコミットのステージング
references/ci-polling.md	ステップ 4 とステップ 5 の監視：Monitor ツール、コミット監視スクリプト、失敗の分類、Changeset Status チェック
references/version-pr-and-publish.md	CI がグリーンになった後：ワークフローの構成、Version Packages PR の特定とマージ、公開実行、npm での検証、公開失敗の診断
evals/evals.json	このスキルを変更するときのみ。リリース中には読み込まれません

インテントマップ

インテント	ステップ	備考
Autoship をすべて実行（出荷／リリース／公開）	1～5	デフォルトの開始点です。途中で確認を求めず、公開まで最初から最後まで実行します
changeset のみを作成	1	プッシュせずにリリースの準備をします
ゲートを修正してプッシュ	1～3	changeset、修正、コミットを行います。CI の監視は行いません
CI のみを監視	4～5	changeset はすでにプッシュ済みです
Version Packages PR のみをマージ	4b～5	CI はすでにグリーンです。前提条件が満たされたらマージします
ゲートの修正のみ	2	リリースフローの一部として実行します。changeset は不要です
公開されなかったリリースの診断	読み取り専用	references/version-pr-and-publish.md（PR 待機タイムアウトのチェック、公開失敗の表）

npm のリリースに関する文脈がない「Ship it」は pr-creator に振り分けられます。

安全性の段階

autoship の起動は、リリースフロー全体を実行することへの継続的な同意を意味します。途中で再確認のために停止せず、客観的な前提条件に基づいてリスクの高いステップを判断してください。

• グリーン（そのまま実行）： 読み取り：CI と PR の状態、npm view、保留中の changeset、package.json のスクリプト、git の履歴と状態。
• イエロー（1 行で通知してから実行）： changeset ファイルの書き込み、lint／型チェック／テスト／フォーマットの修正ツールの実行、git add/commit/push、監視の開始、Version Packages PR の識別が確認され、すべてのチェックに合格した後のマージ。
• レッド（明示的な確認が必要）： 強制プッシュ、履歴の書き換え、リポジトリ設定の変更、破壊的な git 操作。

ワークフロー

進捗を記録するには、このチェックリストをコピーしてください。

Autoship progress:
- [ ] Step 1: Create changeset (default patch)
- [ ] Step 2: Fix lint, types, tests, format
- [ ] Step 3: Commit and push the changeset
- [ ] Step 4a: Watch CI on the pushed commit
- [ ] Step 4b: Find and merge the Version Packages PR
- [ ] Step 5: Watch the publish run, verify on npm

ステップ 1：changeset を作成する（デフォルトは patch）

• references/changeset-and-commit.md を読み込みます。
• 保留中の changeset と対象パッケージを確認します。依頼されたリリースを対象とするものは再利用し、対象外の変更に対してのみ追加します。無関係な保留中のリリースによって公開範囲が曖昧になる場合に限り、質問してください。
• デフォルトは patch とし、ユーザーから明示的に指示された場合にのみ minor または major を使用します。
• ファイルを直接書き込みます（対話型プロンプトには TTY が必要です）。要約には git log --oneline -10 から推測した、ユーザー向けの変更履歴テキストを記載します。
• pnpm changeset status でファイルを検証します。パッケージ名に誤りがある場合、CI ではなくここで失敗します。

ステップ 2：lint、型、テスト、フォーマットを修正する

• package.json のスクリプト（check、lint、typecheck、test、format、fix）からコマンドを確認します。Node 以外のリポジトリでは、Makefile、Cargo.toml、pyproject.toml、go.mod を確認します。
• lint、型チェック、テスト、フォーマットを実行します。コードを変更した後は、最初のゲートから再実行してください。型の修正によって lint が失敗することはよくあり、lint の自動修正でテストが失敗することもあります。
• 対応している場合は、自動修正ツールの対象を変更したファイルに限定し、その後 git status を確認します。広範囲に適用される fix／format スクリプトは、変更対象外のファイルも再フォーマットすることがあります（MDX は特に影響を受けやすいファイルです）。この実行で加わった自動修正の変更だけを元に戻し、同じファイルにある既存の編集は保持します。
• 各ゲートの修正ループは最大 5 回までとし、各回で残りのエラー数を報告します。その後は停止し、ゲート、残りのエラー数、最後のエラー出力を報告します。

ステップ 3：changeset をコミットしてプッシュする

• changeset ファイルと対象範囲内の修正を、明示的なパスを指定してステージします。コミット前に git status --porcelain でフックが生成したファイル（ルートにある schema.gql は既知の例です）がないか確認します。
• コミット（chore: add <type> changeset for <package>）してプッシュします。
• プッシュしたコミットには、引き続き .changeset/*.md が含まれている必要があります（最初の落とし穴）。

ステップ 4a：プッシュしたコミットの CI を監視する

• references/ci-polling.md を読み込みます。
• プッシュした SHA のコミット監視を開始します。状態が変わるごとに 1 行が出力され、そのコミットに対するすべての実行（CI とリリースワークフロー）が完了すると TERMINAL: の行が出力されます。最初のポーリングで何も起きないのは正常です。実行がキューに入るまで時間がかかります。
• 失敗した場合は、gh run view <id> --log-failed で原因を分類します。一時的な失敗またはインフラの問題には gh run rerun <id> --failed を使用します（最大 3 回）。実際の不具合の場合は修正してコミット、プッシュし、新しい SHA の監視を開始します。

ステップ 4b：Version Packages PR を見つけてマージする

• references/version-pr-and-publish.md を読み込みます。
• head が changeset-release/<default-branch> であるオープン PR を見つけます。見つからない場合は、PR 待機監視を実行します（上限 10 分）。
• 次の 3 つすべてを満たす場合に限りマージします。
  • head ブランチが changeset-release/<default-branch> であること（タイトルは通常「Version Packages」ですが、pr-title で変更されている場合があります）。他の PR は絶対にマージしないでください。
  • gh pr checks <n> --json name,bucket のすべてのチェックで bucket: pass が報告されること。
  • gh pr view <n> --json mergeable が MERGEABLE を報告すること（UNKNOWN の場合は待ってから再確認します）。
• 「Version Packages PR #N: @ をマージします」と通知してから、gh pr merge <n> --squash --delete-branch またはリポジトリで許可されているマージ方法を実行します。前提条件を満たさない場合は停止して報告し、絶対にマージしないでください。

ステップ 5：公開の実行を監視し、npm で確認する

• マージすると同じワークフローが再度実行されます。保留中の changeset がなければ公開されます。
• マージ SHA（gh pr view <n> --json mergeCommit --jq .mergeCommit.oid）を取得し、その SHA のコミット監視を実行します。
• 失敗した場合はログを読み、references/version-pr-and-publish.md の公開失敗一覧と照合して報告し、停止します。公開の失敗に対して、根拠なく再試行してはいけません。一覧に記載された原因はすべて、設定または構成の変更が必要です。
• 成功した場合は、npm view <package>@<version> version がマージされたバージョンを出力し、npm view <package> dist-tags がそのバージョンを指す latest を表示することを確認します（pre モードの場合を除く）。残りの監視を停止し、両方の出力を報告します。これらが完了の証拠になります。

障害からの復旧

ゲートが5回の反復後も失敗している場合、またはマージの前提条件が満たされていない場合は、処理を停止して報告してください。失敗したチェックを無視したり、ボットのPRで競合を解決したりしてはいけません。各段階の診断方法については、「CI」と「Changeset Status」の失敗は references/ci-polling.md に、Version Packages PR が作成されない場合と公開の失敗は references/version-pr-and-publish.md に記載されています。

注意点

• ローカルで pnpm changeset version を実行してはいけません。 .changeset/*.md が消費されるため、プッシュしたコミットに保留中の changeset がなくなり、「Changeset Status」が失敗して、Version Packages PR が作成されません。復旧するにはバンプを取り消します。CIを再実行してはいけません。
• pnpm publish や npm publish を直接実行してはいけません。changesetsを迂回して、変更履歴とタグの生成を省略し、Version Packages PRにはすでに公開済みのバージョンが記載されます。その結果、「You cannot publish over the previously published versions」というエラーで失敗します。
• CHANGELOG.md や package.json の version を手動で編集してはいけません。CIがVersion Packages PR内で両方を生成します。ローカルで編集すると、ボットのPRが CONFLICTING になります。
• changesets/action@v2 では、すべての入力名が変更されています（publish から publish-script、version から version-script、title から pr-title、commit から commit-message、branch から pr-base-branch）。旧名は警告のみで無視されるため、publish: を使い続ける @v2 ワークフローでは、Version PRが作成された後、公開が何も行われないまま正常終了します。
• node-version: 22 を指定した setup-node には npm 10.9.x が同梱されています。信頼された公開には npm 11.5.1 以降が必要なため、id-token: write を設定していても changeset publish は ENEEDAUTH で失敗します（pnpmは PATH 上の npm CLI にアップロードを引き渡します）。公開前にNode 24を使うか、npm install -g npm@latest を追加してください。
• クラシックトークンを保持する NPM_TOKEN シークレットで認証するワークフローは、ENEEDAUTH で失敗します。npmは2025年12月9日にすべてのクラシックトークンを無効化しました。新しいトークンを発行するのではなく、信頼された公開に移行してください。書き込み可能なきめ細かいトークンの有効期限は90日以内です。
• npmは、信頼された公開者を保存するときに検証しません。ワークフローのファイル名が .github/workflows/<file>.yml と大文字・小文字または拡張子で異なる場合、公開時になって初めて ENEEDAUTH が発生します。
• 新しい個人用リポジトリでは、ActionsによるPRの作成がブロックされています。リリース実行は「GitHub Actions is not permitted to create or approve pull requests」で失敗し、Version PRは作成されません。解決方法：Settings、Actions、Generalで「Allow GitHub Actions to create and approve pull requests」を有効にします（組織レベルの設定で上書きされる場合があります）。Red tierの場合は報告し、依頼がない限り設定を変更しないでください。
• gh pr list --json headBranch と gh pr checks --json conclusion は無効なフィールドで、エラーになります。headRefName と bucket を使用してください。
• Monitorツールのデフォルトの timeout_ms は300000（5分）です。これを超えるCI実行では、監視がタイムアウトで終了し、何も起きていないように見えます。CIの監視には timeout_ms: 3600000 を指定してください。
• ポーリング間隔は30秒以上にしてください。間隔を短くするとGitHub APIのレート制限（gh api rate_limit --jq .resources.core.remaining）を消費し、リリースの途中で処理が停止します。
• git add -A を使うと、リリースコミットにpre-commitフックの生成物や修正による差分が含まれます。対象のパスを明示してステージしてください。
• 明示的な指示がない major は、すべての利用者に対する破壊的変更を意味します。デフォルトでは patch を選んでください。

関連スキル

• scaffold-cli：changesetsとOIDC公開を設定した新しいTypeScriptパッケージを作成し、初回リリースのためにautoshipへ引き継ぎます。
• pr-creator：機能PRを作成します。Autoshipがマージするのは、ボットが作成したVersion Packages PRのみです。
• pr-babysitter：機能PR（レビュー、競合、CI）を監視します。Autoshipが監視するのはリリースCIのみです。autoshipが進行中のVersion Packages PRを監視してはいけません。