atelier-brief 是 atelier 框架分离式规划运行中的 brief-writer 子技能，定位为“撰写单个单元的简要说明（Sonnet，单元内部权限）”。
用途 在 atelier 分离运行中，导演（架构师）已经做出所有跨单元决策并固定在 CONTRACT.md 中。该技能的工作是把一条简洁的单元规格扩展为完整的 briefs/UNIT-NNN.md，使得 Haiku 执行器能运行到约 90% 而无需做进一步决策，同时让检查器可以客观验证。技能拥有单元内部的权限，但不触碰单元之间的接缝。
输入 运行时会被告知工作目录与单元 id。需要读取：
- <working-dir>/CONTRACT.md：跨单元表面，是事实来源，固定了共享接口、约定、术语、所有权与依赖图。读取与本单元相关的部分。
- <working-dir>/UNIT-SPECS.md（或导演写的单元规格）：找到本单元的简洁条目，包括目标、拥有的文件/输出、依赖、它定义的符号（名称）、它消费的内容、标准意图以及任何验证命令。
权限边界 该技能在单元内部扩展细节，但不重新决定跨单元事项：
- 不重新定义跨单元形状。若本单元消费合约或另一单元中定义的类型/接口，则引用它（“使用来自合约/UNIT-002 的 X”），而不重述或更改其签名。
- 不发明跨单元约定。错误形状、命名、格式、语气、依赖图、文件所有权均由合约固定，应予继承。
- 不改变范围或依赖。这些是导演的决策。若规格在跨单元层面看似有误，应在输出的备注中指出，而不是悄悄“修复”——这属于升级给导演，而非该技能的决定。 在上述限制内，该技能拥有完全权限：方法、单元内结构、本地决策以及确切的验收标准。
撰写简要说明（第一遍） 输出是给有能力的执行器（Haiku）的指令，而非文档。写作原则是让强 Haiku 正确执行该单元所需的最精简 brief。遵循 ../atelier/templates/BRIEF.template.md：目标 · 输入/上下文（确切文件 + 它消费的上游符号/章节）· 方法 · 约束 · 验收标准 · 依赖。
长度基准：brief Haiku 所需的长度不因撰写者而变。若强架构师直接写给 Haiku 会保持紧凑，本技能也应如此。若 brief 比一位敏锐工程师交给有能力的同事完成该单元的内容更长，就是在注水，应删减。目标是写得不超过该长度，越短越好。不要把规格“扩展”成更完整的文档，而要翻译成最小指令集。
方法详略的合理把握（默认简洁）：
- 模式化 / 常见工作（标准 CRUD、常见算法、惯用 UI、普通文案）：几行即可。指出要命中的接口/形状，让验收标准来引导。Haiku 了解该模式——不要叙述它能推断的步骤，不要重述合约中已有的细节。
- 微妙 / 不寻常 / 容易出错的工作：只写出承重步骤和具体陷阱。细节是 Haiku 可能出错处的保险——仅限该处。
该技能不是为弱本地模型做逐字节锁定。brief 的大部分价值在于验收标准 + 合约引用；方法只是简短提示，不是长篇论述。
风格：密集要点与速记，而非散文。电报式行文，不是句子——例如 Output: src/x.js · Uses loadRecords/report (contract seam) · (runnable) node --test test/x.test.js passes。无前言、无解释、无整段落。（实测：要点式 brief 与散文式效果相同，但字数约少 30%。）
底线由什么决定：删去散文后，brief 长度由其验收标准数量驱动（每条几乎不可约减：每条既是规格也是检查器评分依据），而非风格。因此缩短 brief 的方法是减少真正不同的标准数量——但绝不能把两条真实检查合并成一条含糊标准（那只会使其不可检查并把成本推给修复循环）。4–6 条标准的单元约为 120–150 词；12 条标准的单元约为 250 词。这是预期，不是膨胀。
编写具体的验收标准（检查器据此评分，而非凭感觉）。将每条标记为可运行（runnable，命令/测试）或断言式（assertional，可检查的陈述）。当单元产出代码时，优先使用可运行标准。
原样呈现合约的跨模块测试。若合约声明了针对进入本单元依赖边的必需跨模块测试（该测试将真实上游 API 组合进本单元自己的测试套件以捕获签名漂移），则将其原样复制到验收标准中，作为一条具名的可运行标准。不得跳过、重命名或削弱它——它属于合约，不属于该技能。
审计自己的草稿（第二遍） 重读草稿并修正：
- 删去 Haiku 不需要的每个词。删除对合约的重述（改为引用）、对有能力模型可推断步骤的叙述、含糊措辞、开场白以及任何为显得周全而写的内容。这是主要编辑——要无情。若某句不会改变 Haiku 的产出，就删掉。
- 修正任何含糊、不可验证或未标记的验收标准。
- 修正任何 Haiku 执行器可能合理误判的单元内歧义（保留这些——它们是承重部分）。
- 检查方法对真正微妙的工作是否过于单薄（罕见——通常问题相反）。 就地应用修正。审计后的版本即最终 brief——应比草稿更短，而非更长。
报告（最终消息——返回值） 报告字段：unit: <UNIT-ID>；brief: briefs/<UNIT-ID>.md (written)；approach_sizing: terse | detailed —— 一行说明理由；criteria: <n> total (<r> runnable, <a> assertional)；contract_refs: 引用而非重述的跨单元形状/约定；escalation: none | "<导演必须解决的规格/合约中的跨单元问题>"。 若将 escalation 设为非 none，则表示认为规格或合约在其管辖权之上存在错误——编排器会将其路由给导演（架构师）。不要通过发明本地修复来掩盖跨单元缺陷。
适用场景 适用于 atelier 分离式规划运行中的单元 brief 撰写阶段，特别是需要将简洁单元规格转化为可执行的、可客观验证的 brief 的软件开发规划场景。
限制 该技能仅拥有单元内部权限，不处理跨单元决策；不改变范围或依赖；不重新定义跨单元形状或发明跨单元约定；发现跨单元缺陷时应升级而非本地修复。