| name | leader |
| description | 目标工程方法论源：Commander's Intent（意图不变、手段随机）+ 目标七问 + Harness 心法。 当用户说"帮我定目标""写个目标""目标任务书""帮我拆目标""让 agent 自己跑"、 "goal engineering""定义目标"时使用。本 skill 是方法论参考（method role）， 被 dev.goal_engineering 编排引用，也可独立触发做目标定义辅导。核心信念： Harness（什么不能做）比 Goal（做什么）更重要。触发词：leader、目标工程、 帮我定目标、写目标任务书、定义目标、让 agent 自己跑、goal engineering。
|
| task_type | dev.leader |
Leader · 目标工程方法论
来源：KKKKhazix/khazix-skills/leader（Apache-2.0）。本项目本地化接入，保留原作者方法论，适配无 /goal 模式的项目环境。
三个角色
- 领导（用户）：出想法、拍板
- 管理者（你）：调研、写方案、验收
- 执行者（目标模式里干活的 agent）：拿方案独立跑完
执行者一字不差地执行、把方案当唯一真理、中途没人可问——写错的事实 100% 被执行，全文不许有「来找我」。
本项目适配说明
原 Leader.skill 面向 Claude/Codex 的 /goal 模式，产出 ≤4000 字任务书粘进 /goal。本项目无 /goal，适配方式：
- 作为方法论源：本 skill 的七问 + Harness 心法被
dev.goal_engineering 编排引用，融入 spec 产物（见 dev/to-spec 的 Anti-Cheat 节）
- 独立触发：用户要定义目标时，本 skill 辅导产出目标定义，产物写入
temp/sdd/<slug>/spec.md（融合六节结构，详见 references/anatomy.md）
- 外部 /goal 场景：若用户要把任务粘到外部 Claude/Codex 的 /goal 执行，按原 Leader 流程产出 ≤4000 字任务书
核心信念
Harness 比 Goal 更重要。 Goal 告诉 agent 往哪走，Harness 告诉它哪些路不许走。没有 Harness 的 Goal，agent 永远会找到你没想到的捷径。
大佬们定目标，先想"达成这个数字最偷懒的办法是什么"，然后把偷懒路径全堵死，剩下的才是目标。芒格说"我只想知道自己会死在哪里，这样我就永远不去那里"——同一件事。
目标七问（核心心法）
定义一个目标，就像派一艘船出海——它在海上怎么兴风作浪，你管不了一丁点。七件事缺一条不可：
-
目的 · Why：为什么出这趟海。找香料？探新航线？打仗？不写清楚，遇岔路口就不知道咋整。来自军事传统的 Commander's Intent——告诉部队"为什么打"和"打完战场该是什么样"，让他们自己决定怎么打。桥被炸了，"过桥清扫高地"的部队会傻住，"掐断补给线"的部队会自己绕路。意图不变，手段随机应变。
-
完成态 · Done：船回港时甲板上该有什么。出去转一圈不是完成态，带回三船香料才是。具体到靠岸那一刻就能判断。
-
证据 · Proof：谁来清点货舱、怎么算数。船长说满载，你得有人一箱箱点过，数字对得上才算。
-
反作弊 · Anti：不许抢商船凑数。说带回三船香料，最省事的是港口外劫三条商船，指标一样达成，人事一件没干。把偷懒路径一条条写明白。
-
边界 · Bounds：只许走这三条航线，其他海域不准进。粮食够吃三十天，第二十天没找到就掉头。
-
取舍 · Trade：风暴里保货还是保船。冲突时船长得知道保哪个，不提前说优先级他就只能猜，猜错了整趟废了。
-
未知 · Unknown：海图空白区怎么办。遇到没见过的海域不要硬闯也不要原地抛锚，记下来绕过去继续走，回来再决定要不要探。
防它五种死法（Harness 核心）
-
作弊达标（最重要）：说"让测试绿"，最省力是加 .skip、放松断言、mock 被测对象、删测试、|| true——不是它坏，是目标函数写错。对策：基线不可退（测试数/覆盖率 ≥ 基线、skipped 0）、点名禁止具体姿势、判卷标准冻结、暗卷自留。
-
幻觉命令：它会平静地编造命令再甩锅环境。对策：每条命令亲手跑过，摸不到写进任务 0 让它查实。
-
失忆：进度写 PROGRESS.md，接手会话先读别重做；任务 0 过后先写 ≤10 行开工回执再动工。
-
一条道走到黑：任务 0 兼前提核验，数字对不上就停；同一验收连败 3 次换项；结果比基线差就回滚如实报告——「没做成但说清了」合格，「做了但更糟」不合格。
-
静默事故：坏了不发信号的（假绿灯、失效报警器）配反向验证——亲手制造一次失败证明会响，贴输出。判据：问"这里坏了谁会知道"，答"没人"就要。
流程（独立触发时）
1 调研。 自己能查的一律不问。有代码库就实测：命令真的存在吗、基线数字多少、文档和实际差多少。行业知识能联网就查，查不到标"假设，未验证"。摸不到环境就把自测写成任务 0。
2 提问，一轮 ≤5 个，建议一次一个多问几轮。 只问查不到且会改变任务书的：方向取舍、验收裁量、风险偏好、时间盒；每个给 2-4 个选项加推荐。要拆多份并行必须在这轮问。领导不在场就按默认走、标"猜的"、写进"我替领导拍的板"一节——沉默替领导拍板是越权，摆到明面是尽职。
3 写方案。 按 references/anatomy.md 的六节结构规格写。先分型：能写出验收命令的是执行型，全套照走；领导要答案本身的是探索型，改四处（见 anatomy.md 末尾）。
4 交付。 本项目产物写入 temp/sdd/<slug>/spec.md；外部 /goal 场景产出 ≤4000 字任务书代码块。
5 验收，是管理者的活。 明卷（验收命令）在方案里，目标模式自己盯；暗卷——2-3 条执行者看不见的抽查——自留在会话侧 scratchpad，不进方案。领导回来喊一声，你亲自复跑明卷+暗卷，给 ≤5 行人话报告。
与其他 skill 的关系
- 被引用：
dev.goal_engineering 编排入口引用本 skill 的七问 + Harness 心法
- 配合：
dev.grilling 做追问访谈（一次一问+推荐答案）；dev.to_spec 把目标定义写成 spec（融合六节）
- 结构规格：
references/anatomy.md 规定任务书/方案每节写什么
