用途：把模糊任务转成可验证、边界清晰的目标提示词，让 AI 编程代理能自行判断“是否完成”，无需追问人类。
主要能力与模式：提供两种调用模式。Standalone 模式：用户只给出模糊任务或直接要求生成 goal，逐题澄清任务。Compiled-handoff 模式：已有获批规划证据（对话、规格、issue、文档或其他技能）提供答案，不再重新访谈，只套用本技能的“可验证性”规则与目标框架格式；若关键产品决策或完成条件确实缺失，则报告来源尚不可代理执行并指出缺失证据。
使用方式：Standalone 模式下按顺序一次问一个问题：要做什么、在哪运行（项目/仓库/工作区、分支或文件区域）、DONE 是什么样、有哪些约束、目标代理或 harness。完成标准必须可观察、可机器检查，例如 tsc --noEmit 0 errors、eslint 0 warnings、断点下无溢出、npm test 全部通过、Lighthouse Performance ≥ 90 且 LCP < 2.5s 等。随后按目标 harness 格式草拟：Claude Code /goal 使用 Goal / Completion criteria / Constraints / Context 四段；Codex Automations 使用 Task / Frequency / Verification / Workspace；Pi 或通用格式使用“任务 / 完成标准 / 限制”。三种形状是快照而非标准，harness 有官方格式时以 harness 为准，未列出的走通用块。
验证与交付：输出前自检完成标准是否可无歧义判定、是否无需人类主观判断、约束是否足够具体、上下文是否足够；不通过则回到 Phase 1 澄清。Standalone 模式交付后附带一句提示，让用户把 goal 粘进对应代理；Compiled-handoff 模式由上游技能负责交付包装，不添加该结束语。
限制与注意事项：Standalone 模式绝不可跳过第 3 个问题；用户定义不了“done”时需帮其头脑风暴。Compiled-handoff 模式不得重新访谈。每个复选框只放一个可验证条件。约束用于防止代理改无关文件或引入破坏性变更。任务过大时建议拆成 2–3 个有清晰交接的小目标。研究/分析类（不改代码）目标的完成标准是“输出包含指定章节的报告”。文中仓库名、目录与路径均为占位符，实际 goal 必须写目标仓库的真实路径。