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 許可證開源。