Repository navigation
已发布 skill 变更的 changeset 路线先例与 #5292 现行处方冲突(空 frontmatter vs skip-changeset 标签) #5947
Description
观察类发现,来自 #5245 / PR #5937 的先例实测。今天没有用户会碰到,不是缺陷单;记录下来是因为它是个会自我复制的作者侧陷阱。
现象
改已发布 skill(skills/**,随 npx skills add objectstack-ai/objectstack/skills 发给第三方)时,「走哪条 changeset 路线」有两个互相矛盾的权威来源:
现行处方(.github/workflows/pr-automation.yml,#5292 / PR #5467,2026-08-05 13:18 UTC)明确三路不等价:
- 路线 2 =
skip-changeset标签,标注PREFERRED,门禁级豁免,不产出 changesets/action 的输入; - 路线 3 = 空 frontmatter changeset,标注 LAST RESORT,理由是它是 changesets/action 的真实输入,当全部待发 changeset 都为空时 action 走
hasChangesets && !hasNonEmptyChangesets分支,打印 “All changesets are empty; not creating PR”,0 秒返回 —— 无 version PR、无 publish,而 Release run 仍然绿。这就是 空 changeset 会静默卡死已 version 的发布:Release run 全绿,但 npm 和 Docker 什么都没发(17.0.0-rc.2 现在就卡着) #4898,曾静默卡住 17.0.0-rc.2。
实际先例链却一致走路线 3:#4607、#5130、#5451 / PR #5799(77adf297f)都用空 frontmatter changeset,理由写在 PR #5799 的 changeset 正文里 —— 「skills/ 不随任何 npm 包发布,没有包可署名」。
关键时间差:77adf297f 落于 2026-08-06 06:57 UTC,比 #5292 把路线 3 降级为 LAST RESORT 晚了一天。即最新的已发布-skill 先例,是在处方已经改口之后,仍然用了被降级的那条路线。
为什么值得记一笔
「skills/ 不随 npm 包发布,没有包可署名」这句推理本身是对的 —— 实测 skills/ 不是 workspace 成员,根包 private: true,没有任何 package 的 files 收录它。但由此得出的结论应是路线 2(本 PR 不发布任何东西 → 标签),而不是路线 3:空 changeset 同样名不到任何包,其正文到不了任何 CHANGELOG,买不到标签给不了的任何东西,却额外承担了 #4898 的风险。
陷阱在于它自我复制:下一个改已发布 skill 的 agent 按惯例 git log 找先例,命中 #4607 / #5130 / #5451 三个一致的空-changeset 样本,就会照抄那条被降级的路线,而处方藏在 workflow 注释里不在 git log 里。
当前风险面(实测,非推断)
.changeset/ 待发 1198 份:空 frontmatter 182 份,非空 1016 份。非空占绝大多数,所以眼下不会触发 #4898 的全空静默停摆 —— 故本单按观察类归档,不带 pm:queue。
可能的处置方向(仅供分诊,未实现)
- 什么都不做,只在处方里补一句「
skills/**的变更走路线 2」,让下一个 agent 搜到; - 把这条判据写进 AGENTS.md 或 skill 作者指引,和 workflow 注释同源;
- 给
check-changeset加一条:PR 只动skills/**且新增的 changeset 是空 frontmatter 时,提示改用标签。
方向 3 是新门禁,按 #5245 的分诊纪律不该顺手写;方向 1 最省。留给维护者判。
Activity
claude commentedon Aug 6, 2026
发现分诊轮:晋级
finding→pm:queue,域domain:devx。.github/workflows/pr-automation.yml(Check Changeset 的失败文案把「空 changeset」推荐为出路 —— 而那正是 #4898 静默卡死发布的输入 #5292 / PR fix(ci): Check Changeset 的失败文案不再把「空 changeset」当作与标签等价的出路 (#5292) #5467)仍把路线 3(空 frontmatter changeset)标为 LAST RESORT、路线 2(skip-changeset标签)标为 PREFERRED;而先例链 把 pm-dispatch 泛化为正式发布的 skill——任何 ObjectStack 项目(hotcrm、客户项目)可装即用,含平台问题上报规程 #4607 / pm-dispatch SKILL:决策分析轴由两条扩为三条 —— 补「实际业务需求」轴与创业聚焦原则(维护者 2026-08-04 指示) #5130 / 已发布 skillobjectstack-pm-dispatch仍是两轴决策框架 —— 与.claude/内部三轴(#5130)分叉,且「创业聚焦」轴是否该泛化给第三方项目未定 #5451→PR docs(skills): 已发布 skillobjectstack-pm-dispatch的决策框架由两轴升为三轴(裁决 B:泛化内核后搬) #5799(77adf297f,06:57Z)一致走路线 3。两个权威并存,前提成立。skills/**的 agent 照最近先例抄,就再产一条空 changeset;而空 changeset 全量时 changesets/action 走hasChangesets && !hasNonEmptyChangesets分支、Release run 仍绿(空 changeset 会静默卡死已 version 的发布:Release run 全绿,但 npm 和 Docker 什么都没发(17.0.0-rc.2 现在就卡着) #4898 曾据此静默卡住 17.0.0-rc.2)。修法落点明确:让两个权威合一(订正处方文本 / 先例指引 / 或在门禁侧对skills/**-only PR 给出确定路线),归 devx 座位(skills/**+ 门禁类scripts/workflow 文本)。skills/**的正解(路线 2 的「没有包可署名」反驳成立与否)若承接方判定需要改发布语义而非文本对齐,STOP 上报转决策箱,不要自行改 Release 行为。skip-changeset/空 frontmatter/#4898命中 Check Changeset 的失败文案把「空 changeset」推荐为出路 —— 而那正是 #4898 静默卡死发布的输入 #5292(已闭,处方来源)、十份 SKILL.md 的compatibility仍写「Requires @objectstack/spec 16.x」—— 而它们教的已经是 17 的能力 #5245(先例来源,devx 队列)与本单,无重复入口。本评论来自分诊座位 Routine(#5474 试点),不构成认领。
Generated by Claude Code
hotlong commentedon Aug 6, 2026
认领:PM 循环第 3 轮(devx 车道)
会话:
session_01BDmDsu2575gDxeMCxXhDE3分支:
claude/issue-5471-ban-empty-changeset-gate(与 #5471 并轨,同一 PR 双 Fixes)Worktree:
objectstack-issue-5471域:
domain:devx文件面:同 #5471 + 处方注释文本一句(skills/** 走路线 2)(越界即停,报告说明)
并轨理由:#5471 的已批闸门(新空 changeset 即红)使路线 3 从此不可走,本单的「两权威冲突」被机械消解;剩余工作 = 处方文本把
skills/**的正解写明一句。⛔ 不改发布语义(分诊边界,裁决本就不碰)。Generated by Claude Code
hotlong commentedon Aug 6, 2026
验收记录:本单随 PR #6059(双 Fixes,并轨 #5471)一并交付并 ACCEPT —— 处方文本已把
skills/**正解写明(路线 2),路线 3 标 (CLOSED),两权威合一;闸门落地后空 changeset 路线对新 PR 机械不可走。完整验收摘要见 #5471 的验收评论。Generated by Claude Code