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 是更彻底但更大的一次改造。

备注

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions