Sno Station Skills 是面向 Claude Code 和 Codex 的开源 AI 技能库，以 28 个单元（unit）交付 37 个技能，覆盖代码评审、任务交接、配额监控、夜间自省等团队级能力。它每一次发布的背后，都运行着一条严格的质量流水线：🔍 自测门禁确保每个技能先在干净副本上证明自己，PUBLISHED.json 质量印章记录检查结果，registry.yaml 技能注册表维护"单一事实来源"。三者共同构成了一套可审计、可复现的开源项目发布质量体系。

先认识 Sno Station Skills：一套"装进 AI 智能体"的团队习惯

这个仓库的每个目录都是一个"技能单元"（skills/README.md 是分类索引）：

• J · Peer Review & Audit：跨厂商互审、意图审计、测试编写
• S · Communication & Handoff：任务交接、配额耗尽自动换班（rotate-agent）
• H · Reporting & Visibility：回归简报、评审捕获报告
• T · Delegation & Work Orders：工单、交付证明
• R · Retrospective & Improvement：rem-reflect 夜间学习循环

用户只需一条sno setup，这些技能就会装到机器上的智能体中。但"装得进"不等于"靠得住"——发布前的门禁才是重点。

发布流水线全景：一个只读的"产物仓库" + 六项检查

这个仓库本身是生成的，不是手工维护的。AGENTS.md 开宗明义：

本仓库是已发布的技能库，每次发布时由私有工作仓库生成；在此直接做的改动会在下次发布时被覆盖。

也就是说，AGENTS.md 规定的发布流程是"永远自动"：

1. 私有工作仓库中的发布脚本是唯一入口，一次运行完成：构建整棵树 → 推送到main→ 创建下一个 GitHub release，并把构建产物final-skills.tar.gz作为唯一附件；
2. 用户侧的sno setup只从最新 release 下载final-skills.tar.gz，绝不分叉拉取；
3. "完成"的判定是硬性的：最新 release 指向当前maincommit，且附件 digest 与构建产物的sha256sum一致。

在构建过程中，每个单元都要通过六项检查（README.md 的 "Built to be trusted" 一节）：

⚠️ 核心原则：任何一项检查失败的单元都不会被发布；印章由发布步骤写入，永不手写。

自测门禁详解：run-selftest.sh 是如何工作的

每个技能目录都自带一份 run-selftest.sh，发布构建时逐一执行。它们的设计有一个共同的两层结构。

第一层：文本契约（text contract）

技能本质上是写给智能体看的 Markdown 指令。"行为正确"很大程度取决于关键句子是否被改写或删掉。因此自测会断言SKILL.md中必须存在的关键短语。

以 away-brief 的自测 为例，它用约 20 行 Python 检查诸如"四个章节齐备""不虚构页面上不存在的工作"等规则，缺一即失败。

handoff 技能的 text-check.py 更苛刻：它自带一个仅依赖标准库的 frontmatter 解析器（注释里写明：引入 PyYAML 会让缺少该库的机器装不上技能），然后逐条核对requires:声明，甚至把文中每个sno reach命令片段按 shell 词法切开，验证动词和参数都在 reach-contract.json 契约内——文档写错一条命令，门禁就红。

第二层：行为测试（behaviour test）

文本契约只证明"说的是对的"，行为测试证明"做的是对的"。典型案例：

• peer-review 的自测：在PATH前面放一个假 codex 桩，通过环境变量让它"空回复""挂死""非零退出"，然后断言真实脚本在每条失败路径上的账本（ledger）记录——"干净退出但没写报告"被记为failure=empty，"被看门狗杀掉"被记为failure=watchdog，两者必须可区分；
• first-principles-review 的自测：用合法报告做模板，程序化生成"缺章节""未知处置""JSON 损坏""零研究"等十余种坏报告，逐一断言校验器必须拒绝它们；
• rotate-agent 的自测：用一个 fake-quota 命令喂入精心构造的配额 JSON，验证"剩余额度跌破阈值才触发换班""健康时不多读一个其他智能体"等逻辑。

