leader
Deconstructs a one-sentence idea into a self-contained goal/brief that an AI agent can execute independently. Use when the user says: 'Help me write a goal for an agent', 'Break down this goal in detail', 'Write a task brief/spec for the agent', 'Write a /goal prompt', 'Let the agent run this project autonomously', or 'Split this work across multiple agents in parallel'. Performs hands-on verification in the codebase and web research if necessary, then asks clarifying questions in a single round (≤5 questions). Produces an executable task brief (≤4000 characters) ready to paste directly into /goal, complete with verified metrics, whitelisted scopes, anti-cheating acceptance criteria, and checkpoint resumption. Automatically branches between execution-oriented and exploratory (research/tech stack evaluation/solution finding) workflows.
1How It Works & Mechanism
A three-role division is the backbone of this skill: the Leader (user) provides the idea and makes final calls, the Manager (current agent) investigates, drafts the brief, and handles acceptance, and the Executor (agent in goal mode) takes the brief and runs it independently to completion.
三个角色：**领导**（用户）出想法、拍板；**管理者**（你）调研、写书、验收；**执行者**（目标模式里干活的 agent）拿书独立跑完。
The writing premise is that 'the executor has no one to ask': the brief must serve as the single source of truth; any ambiguity will be executed literally, so fallback phrases like 'come ask me' are strictly forbidden.
执行者一字不差地执行、把书当唯一真理、中途没人可问——写错的事实 100% 被执行，全文不许有「来找我」。
The first step of the workflow is investigation rather than questioning: never ask what can be investigated independently. If a codebase exists, personally test whether commands actually exist and verify baseline metrics.
**1 调研。**自己能查的一律不问。有代码库就实测
Questions are asked only in the second round, capped at ≤5 questions per round, with each providing 2-4 options plus a recommendation; unverified domain knowledge must be explicitly labeled as 'Assumed, unverified'.
**2 提问，一轮 ≤5 个。**只问查不到且会改变任务书的：方向取舍、验收裁量、风险偏好、时间盒；每个给 2–4 个选项加推荐。
The task brief has a hard limit of ≤4000 characters (the input constraint of the /goal command); if it cannot fit, the scope is too large and must be split into multiple independent tasks.
**≤4000 字符，硬上限**（`/goal` 官方限制，超了粘不进去）。字符花在不查就会踩的坑上，不写执行者打开仓库一眼能看到的事实；砍调研过程、重复规矩、背景故事。压不进就是活太大——拆成独立几件，一次给一件。
Divergence between execution-oriented and exploratory workflows: goals with automatable acceptance commands use the full execution spec; tasks where the leader seeks answers directly (research, tech selection) use the exploratory spec to prevent superficial filler answers.
**先分型**：动笔前能写出验收命令的是**执行型**，全套照走。领导要答案本身（调研、选型、该不该做 X）的是**探索型**——硬指标只会收到凑数的答案，改四处见 anatomy.md。
Preventing the 'five failure modes' is the core countermeasure: cheating to pass (adding .skip/loosening assertions/mocking/deleting tests), hallucinated commands, context loss/amnesia, stubborn rabbit-holing, and silent failures—each with concrete remedies (baselines cannot regress, commands verified by hand, PROGRESS.md, pivot after 3 consecutive failures, negative validation).
**防它五种死法**： 1. **作弊达标**（最重要）：说「让测试绿」，最省力的是加 `.skip`、放松断言、mock 被测对象、删测试、`|| true`——不是它坏，是目标函数写错。对策：基线不可退（测试数／覆盖率 ≥ 基线、skipped 0）、点名禁止具体姿势、判卷标准冻结、暗卷自留。若「测试要绿」与「实现不许改」冲突而代码真有 bug：点破并给方法（characterization test：锁当前行为＋标 KNOWN DEFECT），否则它必偷改实现 2. **幻觉命令**：它会平静地编造命令再甩锅环境——书里每条命令你必须亲手跑过，摸不到就写进任务 0 让它查实 3. **失忆**：进度写 `PROGRESS.md`，接手会话先读它别重做；任务 0 过后先写 ≤10 行开工回执（理解的目标／顺序／最大风险）再动工；单任务一个会话内做得完 4. **一条道走到黑**：任务 0 兼前提核验，量出的数字对不上就停；同一验收连败 3 次换项；结果比基线差就回滚如实报告——「没做成但说清了」合格，「做了但更糟」不合格 5. **静默事故**：坏了不发信号的（假绿灯、失效报警器）配反向验证
Separate 'rules' from 'information': every strict prohibition must trace back to a verified test or a leader's decision; advisory recommendations are left to the executor's discretion and recorded in PROGRESS.md with rationale.
**法与情报分家**：「不许」是法，违反即不合格，每条溯源到一次实测或一次领导裁决；「建议」是情报，执行者有更好的路可以走、在 `PROGRESS.md` 记一句为什么。把情报写成法，是替执行者做它临场更懂的决定。
Parallel multi-agent splitting is done only with the leader's explicit approval; each brief must share the same 'Overview' (global objective, task boundaries, integration seams), with disjoint file scopes and uniquely assigned shared write targets.
## 多 agent 并行（领导点头才拆） 每份书带同一段「全局」（整体干什么、谁管哪段、接缝在哪——接缝没人接是头号事故）。
Delivery discipline: the final response contains strictly three parts (a one-line usage instruction + a clean, copyable task brief block + a one-line wrap-up), free of process noise; hidden test criteria (2-3 unexposed spot-checks) remain on the conversation side and are excluded from the brief.
**4 交付。**最终回复只有三样，过程噪音（调研表格、中途更正、分析过程）一概不带： - 一句用法：「在执行 agent 那边输 `/goal `，粘贴下面整段，发出去。」（`/goal` 是斜杠命令，没有单独输入框；没有目标模式的工具就直接粘贴发送。）附导读：领导只看三处——开头「这活为什么干」两行、「我替领导拍的板」、末尾「完成条件」的两条硬指标。 - 任务书代码块，整块可复制。 - 一句收尾：「跑完回来说一声，我来验收，给你 5 行内的人话报告。」 **一个目标、一次粘贴。**不许第二条 `/goal`、不许让领导存文件、不许发明开工命令。 **5 验收，是管理者的活。**明卷（验收命令）在书里，目标模式自己盯；暗卷——2–3 条执行者看不见的抽查——自留在会话侧 scratchpad，不进书。
2Core Capabilities
4Recommended Governance & Evidence
- SKILL.md: Pure prompt instructions and rule text; no script execution or external side effects.
5Second-Pass Verification
- [ok] 无脚本 / 无端点 / 无凭证 — 三文件 token 扫描全零命中（含 URL 与工具名）；目录仅 3 个 markdown。
- [ok] 无写盘指令 — SKILL.md 不要求本 agent 写文件；PROGRESS.md / BLOCKED.md 是任务书里要写给执行者的机制，暗卷是「自留在会话侧 scratchpad」。
- [ok] 「≤4000 字符」的出处与一致性 — SKILL.md 写「**≤4000 字符，硬上限**（`/goal` 官方限制，超了粘不进去）」；anatomy.md 写「整本 ≤4000 字符，单任务的书通常 1500–2000」；自检 1 再确认。三处一致。
- [ok] anatomy.md 与主文件的六节结构 — anatomy.md 开头「六节，顺序固定：「我替领导拍的板」放最前…「完成条件」放最后（两条硬指标收拢一切）」；主文件写书规则节的「任务书六节的结构规格与探索型改法见 references/anatomy.md」。
- [ok] 防作弊对策是否可执行 — 给出具体姿势黑名单（`.skip`、放松断言、mock 被测对象、删测试、`|| true`）与基线不可退（测试数/覆盖率 ≥ 基线、skipped 0）、判卷标准冻结、暗卷自留四项对策。
- [ok] 法/情报分家 — 原文「「不许」是法，违反即不合格，每条溯源到一次实测或一次领导裁决；「建议」是情报，执行者有更好的路可以走、在 `PROGRESS.md` 记一句为什么」。
- [ok] 提问上限与选项格式 — 「**2 提问，一轮 ≤5 个。**」+「每个给 2–4 个选项加推荐」+「要拆多份并行必须在这轮问」。
- [ok] 验收隔离（暗卷不进书） — 「暗卷——2–3 条执行者看不见的抽查——自留在会话侧 scratchpad，不进书」与自检第 5 条「暗卷自留没进书」互相印证。
6Verdict & Scenarios
0f1d60fb834f833f…