publish-npm-package

npm パッケージを公開する

認証、バージョン管理、パッケージマネージャーのインストール、ワークフローのトリガー、プロベナンス、検証、復旧を含む、完全で内部整合性の取れたリリースフローを GitHub Actions で設定します。判断基準とルーティングはこちらに記載し、YAML の全体像とツールの詳細は references/ に記載します。

使用するタイミング

次のような依頼には、このスキルを使用します。

• 「このパッケージを npm に公開して」、「npm 公開を設定して」、「npm リリースを自動化して」
• 「GitHub Actions から npm に公開」、「npm のリリースワークフロー」、「npm CI/CD」
• 「信頼された公開」、「npm の OIDC」、「NPM_TOKEN のプロベナンス」、「id-token: write」
• 「semantic-release」、「changesets」、「release-please」、「バージョン更新を自動化して」
• 「新しいパッケージを初めて公開」、「npm パッケージの初期設定」、「GitHub リポジトリを npm にリンク」
• 「npm の公開が失敗する理由」、「CI での EOTP / ENEEDAUTH / E403」、「Actions での npm whoami」

このスキルを適用すべき package.json／リポジトリのシグナル：

• "name" フィールドに加えて "version" があり、repository.url が GitHub を指している
• .github/workflows/*.yml に npm publish、setup-node、id-token: write、または NPM_TOKEN がある
• .npmrc に //registry.npmjs.org/:_authToken または ${NODE_AUTH_TOKEN} がある
• .releaserc*、release.config.js、.changeset/、または .release-please-*.json がある
• スコープ付きの名前（@scope/name）と publishConfig.access の設定がある

次の場合は、このスキルを使用しないでください。

• アプリやサービスを実行環境にデプロイする（Railway、Vercel、Fly）— プラットフォーム用スキル（例：run-railway）を使用します
• パッケージ自体の実行時コード、SDK 内部、または API を作成する — 該当する build-* スキルを使用します
• npm が対象に含まれない状態で、npm 以外のレジストリ（Docker Hub、GHCR、PyPI、crates.io）に公開する
• CI やリリース自動化の文脈がなく、実行する npm／パッケージマネージャーのコマンドだけを尋ねている

まず認証を決め、次にバージョン管理を決めてから、ワークフローテンプレートに進みます

必ずこの順序で進めてください。順序を飛ばすと、リリース自動化の設定が不完全になります。

1. リポジトリを分類します（下の表を参照）。
2. 認証方式を選びます：OIDC による信頼された公開、またはトークン（NPM_TOKEN → NODE_AUTH_TOKEN）。
3. バージョン管理方式を選びます：semantic-release、changesets、release-please、または手動。
4. references/workflows/ にある該当するワークフローテンプレートに進みます。
5. パッケージ／リポジトリの前提条件と、ロックファイル／パッケージマネージャーを確認します。
6. npm pack --dry-run、CI でのビルド／テスト、ツール固有のドライランで検証します。
7. リポジトリが移行中、またはすでに失敗している場合は、末尾の復旧ルーティングに進みます。

まずリポジトリを分類します

以下に回答し、回答を記録してください。以降のすべての判断に影響します。

1. パッケージは公開ですか、非公開ですか？
2. GitHub ホステッドランナーで GitHub Actions を使用していますか（セルフホスト／GHES／GitHub 以外の CI と比較）？
3. 単一パッケージですか、モノレポ／ワークスペースですか？
4. Conventional Commits を実際に使用していますか（意味のあるコミットの大半が type: description 形式ですか）？
5. リリース可能なマージごとに自動公開しますか、それとも人がレビューする Release／Version PR を作成しますか？
6. 新規（未公開）ですか、それともタグ／バージョンを付けてすでに公開済みですか？
7. 対象は本当に npmjs.org ですか？

package.json とワークスペースのマニフェスト → 既存のワークフロー → Git のリモート／タグ → npm レジストリの状態から回答を導き出します。それでも不明な場合は、推測せずに作業を止めて確認してください。

判断マトリクス

公開？	GH ホステッドランナー？	単一／モノレポ	Conventional Commits？	ゲート	認証	バージョン管理
はい	はい	単一	はい	自動	OIDC	semantic-release
はい	はい	単一	はい	人によるレビュー	OIDC	release-please
はい	はい	単一	いいえ	人によるレビュー	OIDC	changesets
はい	はい	単一	いいえ（新規で、今後導入する）	人によるレビュー	OIDC	release-please
はい	はい	モノレポ	任意	任意	OIDC	changesets（デフォルト）
いいえ	任意	任意	任意	任意	トークン	（任意）
任意	いいえ（セルフホスト／GHES）	任意	任意	任意	トークン	（任意）

認証レーン — 混同しないでください

レーン	使用する場面	要件	公開方法	来歴情報
OIDC 信頼済み公開	公開パッケージ、公開リポジトリ、GitHub ホストランナー、npm ですでにリンク済みのパッケージ	npm トークン不要、id-token: write、contents: read、npm CLI 11.5.1 以上、Node 22.14.0 以上	npm publish --access public	条件を満たす公開パッケージでは自動 — --provenance を追加しないでください
トークン＋来歴情報	トークン認証が必要で、公開する来歴情報も必要な場合	NODE_AUTH_TOKEN、id-token: write、クラウドランナー、npm CLI 9.5.0 以上	npm publish --provenance --access public	明示的なフラグ、NPM_CONFIG_PROVENANCE=true、またはツールの設定
トークンのみ	プライベートパッケージ、セルフホストランナー、GHES、プライベートレジストリ、初回公開	NODE_AUTH_TOKEN。id-token は不要	npm publish --access public	なし

認証ルール：

• 対応している場合は、常に OIDC を優先してください。信頼済み公開では npm シークレットは不要です — 公開ステップに NODE_AUTH_TOKEN または NPM_TOKEN が設定されている場合、id-token: write が設定されていても、信頼済み公開ではなくトークン認証です。
• OIDC を使用するには、パッケージが すでに npm に存在している必要があります。新規パッケージの初回公開では、必ずきめ細かなトークンで初回公開し、その後 npm でリポジトリをリンクしてから OIDC に切り替えます。
• OIDC はセルフホストランナーでは動作しません。その場合は、きめ細かなトークンを使用してください。
• secrets.NPM_TOKEN を NODE_AUTH_TOKEN として公開します。CI で npm login を実行しないでください。新しい作業では従来型の自動化トークンを避けてください。
• リポジトリまたはワークフローの単位ごとにきめ細かなトークンを 1 つ使用し、定期的にローテーションしてください。

各レーンの詳細：

• references/auth/oidc-trusted-publishing.md — OIDC の初回設定、リポジトリのリンク、来歴情報のデフォルト設定
• references/auth/granular-tokens.md — きめ細かなトークンの作成、スコープ設定、ローテーション、シークレットの設定

ローカル公開と CI 公開 — 使用中のモードを把握する

この 2 つを混同すると、EOTP / ENEEDAUTH エラーが発生する最大の原因になります。

ガードレール： NODE_AUTH_TOKEN を環境変数だけで設定しても、.npmrc に ${NODE_AUTH_TOKEN} が含まれている場合にのみ機能します。GitHub Actions では、registry-url が設定されている場合に actions/setup-node がそのファイルを書き込みます。開発者のマシンでは、プレースホルダーを含む .npmrc がない限り、npm は NODE_AUTH_TOKEN を無視します。

ローカル公開（開発者のターミナル）

トークンを発行する前に、既存の認証を確認します：

npm whoami --registry https://registry.npmjs.org
echo "${NPM_TOKEN:+NPM_TOKEN is set}"
cat ~/.npmrc 2>/dev/null | grep -v authToken | head
grep -l 'NPM_TOKEN' ~/.zshrc ~/.bashrc ~/.zprofile ~/.bash_profile 2>/dev/null

トークンを設定します（どちらかを選択）：

# 1) CLI flag (most reliable locally; do NOT use in CI logs)
npm publish --access public --//registry.npmjs.org/:_authToken="${NPM_TOKEN}"

# 2) Temporary .npmrc (session-scoped)
echo "//registry.npmjs.org/:_authToken=${NPM_TOKEN}" > .npmrc
npm publish --access public
rm .npmrc

# 3) Browser 2FA login (no token needed)
npm login && npm publish --access public

ガードレール： --//registry.npmjs.org/:_authToken=TOKEN は、ローカルターミナルではセキュリティリスクではありません。references/auth/granular-tokens.md の「誤り」というラベルは、CI ログにのみ適用されます。

CI 公開（GitHub Actions）

純粋な信頼済み公開 — npm シークレットなし：

permissions:
  contents: read
  id-token: write
steps:
  - uses: actions/setup-node@v6
    with:
      node-version: '24'
      registry-url: 'https://registry.npmjs.org'
      package-manager-cache: false
  - run: npm publish --access public

トークン認証 — 公開ステップでの NODE_AUTH_TOKEN 環境変数と、registry-url を設定した setup-node：

- uses: actions/setup-node@v6
  with:
    registry-url: 'https://registry.npmjs.org'
    package-manager-cache: false
- run: npm publish --access public
  env:
    NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

「トークンで 2FA を回避できるはずなのに EOTP が発生する」場合の診断

「Bypass 2FA」を設定したきめ細かな自動化トークンを使っても EOTP が発生する場合：

1. npm はトークンを使用していません — インタラクティブなセッション認証にフォールバックしています。
2. npm whoami を実行します。個人のユーザー名が表示される場合、セッション認証が有効になっています。
3. 設定を修正します（ローカルでは CLI フラグ、CI では setup-node ＋ NODE_AUTH_TOKEN）。トークンをローテーションしないでください。

npm whoami では、信頼済み公開を検証できません。OIDC 認証は npm publish の実行中にのみ適用されます。

バージョニングモデル — ツールではなく、モデルを選択してください

要件	選択肢	使用する場合	避ける場合	参照先
リリース可能なマージのたびに公開する	semantic-release	単一パッケージで、Conventional Commits を厳格に運用し、人的な承認ゲートを設けない場合	モノレポ、コミットの規約が徹底されていない場合、レビュー可能な Release PR を求めるチーム	references/versioning/semantic-release.md
レビュー可能な Release PR を作成し、マージ時に公開する	release-please	Conventional Commits が存在し、チームが人的なマージゲートを求める場合	信頼できないコミットメッセージ、またはゼロからの扱いを対象とする場合	references/versioning/release-please.md
PR ごとにバージョンの意図を示し、リリースをまとめて行う	changesets	モノレポ、Conventional Commits を使用していない単一パッケージ、明示的なバージョンノートが必要な場合	人が作成したバージョン情報なしで、マージ時の公開を望むリポジトリ	references/versioning/changesets.md
まれなリリース／シンプルなリリース	手動トリガー + npm version	自動化のコストがリリース頻度に見合わない場合	タスクで完全な自動化が明示的に求められている場合	該当するワークフローファイルの「手動トリガー」セクション

バージョニングのルール：

• モノレポのデフォルトは changesets です。Conventional Commits がすでにリポジトリを運用する基準になっている場合に限り、release-please を使用してください。
• changesets はモノレポ専用ではありません。Conventional Commits を使用せず、人がレビューする Version PR を求める単一パッケージのリポジトリにも適しています。
• 新規プロジェクト（「チームが今後 Conventional Commits を導入する」）と、既存のリポジトリ（「コミットにすでに Conventional Commits がない」）を区別してください。履歴に一貫性がない既存のリポジトリでは、semantic-release ではなく changesets を使用します。
• すでに公開されているパッケージでは、最初の自動実行の前にベースラインの状態を整えてください（semantic-release では初期タグ、release-please では設定とマニフェストの整合、changesets では設定の初期化）。

ガードレール： release-please マニフェストの「現在のバージョン」は、package.json に記載されたバージョンです。一度も公開されていない新規パッケージでは、package.json に記載された値（通常は 1.0.0 または 0.1.0）を設定してください。0.0.0 と推測して設定しないでください。

ワークフローテンプレート — 記憶を頼りに YAML を手作業で組み立てないでください

認証	バージョニング	テンプレート
OIDC	semantic-release	references/workflows/oidc-workflows.md → 1. OIDC + semantic-release
OIDC	changesets	references/workflows/oidc-workflows.md → 2. OIDC + changesets
OIDC	release-please	references/workflows/oidc-workflows.md → 3. OIDC + release-please
OIDC	手動トリガー	references/workflows/oidc-workflows.md → 4. OIDC + 手動トリガー
トークン	semantic-release	references/workflows/token-workflows.md → 1. Token + semantic-release
トークン	changesets	references/workflows/token-workflows.md → 2. Token + changesets
トークン	release-please	references/workflows/token-workflows.md → 3. Token + release-please
トークン	手動トリガー	references/workflows/token-workflows.md → 4. Token + Manual Trigger

モノレポ：ワークスペースのワークフローを選択する前に、references/monorepo-publishing.md を読んでください。changesets のテンプレートを優先し、Conventional Commits がすでに存在する場合は release-please を使用してください。モノレポで semantic-release をデフォルトとして使用しないでください。

ガードレール： 完全な GitHub Actions YAML の正本はワークフローテンプレートです。バージョニングのリファレンスでは、ツールの設定、カスタマイズ、ツール固有の失敗例を説明します。単独で使える YAML の参照元ではありません。

実装前の前提条件

パッケージとリポジトリ

• GitHub リポジトリにコードをプッシュします。
• package.json.repository.url が GitHub リポジトリの URL と、大文字・小文字も含めて完全に一致していることを確認します。
• 公開スコープ付きパッケージでは、publishConfig.access: "public"（または同等の設定）を指定します。
• トラステッドパブリッシングのみを使用する場合は、publishConfig.provenance を設定しないでください。npm は対象となる公開パッケージの provenance を自動生成します。provenance の設定は、トークンと provenance を併用する方式でのみ必要です。
• ロックファイルをコミットし、CI では対応する決定的なインストール方法を使用します。
• npm pack --dry-run の結果が意図した tarball と一致することを確認します。main／module／types／exports が dist/ を指しているのに、src/ が含まれている場合は、CI を変更する前に作業を止めてパッケージングを修正します。
• パッケージングの構成（files、exports、型定義、ESM／CJS の両対応）：references/package-config.md。

ロックファイルとパッケージマネージャーの判定

ロックファイル／マーカー	インストール	備考
package-lock.json または npm-shrinkwrap.json	npm ci	他のパッケージマネージャーを使用していない場合のデフォルト
pnpm-lock.yaml	pnpm install --frozen-lockfile	Corepack で pnpm を有効にします
yarn.lock ＋ .yarnrc.yml または packageManager: yarn@…	yarn install --immutable	Yarn Berry／モダン Yarn
Berry のマーカーがない yarn.lock	yarn install --frozen-lockfile	Yarn Classic
bun.lockb	bun install --frozen-lockfile	リポジトリですでに Bun を使用している場合のみ

複数のロックファイルがある場合は、リリース自動化を変更する前に作業を止め、使用するパッケージマネージャーを一本化します。

CI

• registry-url: https://registry.npmjs.org を指定して actions/setup-node を使用します。
• ビルドとテストは、公開と同じジョブで実行するか、公開より前に実行します。
• 公開の競合を避けるため、concurrency を設定します。
• 権限は最小限にし、明示的に指定します。
• テンプレートでは actions/setup-node@v6 と Node 24 を使用します。タグを参照できる例をリポジトリで意図的に維持している場合を除き、package-manager-cache: false を指定します。
• 本番環境では、タグのコメントを付けてアクションを完全な SHA に固定します。詳しくは references/supply-chain.md を参照してください。

初回公開のブートストラップ（新規プロジェクト → OIDC）

ガードレール： トラステッドパブリッシングを使用するには、対象のパッケージがすでに npm 上に存在している必要があります。新規パッケージは、トラステッドパブリッシングを連携する前に、トークン認証でブートストラップする必要があります。

1. npmjs.com で詳細なアクセス権を持つトークンを作成します（references/auth/granular-tokens.md）。
2. GitHub Actions のシークレットに NPM_TOKEN として追加します。
3. 1 回公開します：npm publish --access public を実行するか、初回リリースにトークンベースのワークフローテンプレートを使用します。
4. https://www.npmjs.com/package/<your-package>/access にアクセスし、Publishing access → Add GitHub Actions の順に選択してリポジトリを連携します。
5. NPM_TOKEN を削除し、ワークフローを OIDC のみを使う構成に切り替えます。

移行の前提条件

• semantic-release：完全な Git 履歴（fetch-depth: 0）とベースラインタグが必要です。
• release-please：設定とマニフェストを、現在の package.json のバージョンに合わせます。
• changesets：changeset を追加するためのコントリビューター向けルールと、空の changeset の明確な扱いが必要です。

ガードレール — 中途半端に設定されたリリース自動化は、何もしないより悪い

• きめ細かいトークンより OIDC を、クラシックな自動化トークンよりきめ細かいトークンを優先してください。
• 強い既存の理由がない限り、モノレポでは semantic-release より changesets を優先してください。
• チームが人間によるレビューを経る Release PR を望む場合は、semantic-release より release-please を優先してください。
• 記憶を頼りに YAML を作るのではなく、参考資料にあるワークフローテンプレートを優先してください。
• 実際に Conventional Commits を使用しておらず、fetch-depth: 0 を設定しておらず、選択した認証方式をサポートする最新のツールチェーンを使っていない場合は、semantic-release を選ばないでください。
• release-please には2 ジョブパターンが必要です。1 つ目のジョブで Release PR を作成・更新し、2 つ目の公開ジョブは release_created == 'true' の場合にのみ実行します。
• セルフホストランナーで OIDC が機能すると思い込まないでください。
• トークンを含む .npmrc ファイルをコミットしないでください。プレースホルダーベースの .npmrc は問題ありませんが、実際のトークンを含めてはいけません。
• スコープ付きパブリックパッケージへのアクセスを忘れないでください。スコープ付きパッケージでの E403 は、たいてい publishConfig.access: "public" が設定されていないことを意味します。
• 信頼されたパブリッシングのみを行う基本設定に --provenance を追加しないでください。トークン＋プロベナンスの構成でのみ使用してください。
• 信頼できないコードにリリースシークレットを公開するために pull_request_target を使用しないでください。
• リポジトリが移行の途中なら、認証、バージョン管理、ワークフロー、ブートストラップをまとめて完了させてください。中途半端な状態でリリースしないでください。

検証スクリプト

同梱ヘルパー — フラグについては対応する .md を読み、通常の使用時にスクリプトのソースを読み込まないでください。

スクリプト	用途
scripts/check-package-json.mjs	package.json を調査し、パッケージマネージャー／ロックファイルを検出して、メタデータと src／dist の不一致を警告します。JSON と人間向けの出力を生成します。
scripts/dry-run-publish.sh	公開せずに npm pack --dry-run（および任意で npm publish --dry-run）を実行します。
scripts/check-npm-auth.sh	トークン認証の診断を行います。トークン環境変数の有無と、トークン認証を使用する場合の npm whoami を確認します。信頼されたパブリッシングは検証しません。

完了を宣言する前の検証

必ず次を実行してください。

• scripts/check-package-json.mjs [package-dir]（または対象リポジトリでの同等のコマンド）
• scripts/dry-run-publish.sh [package-dir] または npm pack --dry-run
• 公開と同じワークフロー内でのビルドとテスト
• 選択したバージョン管理ツールがインストールされているだけでなく、実際に組み込まれていることの確認

認証方式ごとの確認事項：

確認項目	OIDC	トークン
ランナー	GitHub ホスト型／対応するクラウド	任意
権限	contents: read、id-token: write	トークン＋プロベナンスを使用する場合を除き不要
レジストリ	setup-node → registry-url: https://registry.npmjs.org	同左
シークレットの設定	なし（NODE_AUTH_TOKEN なし）	NPM_TOKEN シークレット、公開時の NODE_AUTH_TOKEN 環境変数
認証診断	公開時のみ。npm whoami では OIDC を証明できません	scripts/check-npm-auth.sh --token または npm whoami
公開後	npm audit signatures	プロベナンス／署名が想定される場合のみ npm audit signatures

ツールごとの確認事項：

ツール	ドライラン	主なファイル	重要な確認事項
semantic-release	npx semantic-release --dry-run	.releaserc / release.config.js	Git の全履歴、基準タグ、プラグインの順序
changesets	npx changeset status	.changeset/config.json	リリース／バージョン PR の手順がテンプレートと一致していること
release-please	release-please release-pr --repo-url=<owner/repo> --token=TOKEN --dry-run（任意）	.release-please-config.json、.release-please-manifest.json	マニフェストのバージョンが package.json と一致していること。公開は release_created == 'true' を条件に実行すること

ガードレール： release-please には、組み込みのドライラン機能に相当するものがありません。設定ファイルとマニフェストファイル、およびマニフェストと package.json の整合性を確認してください。

出力の要件

セットアップまたは診断が完了したら、以下を報告してください。

• 選択した認証方式とバージョニングモデル
• 変更したファイル
• 正確な公開ワークフローのトリガー
• パッケージ名、バージョン、npm dist-tag
• npm パッケージの URL（https://www.npmjs.com/package/<name>）
• フローで作成される場合は、GitHub リリース／タグの URL
• 実際に実行した検証コマンド
• プロベナンス／署名の検証状況
• 公開に失敗した場合、または誤った内容を公開した場合のロールバックまたは復旧に関する注記

復旧先の選択

既存の障害に関するタスクの場合は、最も対象を絞ったリファレンスをすぐに参照してください。

問題	最初に読むもの	確認事項
OIDC／プロベナンスの障害	references/common-issues.md、次に references/auth/oidc-trusted-publishing.md	id-token: write の不足、contents: read の不足、リポジトリ URL の誤り、セルフホストランナー、npmjs のレジストリ設定の不足
トークン認証の障害	references/common-issues.md、次に references/auth/granular-tokens.md	トークンの期限切れ、スコープの誤り、シークレットの誤った設定、ローテーションのミス
semantic-release の障害	references/common-issues.md、次に references/versioning/semantic-release.md	シャロークローン、ベースラインタグの不足、リリース対象にならないコミット、古いプラグインバージョン
changesets の障害	references/common-issues.md、次に references/versioning/changesets.md	changesets の追加忘れ、リリース PR のずれ、アクセス／公開設定、プレリリース状態
release-please の障害	references/common-issues.md、次に references/versioning/release-please.md	マニフェストのずれ、リリース対象のコミットがない、重複または停滞した Release PR、公開ゲートの不具合
誤ったバージョンを公開した／パッケージに不具合がある	references/common-issues.md	許可される場合は72時間以内にアンパブリッシュし、それ以外の場合は非推奨にして修正版を公開する
トークン漏えい／セキュリティインシデント	references/supply-chain.md	無効化、ローテーション、公開履歴の監査、リリースを再開する前にワークフローを強化する

シナリオ別の最小限の参照セット

• 公開単一パッケージ、全自動： references/auth/oidc-trusted-publishing.md + references/versioning/semantic-release.md + references/workflows/oidc-workflows.md（#1）+ references/supply-chain.md。
• 公開単一パッケージ、レビュー可能なゲート： references/auth/oidc-trusted-publishing.md + references/versioning/release-please.md または references/versioning/changesets.md + references/workflows/oidc-workflows.md（#3 または #2）+ references/supply-chain.md。
• モノレポ／ワークスペース： references/monorepo-publishing.md + references/versioning/changesets.md（デフォルト）または references/versioning/release-please.md + 対応する OIDC／トークンワークフローのセクション + references/supply-chain.md。
• プライベートパッケージ、セルフホストランナー、または GitHub 以外の CI： references/auth/granular-tokens.md + 選択したバージョニングのリファレンス + references/workflows/token-workflows.md の該当セクション。
• 既存のワークフローで障害が発生： references/common-issues.md + 現在のモードに対応する認証リファレンス + 現在のツールに対応するバージョニングリファレンス。

既知の落とし穴 — クイックリファレンス

落とし穴	影響	対処
ローカルで setup-node の .npmrc を設定せずに NODE_AUTH_TOKEN 環境変数を使う	P0 — npm がトークンを無視し、対話型ログインにフォールバックして EOTP が発生します	ローカルでは --//registry.npmjs.org/:_authToken=TOKEN を使い、CI では setup-node と NODE_AUTH_TOKEN を併用します
EOTP が発生し、トークンの種類が間違っていると思い込む	P0 — 誤診	EOTP は、npm がトークンではなく対話型セッション認証を使っていることを意味します。トークンではなく設定を修正してください。
既存の NPM_TOKEN がないか ~/.zshrc / ~/.bashrc を確認しない	P1 — トークンが重複して発行されます	ユーザーに新しいトークンを求める前に、grep NPM_TOKEN ~/.zshrc ~/.bashrc を実行します
NODE_AUTH_TOKEN / NPM_TOKEN を設定して「OIDC」と呼ぶ	P0 — 気付かないまま誤った認証になります	OIDC では npm シークレットを一切使いません。スコープ内にトークンがあれば、それはトークン認証です。
一度も公開されていないパッケージを OIDC で初回公開する	P0 — 404	まず granular token で初期設定し、npm でリポジトリをリンクした後に OIDC に切り替えます
conventional commits を使わずに semantic-release / release-please を使う	P0 — リリースがブロックされます	チームが conventional commits を採用しない場合は、changesets を使います
--//registry.npmjs.org/:_authToken=TOKEN は常に誤りだと思い込む	P1 — ローカルでの公開がブロックされます	「誤り」という評価は CI のログにのみ当てはまります。ローカルでは CLI フラグが最も信頼性の高い形式です
changesets はモノレポ専用だと思い込む	P1 — ツール選択の誤り	changesets は単一パッケージのリポジトリでも使え、conventional commits も必要ありません
新規プロジェクトの「採用する予定」と、既存プロジェクトの「採用していない」を混同する	P1 — 誤ったガイダンス	新規プロジェクトでは採用できます。conventional commits を使っていない既存リポジトリには changesets が必要です
ワークフローテンプレートではなく、バージョニングのリファレンスから設定をコピーする	P1 — 設定が一致しません	ワークフローテンプレートを基本とし、バージョニングのリファレンスはカスタマイズに使います
本番環境で @v4 アクションタグを使う	P1 — サプライチェーンリスク	タグコメントを付けて完全な SHA に固定します。references/supply-chain.md を参照してください
release-please のマニフェストのバージョンが package.json と一致しない	P1 — release-please が誤作動します	新規プロジェクトも含め、マニフェストは package.json と完全に一致させる必要があります

最後に

SKILL.md は、判断、手順、ガードレールに焦点を絞ってください。読むのは次のものだけです。

1. 認証リファレンス
2. バージョニングのリファレンス
3. ワークフローテンプレートの該当セクション
4. 必要な場合に限り、references/common-issues.md / references/supply-chain.md

リファレンスに記載済みの内容について、ここで YAML 全体やパッケージングを詳しく掘り下げないでください。