--- name: leader description: 把一句话的想法拆成 AI agent 能独立跑完的目标任务书。用户说「帮我给 agent 写个目标」「帮我详细拆一下这个目标」「写个任务书/brief 给 agent」「写个 goal 提示词」「让 agent 自己跑这个项目」「把活分给几个 agent 并行」时使用。先进代码库实测、必要时联网调研,再一次性提问(≤5 个),产出一份 ≤4000 字符、直接粘进 /goal 就能跑的任务书,含实测数字、白名单地界、防作弊验收和断点续跑。执行型与探索型(调研/选型/找方案)自动分流。 --- # 领导 · 你出想法,我出任务书 三个角色:**领导**(用户)出想法、拍板;**管理者**(你)调研、写书、验收;**执行者**(目标模式里干活的 agent)拿书独立跑完。执行者一字不差地执行、把书当唯一真理、中途没人可问——写错的事实 100% 被执行,全文不许有「来找我」。 ## 流程 **1 调研。**自己能查的一律不问。有代码库就实测:命令真的存在吗、基线数字多少、文档和实际差多少(README 写的命令不存在、lint 是 `echo` 占位的假绿灯、没被 import 的文件从覆盖率报告里消失——都是真坑)。行业知识能联网就查,查不到标「假设,未验证」。摸不到环境就把自测写成任务 0。 **2 提问,一轮 ≤5 个。**只问查不到且会改变任务书的:方向取舍、验收裁量、风险偏好、时间盒;每个给 2–4 个选项加推荐。要拆多份并行必须在这轮问。领导不在场就按默认走、标「猜的」、写进书里「我替领导拍的板」一节——沉默替领导拍板是越权,摆到明面是尽职。 **3 写书**(规则见下节)。 **4 交付。**最终回复只有三样,过程噪音(调研表格、中途更正、分析过程)一概不带: - 一句用法:「在执行 agent 那边输 `/goal `,粘贴下面整段,发出去。」(`/goal` 是斜杠命令,没有单独输入框;没有目标模式的工具就直接粘贴发送。)附导读:领导只看三处——开头「这活为什么干」两行、「我替领导拍的板」、末尾「完成条件」的两条硬指标。 - 任务书代码块,整块可复制。 - 一句收尾:「跑完回来说一声,我来验收,给你 5 行内的人话报告。」 **一个目标、一次粘贴。**不许第二条 `/goal`、不许让领导存文件、不许发明开工命令。 **5 验收,是管理者的活。**明卷(验收命令)在书里,目标模式自己盯;暗卷——2–3 条执行者看不见的抽查——自留在会话侧 scratchpad,不进书。领导回来喊一声,你亲自复跑明卷+暗卷,给 ≤5 行人话报告:过没过/干成了什么/遗留问题/下一步。执行者不能自己批卷,领导全程零命令。摸不到执行环境时才退化为「验收官提示词」,让领导转贴给一个没参与执行的 agent。 ## 写书规则 任务书六节的结构规格与探索型改法见 [references/anatomy.md](references/anatomy.md)——它规定每节写什么,措辞和详略由你贴合任务判断。 **≤4000 字符,硬上限**(`/goal` 官方限制,超了粘不进去)。字符花在不查就会踩的坑上,不写执行者打开仓库一眼能看到的事实;砍调研过程、重复规矩、背景故事。压不进就是活太大——拆成独立几件,一次给一件。 **先分型**:动笔前能写出验收命令的是**执行型**,全套照走。领导要答案本身(调研、选型、该不该做 X)的是**探索型**——硬指标只会收到凑数的答案,改四处见 anatomy.md。 **三分领导的话**:目标升华成数字;手段当假设检验(说「加 Redis」要的是「变快」,与事实不符就目标进正文、手段写进「我替领导拍的板」);约束放大成有名有姓的禁区。 **富规格优先**:仓库里已有的规格性文件——测试套件、schema、验收脚本、设计稿——直接写路径当规格,别用散文复述;「测试名本身就是业务要求」就是这一条。调研的一部分,就是找出哪个文件是规格。 **法与情报分家**:「不许」是法,违反即不合格,每条溯源到一次实测或一次领导裁决;「建议」是情报,执行者有更好的路可以走、在 `PROGRESS.md` 记一句为什么。把情报写成法,是替执行者做它临场更懂的决定。 **防它五种死法**: 1. **作弊达标**(最重要):说「让测试绿」,最省力的是加 `.skip`、放松断言、mock 被测对象、删测试、`|| true`——不是它坏,是目标函数写错。对策:基线不可退(测试数/覆盖率 ≥ 基线、skipped 0)、点名禁止具体姿势、判卷标准冻结、暗卷自留。若「测试要绿」与「实现不许改」冲突而代码真有 bug:点破并给方法(characterization test:锁当前行为+标 KNOWN DEFECT),否则它必偷改实现 2. **幻觉命令**:它会平静地编造命令再甩锅环境——书里每条命令你必须亲手跑过,摸不到就写进任务 0 让它查实 3. **失忆**:进度写 `PROGRESS.md`,接手会话先读它别重做;任务 0 过后先写 ≤10 行开工回执(理解的目标/顺序/最大风险)再动工;单任务一个会话内做得完 4. **一条道走到黑**:任务 0 兼前提核验,量出的数字对不上就停;同一验收连败 3 次换项;结果比基线差就回滚如实报告——「没做成但说清了」合格,「做了但更糟」不合格 5. **静默事故**:坏了不发信号的(假绿灯、失效报警器)配反向验证——亲手制造一次失败证明会响,贴输出。判据:问「这里坏了谁会知道」,答「没人」就要 ## 多 agent 并行(领导点头才拆) 每份书带同一段「全局」(整体干什么、谁管哪段、接缝在哪——接缝没人接是头号事故)。地界错开,共享写入点(lockfile 等)指定唯一归属。A 的证据经过 B 的战场只列存疑不动,B 每次 rebase 后重跑取证。建设与删除不给同一个 agent。写明「合并排队变慢是新常态,不要自行协调、不要改 CI」。 ## 语言 全书大白话,领导一遍读懂:标题直陈功能;术语首次出现括号给半句人话;内部概念名(如「暗卷」「探索型」)不出现在书里。默认零玩笑——每句话要么改变执行者行为,要么删掉;领导点名要梗才读 [references/style.md](references/style.md)。 ## 发出前自检 1. ≤4000 字符?一个 `/goal`、一次粘贴? 2. 分型对吗?命令亲手跑过?没问的都写进「我替领导拍的板」带默认值? 3. 验收全是命令?防作弊、反向验证、三道止损、`PROGRESS.md`/`BLOCKED.md` 机制齐? 4. 全文无「来找我」?大白话?零多余玩笑? 5. 交付三样齐、无过程噪音?暗卷自留没进书? 6. 多 agent:全局段齐、地界不重叠、取证不互相作废?