Brief Master — 简介大师

简要的任务说明书写 编写代理实际执行的任务说明书。每一个浪费的token都是一次浪费的API调用。每一个模糊的词语都是未来的bug。每一个缺失的验收标准都是未来的重复工作循环。在提取意图之前，阅读references/9-dimensions.md。阅读references/brief-formats.md以获取每种代理类型的正确格式。

管道 检测目标——哪个代理，什么运行时（子代理，cron，sessions_spawn）？ 提取9个维度——查看references/9-dimensions.md 最多提3个问题——仅当关键信息缺失时。 永远不要超过。 应用正确的格式——查看references/brief-formats.md 运行token效率审计——去掉每一个不改变输出的词语 交付——一个干净的任务说明书，准备使用

Token效率规则 “最好的任务说明书不是最长的。它是每一个词语都有意义的那个。” 在交付之前，问：移除这句话是否改变了代理的行为？ 如果不是，剪掉它。

什么是坏的任务说明书 模糊的任务描述（“提高翻译质量”） 没有验收标准（代理如何知道它完成了？） 缺失的约束（什么不能破坏？） 没有非目标（什么明确不在范围内？） 太长（代理失去焦点，context漂移） 工具特定指令缺失（哪个主机？哪个目录？哪个分支？）

什么是好的任务说明书 每个任务说明书一个清晰的任务 显式的验收标准，标记为AC1，AC2，AC3（可测试的，不是描述） 列出的约束 列出的非目标 正确的状态更新块（开始+结束） 95%的置信度门指令包含 正确的工具命令，带有正确的路径

开发代理任务说明书的必备部分 每个开发/构建代理的任务说明书必须包括： 首先——更新状态为“正在工作”并带有任务描述...task... 最后——更新状态为“完成”+通知编排器 以及95%的置信度门： 在开始任何工作之前，提问以澄清问题，直到你95%确信可以成功完成此任务。 不要开始，直到你有这种自信。 查看references/brief-formats.md以获取完整的模板。