PUBLISHED.json里的selftests_run字段正是这次执行的计数：大多数单元是 1，e2e是 2，pl是 6——一个单元下的技能越多，要跑通的自测就越多。

PUBLISHED.json：发布最后盖上的"质检印章"

所有检查通过后，发布步骤才写入PUBLISHED.json。看 away-brief 的印章：

{ "unit": "away-brief", "category": "H", "tier": "shipped", "source": { "commit": "e27d56a7…", "unit_tree_clean": true }, "selftests_run": 1, "contract_sha256": "5022662b…", "payload_sha256": "88fc37d2…", "published_at": "2026-10-24T12:04:45Z" }

每个字段的含义：

这枚印章的价值在于防篡改与可验证：内容变了，payload_sha256就对不上；印章只能由发布步骤在最后一步写入，作者无法先盖章后补测。AGENTS.md 也把它列为仓库规则："PUBLISHED.json由发布构建写入，永不手写。"

registry.yaml：技能库的"单一事实来源"

registry.yaml 用极简格式登记每个公开单元——一行一个，机器可读，不许嵌套：

units: peer-review: {cat: J, tier: shipped} handoff: {cat: S, tier: shipped} pl: {cat: T, tier: shipped, split: {pl-analyze: R}}

三个设计点值得新手学习：

• 分类码固定且有序：J M S H T R，同时出现在目录名和注册表中，skills/README.md 与注册表登记同一分类，双处一致即可互相校验；
• tier 是门禁的结论：shipped表示"至少一次通过门禁、进入了已发布版本"；candidate表示"打算发布，但尚未从这个仓库通过门禁"。例如 test-writer 与五个 coder 类技能目前仍是 candidate——同样的自测与印章流程适用于它们，只是 tier 如实反映状态；
• split 处理跨分类成员：pl家族里的pl-analyze属于 R 分类，cos家族里的cos-evolve也属于 R。家族整体安装（保持一行），但成员归属另作登记，索引页 skills/README.md 会把它们列回自己的分类下。

requirements-contract.json：所有依赖声明的"公共规则集"

每个 SKILL.md 头部都有requires:块，声明该技能需要哪些 Sno 程序、智能体需要哪些能力槽（slot）以及需求等级。这些声明不是自由文本，全部对照 scripts/requirements-contract.json 校验：

• program_ids：允许的四个程序（reach、heartbeat、subscription-quota-check、report-time）
• slot_ids：允许的能力槽（如4.shell、4.file-read-write、4.background-processes）
• need_values：只有required/preferred/optional三档
• version_pattern：版本号格式

sno setup读取这份声明后，为每个智能体做三种决定之一：完整安装、降级安装、或跳过——README.md 的 "For skill authors" 一节解释了整套布局与声明规则。声明写错一个词，发布检查第 4 项就会失败，错误根本进不了用户机器。

小结：一套新手可直接复用的质量门禁清单

把 Sno Station Skills 的流水线拆掉外壳，剩下的是一套任何开源项目都能抄的做法：✅

1. 产物仓库只读：改动只来自自动化发布脚本，杜绝手工推送；
2. 安装源是 release 附件而非分支，并用 digest 对账"完成"；
3. 技能自带自测：文本契约管"说法"，行为测试管"做法"，且跑在干净副本上；
4. 印章最后写：PUBLISHED.json记录 commit、自测计数与双摘要，绑定内容、防手写；
5. 注册表单一来源：一行一单元，tier 如实记录门禁状态，跨分类成员用 split 显式登记；
6. 声明对照公共契约：requires:字段的词汇表、格式统一由requirements-contract.json约束。

质量不是发布前的一次评审，而是写进每个技能、随每次发布自动重跑的一串可执行断言——这正是这个仓库"自测通过才发布"承诺的原理所在。