Skip to content

同一套 binding 决策框架在 .claude/ 与已发布 skills/ 各存一份,无任何门禁保持同构 —— #5130 改一份、另一份静默分叉两天 #5798

Description

@os-zhuang

实施 #5451 过程中发现,未认领

现象(实测)

决策评估轴框架这一段 binding 文本在仓库里有两份手写副本:

副本 面向 分发方式
.claude/skills/pm-dispatch/SKILL.md + .claude/agents/os-dev.md 内部 agent 协议 不发布
skills/objectstack-pm-dispatch/SKILL.md(内含 dev-agent 模板) 第三方项目 npx skills add objectstack-ai/objectstack/skills 直读仓库

没有任何门禁检查这两份是否一致。 后果已经实测发生过一次,就是 #5451 本身:#5130(2026-08-04)把内部版由两轴改为三轴,发布版的镜像原封不动,分叉存在了两天,直到有人手工发现,并且需要额外一个 issue + 一轮维护者裁决(泛化与否)才补上(PR 见 #5451)。分叉期间,装了这份 skill 的第三方 PM agent 按两轴呈报,而本仓按三轴。

对比:这一类漂移在本仓已经有门禁的先例,理由写在 .github/workflows/lint.yml 里 —— check:skill-refs / check:skill-docs 覆盖 skills/*/references/_index.md 与 catalog 列表,注释明说「These ship to third parties via npx skills add, so the drift is served straight to consumers' agents」。同一条理由完全适用于 SKILL.md 正文里的 binding 框架,但那部分没有覆盖——现有两个门禁只比对 frontmatter 与生成的索引,不看正文。

两种处置方向(哪一种正确请三轴分诊时定)

倾向先把判据想清楚再动手:如果只想防「一份改了另一份忘了」,A 的最小形态(轴数 + 轴名锚点)就够,且能立刻挡住下一次 #5130;B 是更彻底但更大的一次改造。

备注

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions