跳到正文
cccskills
免费在 GitHub 公开中文介绍

npm-trusted-publishing

将 GitHub Actions 的 npm 发布从保存的令牌迁移到使用短期凭证的可信发布,并检查工作流权限、工具版本和包设置,诊断认证失败或仓库信息不匹配。

原文查看原文说明

Set up or fix npm trusted publishing (OIDC) in GitHub Actions and remove NPM_TOKEN. Use for ENEEDAUTH, E404 on PUT, E422 repository.url, or migrating off 2FA-bypass tokens before January 2027.

github/awesome-copilot星标 40,567(GitHub 40,567 + cccskills 0)
集成工具GitHub

实测评分 未实测

查看安装方法

适用场景

  • 替换 npm 发布所用的保存令牌
  • 排查 ENEEDAUTH 或 E404
  • 修复 repository.url 导致的 E422
  • 应用前检查配置变更

中文介绍

功能

此技能帮助您将 GitHub Actions 的 npm 包发布从保存的 NPM_TOKEN 迁移到可信发布。可信发布使用 OIDC,即短期认证机制。技能会检查工作流权限、npm 版本、环境变量和 npm 上的发布者注册信息,也会协助排查发布时的 ENEEDAUTH、E404,以及与 repository.url 有关的 E422 错误。

适用场景

如果您希望从工作流中移除发布令牌,或迁移过程中发布失败,可以使用此技能。它可以通过 go-tokenless 显示拟议的差异和所需命令,并说明如何应用配置变更。

使用示例

  • “将这次发布迁移到可信发布,并检查是否还留有令牌配置。”
  • “查明 npm 发布因 ENEEDAUTH 失败的原因。”

注意事项

此流程需要 GitHub 托管的运行器和 npm 11.5.1 或更高版本。在 npm 上注册发布者以及删除旧令牌,需要用户登录 npm 并完成双重验证。尚不存在的包需要先手动发布一次。只有在不使用令牌的发布成功后,才删除或撤销旧令牌。

本介绍由 AI(OpenAI Codex)根据公开的 SKILL.md 撰写。准确的规格请查看下方原文。

文档检查

AI 根据 SKILL.md 的内容检查了需要注意的操作和使用前提。评分只依据实际运行的结果(实测对比)。

安全性发送数据、删除文件、执行命令等是否有说明
A良好资料要求避开不安全触发器,并在发布成功后再删除令牌。
安装难易度所需工具和 API 密钥是否少且有说明
B部分不足需要 GitHub 托管运行器、npm 11.5.1 以上、npm 登录和双重验证。

不计入评分。 由 AI(OpenAI Codex)于 2026年10月25日 评估。仅供参考,安装前请同时查看原文。

如果您认为评估有误,请申请复核

请写明哪一项有误以及原因。无需登录。我们会对照 SKILL.md 重新评估,并在此处更新结果。

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

包含的文件(1)

  • SKILL.md5.1 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

npm Trusted Publishing

Moves a GitHub Actions release from a stored NPM_TOKEN to npm trusted publishing. GitHub signs a short-lived OIDC token for the run, and npm exchanges it for a publish token. It also diagnoses the misleading errors a half-finished migration produces. From January 2027, granular tokens that bypass 2FA can no longer publish directly (npm docs).

When to Use This Skill

  • The user wants to remove NPM_TOKEN / NODE_AUTH_TOKEN from a release workflow or set up OIDC or provenance publishing.
  • A CI publish fails with ENEEDAUTH, 404 Not Found - PUT https://registry.npmjs.org/... or E422 ... repository.url.
  • Release logs show npm notice npm tokens that bypass 2FA are being restricted.

Checklist (all must hold)

Work through every item. Missing any one of them produces the errors above.

  1. OIDC permission: the publishing job has permissions: id-token: write. If the job had no permissions block, keep the scopes it needs, such as contents: write for tags and releases or pull-requests: write for changesets. Adding a block drops every scope you don't list.
  2. npm 11.5.1 or newer runs the publish. Node 24 ships it. Node 22 ships npm 10, so add npm install -g npm@^11.5.1 (or a newer pinned major) before publishing. pnpm 10 hands the publish to npm, so the same rule applies. Yarn Berry needs 4.10.3+.
  3. No token reaches the publish step. Remove NODE_AUTH_TOKEN, NPM_TOKEN and YARN_NPM_AUTH_TOKEN from the step, the job and the workflow env, and delete script lines that write _authToken or npmAuthToken. npm tries OIDC first but falls back to a configured token, so a leftover token keeps the old credential in use. Keep a read-only token only on install steps that need private packages.
  4. actions/setup-node has registry-url: https://registry.npmjs.org.
  5. package.json repository.url names the same GitHub repo, for example git+https://github.com/OWNER/REPO.git, plus directory for workspace packages. A mismatch gives E422.
  6. A trusted publisher exists on npm for each package (npmjs.com → package → Settings → Trusted publishing), or with npm 11.15+: npm trust github <pkg> --repo OWNER/REPO --file release.yml --allow-publish --yes
    • The workflow file name must match exactly; it is case-sensitive and includes .yml.
    • For a reusable workflow, use the calling workflow's file name, and grant id-token: write in the caller too.
    • If the job uses environment:, set the same environment on the publisher.
    • A package that doesn't exist yet must be published once by hand first.
  7. GitHub-hosted runner. Self-hosted runners can't use trusted publishing.

