Matt Pocock 技能集
源码分析：Matt Pocock Skills 发布背后的版本同步小脚本
通过六个真实执行的一次性夹具，追踪 sync-plugin-version.mjs 的无操作、只读检查、受保护更新与嵌套字段失败分支。
你将学会
- 先追踪读取，再看唯一写入点
- 不要只验证最顺利的分支
- 明确这些证据还不能证明什么
开始前需要
- 理解基础仓库、工单系统与测试概念
- 能够区分指令内容和执行权限
选择采用方式，并追踪相关文件、权限边界和验证证据。
先看结论
- 检查模式即使遇到版本不一致也不写文件。
- 第一次文本匹配后还有顶层 JSON 版本验证。
- 本地版本一致不证明已分发或已部署。
先追踪读取，再看唯一写入点
维护脚本按自身文件位置定位仓库，读取 package.json 与 .claude-plugin/plugin.json，并解析两份 JSON。目标版本来自 package.json。如果两个版本已经相同，脚本直接成功退出，不重新写入插件文件；带检查参数时遇到不一致，则返回失败并保留原始字节。
更新模式通过正则表达式替换文本中第一个 version 字段，再解析候选结果并核对顶层版本。只有验证通过才执行最后的文件写入。这能为预期清单结构保留原有排版，但它不是一个可以处理任意 JSON 结构的通用编辑库。
不要只验证最顺利的分支
编辑探针先核对固定版本脚本的 Git blob 标识，再把它放进六个新建的本地夹具目录。版本一致时检查通过且文件不变；版本不一致时检查失败但不写入；更新模式只改变预期的版本文本；再次运行同版本输入仍保持原样。整个验证不需要安装依赖或执行真实发布。
另外两个案例检查边界：缺少 version 字段时拒绝修改；嵌套 version 先于顶层字段出现时，文本替换先命中嵌套字段，随后顶层版本验证失败，也在写入之前停止。这是实际观察到的适用范围限制和保护检查，不证明任意清单结构都受支持。
明确这些证据还不能证明什么
测试使用独立写出的预期文档，同时观察退出码和完整文件字节，而不是再运行同一个替换表达式生成“预期结果”。因此，版本不一致和嵌套字段案例真的有能力暴露行为回归。本系列保留了源码标识与探针结果，便于后续复核。
本地同步成功不会发布包、移动市场条目的固定提交，也不会更新用户安装。这个脚本同样没有提供跨多个文件的原子发布事务。应把小范围文件一致性检查，与发布编排和分发验证分开；下一篇会说明怎样评估更大工作流程，而不编造测量结果。
实施步骤
- 1
固定并验证维护脚本的确切源码。
- 2
为不变、检查失败和更新分别准备独立预期文件。
- 3
加入缺失字段与嵌套字段先出现的案例。
- 4
断言退出码和完整字节，不运行真实发布。
可复制示例
{
"executedScript": "scripts/sync-plugin-version.mjs",
"fixtureCases": 6,
"mismatchCheck": {"exitCode": 1, "fileChanged": false},
"nestedFirstVersion": {"exitCode": 1, "fileChanged": false},
"packagePublished": false,
"marketplaceUpdated": false
}常见问题
为什么不直接解析后重写整个 JSON？
固定实现选择只替换一个文本字段来保留排版，这也带来了夹具验证的首次匹配限制。
实际运行过上游脚本吗？
运行过。先验证源码哈希，再对六个一次性本地夹具执行；没有运行技能、安装器、发布或工单操作。
资料来源
- package.json来源核查 2026-09-08
- .claude-plugin/plugin.json来源核查 2026-09-08
- scripts/sync-plugin-version.mjs来源核查 2026-09-08