AI 应用MCP 服务【免费下载链接】Figma-Context-MCPMCP server to provide Figma layout information to AI coding agents like Cursor项目地址https://gitcode.com/gh_mirrors/fi/Figma-Context-MCP点击查看免费下载本文是 Figma-Context-MCPnpm 包名figma-developer-mcp仓库的发布操作指南源于仓库内 .claude/commands/release.md 中沉淀的 Claude Code 发布指令。文章完整覆盖检查待发布 PR → 审阅内容 → 确认合并 → 验证流水线 → 撰写发布说明六个步骤并深入解读 release-please 自动化链条的底层实现GitHub Actions 配置、OIDC 发布、server.json版本同步帮助维护者安全、规范地完成一次版本发布理解为什么合并 release PR 必须用 rebase 而不是 squash等关键决策。发布工作流全景一条近乎零人工的自动化链条Figma-Context-MCP 的版本发布由 release-please 驱动的 GitHub Actions 全自动编排人工环节被压缩到合并一个 PR。核心链路如下开发者向main分支合并带有 Conventional Commit 前缀fix:、feat:、feat!:) 的 PRfeature PR 采用 squash-mergePR 标题即提交信息合并触发 .github/workflows/release.yml 中googleapis/release-please-actionv4的运行release-please 依据提交前缀自动计算版本号、更新 CHANGELOG.md 并开出 release PR标签autorelease: pending维护者人工审查、合并该 release PR触发点在于合并动作而非开 PR 动作合并 release PR 再次触发 Release 工作流自动完成类型检查、构建、以 OIDC 方式发布 npm 包、更新 server.json 版本号、通过mcp-publisher发布到 MCP Registry人工最后一步是调用/release-notes把机械生成的 Release body 润色成有品牌调性的发布说明。从仓库的 release-please-config.json 可以看到 release 的细化配置{ packages: { .: { release-type: node, changelog-path: CHANGELOG.md, bump-minor-pre-major: true, include-component-in-tag: false } } }其中bump-minor-pre-major: true意味着 0.x 阶段按 minor 递增0.x 的 minor 相当于主版本changelog-path指向 CHANGELOG.md——该文件由 release-please 独占维护人工不要改动它详见后文第 6 步。第 1 步检查是否存在待发布的 release-please PR执行以下命令查找处于待发布状态的 release PRgh pr list --repo GLips/Figma-Context-MCP --label autorelease: pending --json number,title,urlrelease-please 会自动为 PR 打上autorelease: pending标签因此用--label过滤即可精准命中。如果返回为空说明当前没有待发布的 release PR此时应向用户说明No pending release PR. Release-please creates one automatically when conventional commits (fix:,feat:) land onmain.这条提示的含义是release PR 是自动产生的无需手动创建——只要fix:/feat:类型的提交合入mainrelease-please 便会自动开 PR。这一点与 CLAUDE.md 中On merge tomain, release-please reads conventional commit prefixes (fix:,feat:,feat!:)的描述相互印证。第 2 步展示本次 release 的内容概览找到 release PR 编号后用下面的命令读取其 bodyrelease-please 生成的 body 中包含待发布的 CHANGELOG 与版本号信息gh pr view number --json body然后向用户总结三点新版本号例如0.13.2可从 package.json 的version字段对照当前已发布版本本次包含的 features、fixes 及其他变更的数量对应 CHANGELOG.md 中各小节标题包含的提交清单。参考 CHANGELOG.md 中0.13.2的条目可以看到 release-please 生成的典型结构——先是版本标题与日期再按Bug Fixes、Features分组列出*前缀的变更条目每条带 PR 编号## 0.13.2 (2026-06-18) ### Bug Fixes * apply paint-level opacity to gradient fills (#399)这种提交标题 PR 编号的平铺列表正是第 6 步里提到的terse commit-title list也是需要被/release-notes润色的对象。第 3 步请求用户确认后决定合并策略用 AskUserQuestion 向用户确认Merge this release PR to publish vversion to npm?提供三个选项Merge and publish—— 直接合并继续发布Review diff first—— 先看完整 diff执行gh pr diff numberCancel—— 停止不合并。这一步是发布流程中唯一的人工把关点确认版本号无误、确认将要发布的变更清单符合预期然后再进入合并环节。第 4 步合并 release PR必须使用 rebase而不是 squash合并命令如下gh pr merge number --rebase --repo GLips/Figma-Context-MCP也可以在 GitHub UI 中直接 merge效果相同。关键原则release PR 必须用 rebase 合并禁止 squash。原指令给出了明确的技术理由理解它能避免踩坑普通 feature PR 采用squash-merge因此每个 Conventional Commit 标题连同(#NNN)编号都会进入 changelog作为 release-please 解析的输入而 release PR 本身是 release-please 自动作者的一个单一提交标题形如chore(main): release X.Y.Zrebase会把这个提交原样回放到main上——保留 bot 作者身份、干净的 subject、不带(#NNN)后缀squash则会重写这个提交及其中的 changelog 内容与历史上所有先前的 release 提交产生分歧。验证方法用git log查看历史上的chore(main): release提交它们全都是单父提交single-parent、bot 作者、无 PR 后缀的形态。合并后应保持这一形态的一致这正是 rebase 的意义所在。第 5 步验证 Release 工作流已触发并跟踪 npm 发布合并完成后执行gh run list --repo GLips/Figma-Context-MCP --limit 1确认 Release 工作流即 .github/workflows/release.yml被触发然后把 workflow run 的 URL 报告给用户便于监控 npm 发布进度。合并 release PR 后触发的工作流做了哪些事从 .github/workflows/release.yml 可以看到完整步骤链release-please-actionv4负责推进版本与生成 GitHub Releasepnpm install→pnpm type-check→pnpm build构建产物进入dist/pnpm publish --no-git-checks配合id-token: write权限与 Node 24 环境走npm OIDC trusted publishing无需在 CI 中保存 npm token用jq把新版本号写入 server.json 的顶层version与packages[0].version供 MCP Registry 清单使用下载并运行mcp-publisher以github-oidc方式登录并执行publish将服务发布到 MCP Registry。关键结论从合并 PR 之后npm 发布、server.json同步、MCP Registry 发布全部自动完成hands-off无需任何额外人工步骤。另外需要注意该工作流的release-please任务带有if: ${{ github.repository_owner GLips }}条件即只有在原仓库作者名下才会实际执行发布镜像仓库如本 mirror不会触发真正的发布动作。第 6 步撰写精品版 Release Notes当工作流已发布 GitHub Release即 tag 已存在后运行/release-notes它的作用是用品牌调性的亮点说明替换掉机械的、自动生成的 Release body。原指令明确指出release-please 只产出一列简短的提交标题terse commit-title list而/release-notes负责把它改写成值得一读的版本说明。需要特别注意的是CHANGELOG.md保持原样不要动它——该文件由 release-please 独占管理与 release-please-config.json 中changelog-path: CHANGELOG.md对应。每次新 release 时 release-please 会覆盖更新它人工改写会在下一次发布时被覆盖属于无效劳动且会引入不一致。附发布流程要点速查表环节命令 / 操作要点查找 release PRgh pr list --repo GLips/Figma-Context-MCP --label autorelease: pending --json number,title,url无结果时告知用户 release-please 会自动创建查看 release 内容gh pr view number --json body总结版本号、变更数量、提交清单人工确认AskUserQuestion三选一合并 / 先看 diff / 取消合并gh pr merge number --rebaserebase 而非 squash保持 bot 单提交形态验证gh run list --repo GLips/Figma-Context-MCP --limit 1确认 Release 工作流已触发发布说明/release-notes润色 Release bodyCHANGELOG.md交由 release-please 管理这套流程把发布这件事从手工执行 npm 命令、手工写 changelog 的繁琐操作收敛为确认 → 合并两步配合 .github/workflows/release.yml 与 release-please-config.json 的自动化配置以及 CLAUDE.md 中PR 标题必须使用 Conventional Commit 前缀的协作约定形成了一条可预测、可审计、可回放的发布流水线。对任何采用 release-please 的 TypeScript 开源项目本文第 4 步关于 rebase/squash 的取舍分析都同样适用。赞分享AI 应用MCP 服务【免费下载链接】Figma-Context-MCPMCP server to provide Figma layout information to AI coding agents like Cursor项目地址https://gitcode.com/gh_mirrors/fi/Figma-Context-MCP点击查看免费下载相关推荐jsPDF 版本发布全流程指南从 GitHub Release 到 npm 自动发布的标准化操作手册jsPDF 版本发布全流程指南从 GitHub Release 到 npm 自动发布的标准化操作手册 本文以 jsPDF 官方仓库的 RELEASE.md h后端Apify MCP Server 发布全流程指南从 GitHub Actions 一键发版到 npm 与 MCP Registry 双轨发布Apify MCP Server 发布全流程指南从 GitHub Actions 一键发版到 npm 与 MCP Registry 双轨发布 Apify MCwinston 发布流程全指南从 GitHub Release 到 npm dist-tag 的完整操作手册winston 发布流程全指南从 GitHub Release 到 npm dist tag 的完整操作手册 本篇指南基于 winston 官方发布文档 do开发工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考