Security Rules

  • Untrusted triggers: never add id-token: write to a job in a workflow triggered by pull_request_target, issue_comment, workflow_run or discussion. It would let outsiders exchange an OIDC token and publish. Move publishing to release, push (tags) or workflow_dispatch.
  • Dry runs: npm publish --dry-run and npm pack jobs don't publish, so they need no id-token and no trusted publisher.
  • The old token: delete the secret (gh secret delete NPM_TOKEN) and revoke it on npmjs.com only after the first tokenless release succeeds.

Error Guide

ErrorUsual cause
ENEEDAUTHNo id-token: write, npm older than 11.5.1, or a workflow file name that doesn't match the trusted publisher
404 Not Found - PUT https://registry.npmjs.org/<pkg>Same as above, a mismatched environment, no trusted publisher yet, or an expired token still being used
E422 ... repository.urlrepository is missing in package.json or names another repo
Publish still uses the tokenA token remains in env, .npmrc or .yarnrc.yml (checklist item 3)

Example

jobs:
  publish:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v6
        with:
          node-version: 24
          registry-url: https://registry.npmjs.org
      - run: npm ci
      - run: npm publish --access public   # no NODE_AUTH_TOKEN

Automating It

go-tokenless (MIT) applies this checklist to an existing repository. Use it when the user wants the edits made for them.

  • npx go-tokenless prints a read-only diff of the workflow and package.json changes, plus the npm trust commands.
  • npx go-tokenless apply writes the changes.
  • It refuses the unsafe cases above instead of guessing.

Limitations

  • The npm side (adding the trusted publisher, deleting the old token) needs the user's npm login with 2FA. Hand those steps to the user.
  • Trusted publishing covers GitHub Actions, GitLab.com and CircleCI cloud only.

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

扫描现有项目的代码与配置,生成涵盖技术栈、结构、架构、规范、集成、测试和风险的七份文档。为结论标注文件依据和未知项,并指出计划描述与实际实现的差异。

  • 了解陌生代码库
  • 准备项目交接文档
  • 对照设计资料与实际实现
github/awesome-copilot4.1万2026年10月29日 更新

acreadiness-assess

免费有简介

使用AgentRC评估代码仓库对AI智能体的准备情况,并生成可独立打开的HTML报告。查看九个方面的评分和优先改进建议,也可按组织自定评分政策。

  • 引入AI智能体前检查准备情况
  • 根据评估结果安排改进优先级
  • 按组织自定政策评分
github/awesome-copilot4.1万2026年10月29日 更新

使用AgentRC分析项目代码中的语言、框架和开发惯例,生成或更新AI编程代理的指令文件。可集中写入一个文件,也可按主题和项目区域拆分,并在写入前预览改动。

  • 创建VS Code Copilot指令
  • 将开发规则变更写入指令
  • 按单体仓库区域整理规则
github/awesome-copilot4.1万2026年10月29日 更新

acreadiness-policy

免费有简介

按团队或组织标准调整AgentRC准备度评估。可选择或创建JSON策略,调整检查权重、停用无关检查、设置通过率,并在CI流程中设定自动检查门槛。

  • 制定组织共用的评估标准
  • 只评估AI相关的准备情况
  • 调整特定检查项的权重
github/awesome-copilot4.1万2026年10月29日 更新

ad-campaign-analyzer

免费有简介

分析你提供的广告成效数据,找出浪费支出和表现较好的广告,并整理暂停、加预算或继续测试的候选项。还可比较不同平台、评估A/B测试差异,并提出预算调整建议。

  • 找出应暂停的广告或关键词
  • 发现适合增加预算的广告系列
  • 判断A/B测试的数据是否足够
github/awesome-copilot4.1万2026年10月29日 更新

为指定代码文件添加学习注释,解释语法、编程概念和设计选择;可按读者水平调整讲解深度和重复频率,并保持文件结构、编码与语法。

  • 为现有代码添加初学者说明
  • 解释语法或设计选择的原因
  • 按读者经验调整注释内容
github/awesome-copilot4.1万2026年10月29日 更新

查看 github 的全部技能

报告此技能的问题