Show HN：又一个标记语言工程工具包

Yamlet 是一个面向智能体辅助规格驱动开发（spec-driven development）的极简规范格式与工具链，目标是成为单一事实来源。整个设计围绕一个核心理念展开：每个 .yamlet.yaml 文件描述一个组件、一份契约、若干必需的需求，以及使用 EARS 格式编写的验收标准。作者认为，规格撰写应当“只写必需的最少内容，但传达尽可能多的含义”，从而减少智能体在需求理解上的偏差。

项目提供了一个自包含的 yamlet 命令行工具，支持 macOS 和 Linux（Intel 与 Apple Silicon/arm64），无需运行时。用户可以通过 Homebrew 安装，也可以从 GitHub Releases 下载 tarball 并校验 SHA256SUMS。此外，Yamlet 还可作为 Claude Code 插件安装，通过 /plugin marketplace add 和 /plugin install 两条命令即可启用。

工作流分为三个主要阶段：Author——由 yamlet-author 技能以访谈方式引导你完善规格，所有 YAML 和 ID 都由 CLI 负责写入，保证文件在构造上就是正确的；Verify——yamlet verify 根据机械规则目录检查规格是否合规；Project tests——yamlet tests 将每条验收标准转换为 Gherkin 格式的 .feature 文件，方便你编写步骤定义。整个流程刻意不构建“全自动流水线”，而是把规格定义这个环节做扎实，其余代码生成和实现仍由开发者掌控。

Yamlet 的设计动机来自作者对现有方案的不满：许多同类工具冗长且不可靠，容易让智能体对同一目标产生多种解读；而智能体会继承开发团队几十年来遇到的通病——需求不清、范围过大、目标漂移、急于交付、忽视代码质量指标。作者认为，与其依赖昂贵的专家或复杂的技能堆叠，不如用一个精简、可验证的规范格式来约束智能体。项目没有使用 MCP 服务器，也没有集成二十多个技能，而是将五个 Claude Code 技能打包在一个插件中。

在文件格式层面，Yamlet 规定了一组顶层键：system（slug 格式）、topic、summary、description、blast_radius（低/中/高）、front（internal/external）以及非空的 requirements 列表；exposes、components、connections 为可选项。exposes 声明组件的契约签名，包括名称、意图、命名输入和可选输出，验收标准通过 {input.NAME} 和 {output.NAME} 引用，校验器会双向检查所有引用是否可解析且所有声明是否被使用。

对于复合组件，components 列出成员文件，connections 以 sink: source 的方式描述数据流，例如 attachment: uploads.pdf_file。yamlet verify 会跨文件解析每个端点，确定数据流方向，并强制要求每个成员输入必须被连线；复合组件自身的 requirements 可选，仅用于表示连线无法表达的涌现性义务。项目提供了 pdf_archiver.yamlet.yaml 作为完整示例。

每条需求（RQ-N）包含描述和若干验收标准（AC-N）。每条验收标准由 pattern、required clause(s) 和 shall 列表组成。不同的 pattern 对应不同的必须子句：ubiquitous 总是开启；state 需要 while；event 需要 when；optional 需要 where；unwanted 需要 if；complex 需要 while 且必须是 when/if 之一。如果条款或 shall 文本中出现 {n} 占位符，则必须提供 examples 表，且每一行都要绑定全部占位符。

可视化方面，yamlet graph 可以输出规格结构图：默认生成 Graphviz DOT 格式，可通过 dot -Tsvg 渲染；--format=json 则输出稳定的 renderer-agnostic 图模型（yamlet.graph/v1），方便自定义渲染引擎。由于项目规格通常集中在一个目录，graph 命令会一次性展开整棵组合树。

插件包含五个技能：yamlet-author（访谈式撰写）、yamlet-contract-challenger（契约冻结前的对抗性审查）、yamlet-criteria-challenger（每条需求提交前的对抗性审查）、yamlet-verifier（规则校验）、yamlet-tester（重新生成 Gherkin 特性树）。前两个挑战者技能是单向流程中的关键关卡：契约在 init 后不可变，需求或标准一旦提交也不能修改，因此审查关卡是最后且最便宜的纠错机会。主流程从 /yamlet-author 开始，经过两个门禁，最终由 verifier 和 tester 收尾；每次写入都由 CLI 统一管理。Yamlet 以 MIT 许可证开源。