node-release

node-release

長期間有効なシークレットも、推測した情報も使わずに、バージョン管理と npm への公開を自動化します。このスキルで解決する問題は、2026年になってもモデルが NPM_TOKEN シークレットを設定すること、パッケージの初回バージョンは OIDC 経由で公開できないことを見落とすこと、信頼されたパブリッシャーの登録を微妙に間違えること（大文字・小文字、ファイル名、間接呼び出し）、タグ付け後に公開が失敗するとリリースが中途半端なままになることです。

使用しない場合

• エクスポートマップ、バンドル、tarball の内容 → node-packaging（リリースでは、そのチェックがすでに通過していることを前提とします）。
• 依存関係の来歴の検証 → node-supply-chain。
• テスト／lint の CI → node-ci。

ワークフロー

1. リリースツールを選択します。ワークフローの実態に基づいて選んでください（references/release-playbook.md の判断表を参照）：Changesets（人が記述するリリースノート、モノレポ）、semantic-release（厳格な Conventional Commits、完全自動化）、release-please（リリースごとの PR レビューを必須化）。
2. 信頼されたパブリッシング（OIDC）をデフォルトの認証方式にします。必要条件はすべて、公式 npm ドキュメントへのリンクとともにプレイブックでバージョンごとに明記しています（ランナー上の CLI／Node の最小バージョン、GitHub ホステッドランナー、リポジトリとワークフローファイル名の完全一致、workflow_call による間接呼び出しの注意点）。信頼されたパブリッシングでは、来歴が自動的に付与されます。
3. ブートストラップ時の注意点は、問題になる前に伝えます。新規パッケージは OIDC 経由で初回公開できません。プレイブックのブートストラップ手順では、手動で一度公開し、その後に登録し、最後にトークンを失効させてアカウントレベルで信頼されたパブリッシングのみを許可します。
4. プレイブックの YAML を基に公開ワークフローを作成します。必要最小限の権限（id-token: write、必要な場合のみ contents: read/write）、SHA で固定したサードパーティ製アクション（node-supply-chain のポリシーと一致）、node-packaging のチェックを通過した場合にのみ公開します。
5. 失敗時の順序を徹底します。公開してからタグ付けするか、再試行を冪等にしてください。公開済みのタグは決して削除しないでください。リリースは不変です。
6. 最初から最後まで検証します。まずドライランを行い、可能であればプレリリース／dist-tag を使って実際に公開します。レジストリページで来歴を確認してから、旧トークンを失効させてください。

出力仕様

来歴付きでバージョン、変更履歴、タグ、npm への公開を行う、動作する自動リリースパイプライン。移行後は長期間有効なレジストリシークレットをゼロにし、ブートストラップとロールバックの手順をリポジトリに記録し、段階的／プレリリース用の公開チャネルを意図的に決定します。

注意点

• 信頼されたパブリッシャーの登録は完全一致が必要です。オーナー／リポジトリ名の大文字・小文字と、拡張子を含むワークフローファイル名が対象です。再利用可能な（workflow_call）ワークフローから公開する場合は、呼び出し元のファイルに対して検証されます。
• OIDC は、侵害されたワークフローを安全にするものではありません。保存されたシークレットの窃取を防ぐだけです。ワークフローファイルのレビューは引き続き重要です（.github/ に CODEOWNERS を設定）。
• タグ付け後に失敗すると、npm に存在しないバージョンがあるように見えてしまいます。順序の制御か冪等性のどちらかを、明確に選んでください。
• npm 側の詳細（最小要件、段階的な公開、トークンの有効期間）は変化します。プレイブックではそれぞれを一次情報源とともにバージョンごとに記載しています。設定時に再確認してください。

ファイル

• references/release-playbook.md — ツールの判断表、バージョンごとの要件とドキュメントリンクを含む OIDC の設定、ブートストラップ手順、公開ワークフローの YAML、失敗時の順序パターン、dist-tag／プレリリースに関するガイダンス。