需要为 Claude Code / Codex 的…

当用户要创建、改写、压缩或清理 goal prompt / goal 条件 / /goal 命令时，生成一行、不超过 4000 字符、带可检查完成条件的目标。

适用场景

解决思路

1. 判断任务是否适合 goal：goal 适用于比单轮更大、且有可检查终点的工作；把多个小目标串联并在其间做 review，而不是写一个巨型 goal。
2. 起草时用 AND 连接各要素，绝不用 or（循环会走更省事的分支），并包含以下要素：
3. 1) 写最终状态而非活动：例如写 "all `legacyAuth()` call sites use `auth.verify()`"，而不是 "migrate the auth code"；活动可以被口头声称，最终状态只有真或假。
4. 2) 先读的范围：行动前要读的文件、issue、日志或计划。
5. 3) 明确的检查：确切的命令及其可观察结果（如 "`npm test` exits 0"），并要求运行它并展示输出；没有进入 transcript 的结果对评估器来说不存在。
6. 4) 不变量：哪些东西不能改（如 "without modifying vendor/"），并且始终包含 "do not weaken, skip, or edit the checks themselves"。
7. 5) 停止边界或受阻条款：如 "or stop after 20 turns"、"if blocked, stop and report the blocker"；没有它，写错的条件会永远循环，格式化脚本会在缺失时警告（Claude Code 在 session resume 时会重置 turn 计数器，所以 turn 边界会在 resume 后静默延长）。
8. 保持目标小：每条约束都会缩小模型可探索的状态空间；尽量收敛到一个可终止的判据，把范围和定义移到被引用的文件里，去掉非目标——只有能堵住真实逃逸路径的约束才值得保留。
9. 对长目标：还要写明最终证据（diff、report、artifact），并要求一个 progress log 文件，以便在 compaction 和 resume 之间保持持久状态；如果 brief 超过 4000 字符，把细节放进 `GOAL.md` 并在 objective 中引用该文件。
10. 绝不虚构缺失要素：每个要素都要基于用户请求、对话或仓库，去查而不是猜；如果某要素无法从可用信息中填出，仍然优化并格式化用户提供的内容，省略该要素并标记为缺失（见 Format）；用虚构的成功条件会让 goal 在错误的契约上终止。
11. 格式化前，以懒惰模型的视角重读草稿条件：让所有检查通过而不做预期工作的最省事方式是什么？堵住最省事的那些——优先把已有的检查配对，而不是新增约束，也不要把所有能想到的逃逸路径都列成非目标清单。
12. 常见逃逸路径：删除或 stub 而不是修复（"search prints nothing" 在调用方被删掉时也成立；把这类检查与一个证明功能仍可用的检查配对）；只通过子集（只跑一个测试文件、缩小搜索路径、从检查中排除目录）；钻 gate 的空子（skip/xfail 测试、硬编码期望输出、对测试输入特判、编辑检查本身——即不变量规则）；不运行就声称完成（transcript 中没有检查输出就宣布 done 或 blocked——即 show-the-output 规则）。
13. 无法从可用信息堵住的逃逸路径，放进 `Missing:` 列表作为警告；虚构或荒谬的约束比标记出的缺口更糟。
14. 安全研究类 goal：把审计目标收敛到一个可终止判据，例如识别、触发并验证一个在引用的 threat-model 文件下有效的高危漏洞；范围、攻击者能力、严重性基线和要跳过的已知发现都放在该文件里，而不是 goal 里；使用中性措辞（"trigger and validate"，而不是 "prove this is exploitable"），要求展示前置条件（假设攻击者已具备访问权限是最常见的误报），并在每个发现后停下来做人工 review，而不是堆积未分类的报告；用另一个全新 agent 做第二遍验证，绝不让发现者自己单独验证。
15. 格式化：对草稿（文件或 stdin）运行 `uv run --no-project {baseDir}/scripts/format_goal_prompt.py --fenced`；它会把空白折叠成一行、去掉 `/goal` 前缀、引号和围栏、在缺少停止条款时警告，并拒绝超过 4000 字符的输出——此时应缩短或把细节移到文件后重跑。
16. 只返回一个 fenced `text` 块，一行：```text\n/goal <single normalized objective>\n```；块周围不要加任何说明文字——除非 checklist 要素无法被 grounded：此时在块后跟一个 `Missing:` 列表，每行一个缺口，告诉用户需要补什么。
17. 示例：草稿 `/goal Migrate the auth module: - replace legacyAuth() with auth.verify() - make sure the tests still work` 重写并格式化为 ```text\n/goal All legacyAuth() call sites use auth.verify(): `rg "legacyAuth\(" -t ts` prints nothing AND `npm test` exits 0 (run both, show the output), without modifying vendor/ or weakening any test. If blocked, stop and report attempted paths and the blocker, or stop after 20 turns.\n```；这里 `npm test` 来自仓库的 package.json 而非猜测，把它与零匹配检查配对堵住了最省事的逃逸路径：删掉调用点而不是迁移。
18. 当没有任何信息能 grounded 某要素时，格式化已有内容并标记缺口：草稿 `make checkout faster` 且上下文中没有指标或 benchmark 时，输出 ```text\n/goal Make checkout faster\n``` 并附 Missing: 可度量的最终状态（哪个指标和阈值算 "faster"）、验证（证明 faster 的 benchmark 或命令）、停止边界（如 "or stop after 20 turns"）。

适用边界 · 注意事项

• 任务小于一轮即可完成、没有可检查终点时，不适合用 goal。
• 不要写一个巨型 goal 覆盖多个阶段；应串联小目标并在其间 review。
• 不要虚构缺失要素（如成功条件、验证命令、停止边界）；无法 grounded 时省略并标记为 Missing。