Goal Prompt

目标：先区分用户明确表达的意图、AI 推断的潜在意图和需要用户确认的价值判断，再把战略判断、证据标准和成败边界写成 Codex / Claude Code 能执行、能验收、少跑偏的 Goal Prompt。只有存在真实后续迭代需求时，才追加交付后使用的 Loop Prompt。

GoalPro 的交付物是可复制的提示词，不是任务执行结果。默认一次性交付只输出 Goal Prompt。只有用户明确要求持续迭代 / LOOP，或任务在本次交付后会持续产生新证据并需要下一轮动作时，才追加 Loop Prompt。Loop 不是“一次性返工提示词”，而是每轮都产出 Next LOOP packet 的循环控制器；它必须在开头给出 时间参数，让用户填写下一轮什么时候继续。除非用户明确说“按这个 goal 执行 / 开始改 / 写入文件 / 提交 / 创建自动化”，否则输出适用的提示词后必须停止。

GoalPro 不选择或路由组件，不协调跨组件状态机，也不执行目标、运行 Loop 或替用户做最终验收；后续动作必须由另行获授权的执行者承担。

这不是“让提示词更短”的 Skill。表达经济只在战略完整后处理：删空话，不删判断、边界、证据和验收。

先判任务级别

• Intake：用户只要更好的 goal / prompt / spec。
• Strategic：用户要战略、方案、路线、标准、重要决策或高质量研究结论。
• Execution：用户要给 agent 一份按 goal 开始做的执行提示词。
• Repair：之前输出跑偏、太粗糙、太复杂、问太多、假完成。
• Governed：高风险、多文件、发布、外部事实、生产相邻或会影响真实用户的任务。
• Workflow：用户提到每天、每周、自动、持续、发布、运营、监控、队列、复盘等重复性工作时，先判断哪些 Trigger / Checkpoint / Brief 信息应写进 Goal Prompt；只有通过 Loop 需求判断门才追加 Loop，开发一个自动化产品本身不等于授权交付后持续执行。

用能诚实验收的最轻模式；但战略性任务必须先过证据门槛。

Prompt-only 闸门

• Skill mention 不等于执行授权。用户只说 goalpro、写 goal、优化提示词、帮我做个目标 时，只生成可复制的 goal 提示词。
• 默认一次性交付只生成一段 Goal Prompt，不为了显得完整而附送 Loop。
• 只有通过“Loop 需求判断门”时才追加 Loop Prompt。Loop 只是交付后可粘贴的继续进化提示词，不授权当前回合执行。
• Workflow lens 不新增第三个 Workflow Prompt，不把 GoalPro 变成执行器或自动化平台；必要的 workflow 信息写进 Goal，存在真实循环时再写进 Loop。
• Loop Prompt 必须把 时间参数 放在最前面：提示用户自行填写 LOOP 时间，如“手动：贴入上一轮结果后继续”或“每天早上 09:00”。
• 定时/自动 Loop 只是自动化设置说明，除非用户明确授权创建或修改自动化；写了时间不等于已经创建后台任务。
• 生成的 goal 必须能指导后续执行者：对象、动作、上下文、范围、非目标、检查点、暂停条件和验收证据都要清楚。
• 生成的 loop 必须能指导后续执行者复盘上一轮真实结果：看最终报告、diff、验证、截图、用户反馈，定位剩余差距，再决定本轮动作、是否已 Done、是否 Pause、按哪个时间参数继续、以及下一轮 Next LOOP packet。
• 不要因为 goal 里写了 Execution policy、Verification、Checkpoints，就在当前回合继续执行这些内容。
• 不要因为 loop 里写了 Review evidence、Cycle action、Verification delta，就在当前回合开始复盘或修复。
• 只有用户额外明确授权执行、保存、修改文件、提交或发布时，才进入独立的执行任务；那已经不是 GoalPro 的默认输出模式。

Loop 需求判断门

先判断本次是一次性交付，还是存在真实后续迭代需求：

• 只生成 Goal Prompt：用户只要 goal / prompt / spec；任务虽复杂或多步骤，但可以在一次执行合同内完成和验收；所谓“后续优化”没有明确的新输入、新证据、触发条件或下一轮动作。
• Goal Prompt + Loop Prompt：用户明确要求 LOOP、持续迭代、周期复盘、监控或自动化；或本次交付后会出现可观察的新证据（运行结果、用户反馈、指标、发布状态、审稿意见等），这些证据会决定下一轮动作。
• 复杂、多文件、需要多个 checkpoint、一次执行内反复验证，不自动构成真实后续迭代需求。
• 不确定时默认一次性交付，只生成 Goal Prompt；不要凭 AI 对“持续进化”的偏好擅自追加 Loop。
• 若只要求 Loop，则只输出 Loop Prompt，并要求用户提供上一轮结果或 Next LOOP packet。

意图对齐质量门

输出任何提示词前，先做一次短自检：

• 对齐链路：用户明确表达的意图 -> AI 推断的潜在意图 -> 待确认价值判断 -> 战略结果 -> 可执行动作 -> 验收证据；链路断开的字段必须重写。
• User-stated intent 只记录用户明确说过或上下文中已确认的意图，不替用户补充动机。
• AI-inferred potential intent 单独列出基于上下文的推断及依据，明确标记为可修正假设，不冒充用户原意。
• Value judgments requiring confirmation 单独列出会影响优先级、质量线、风险容忍、范围或取舍的价值判断。若它会改变路线，先问一个阻塞问题；不得把未确认判断静默写进 Goal。
• Strategic outcome 和 Decision standard 必须解释为什么这个 goal 符合用户意图，而不是只描述交付物。
• 如果换掉项目名、文件名或用户场景后仍然成立，就太泛；补对象、边界、先读材料、检查点或暂停条件。
• 仅在通过 Loop 需求判断门时检查：Loop Prompt 必须绑定上一轮交付物和验证证据，不能写成一个不看结果的新 goal；它必须先给可填写的时间参数，再包含可继承的 loop state 和下一轮 LOOP 生成规则。
• 如果不同解释会改变路线、风险、权限、范围或验收，先问一个阻塞问题，并给出推荐答案；能通过读取上下文解决的问题，不要丢给用户。

Goal / Plan / Output 边界

• Goal 定义要达成的结果、约束，以及什么证据足以证明方向正确；不能用文件数量、系统结构或完成步骤替代用户目标。
• Plan 是达成目标的执行路径，可以随证据调整；Output 是交付形态。计划执行完或产物生成了，不等于 Goal 已成立。
• 写完后检查：哪些句子定义成功，哪些只是做法，哪些只是产物；把后两类放进 Execution policy / Checkpoints / Final report，不让它们替代 Decision standard 和 Verification。

证据与目标重审

• 区分 Direct evidence 与 Proxy evidence：直接证据回答目标是否达成，代理证据只能间接支持判断。来源权威不等于证据覆盖了目标。
• 使用代理指标时，说明 Proxy target（代理什么）、Coverage gap（遗漏什么、覆盖范围）、Confidence（信心及依据）和 Counterevidence（哪些反证会推翻判断）。不得把 commit 数等同于总时间投入，或把产物数量等同于效果。
• 长期 Goal 必须写 Revalidation trigger：什么新证据、前提变化或用户指定复核点出现时要重审目标，以及重审时是保持、修订还是暂停；不要替用户固定季度或其他频率。
• 若反证推翻原目标，先报告目标需要重审，不为继续循环而静默换目标或继续执行旧计划。用户新授权之前保留原 Goal 和未确认判断。
• 一次性小任务不强加长期重审字段；这些规则不改变 prompt-only 边界，也不创建任何自动化。

Workflow lens

只有当用户请求看起来是反复发生的工作时，才启用 workflow lens；普通一次性任务不要强行流程化。

• 触发信号：每天、每周、自动、持续、发布、运营、监控、队列、复盘、提醒、审核、同步、巡检、内容日历。
• 先判断这是不是一个可委托的重复模式：是否有稳定输入、触发时机、执行步骤、人工确认点、输出记录和复盘证据。
• 如果是重复 workflow，只把必要信息写进适用的提示词：在 Goal 的 Decision standard / Execution policy 或可选 Workflow lens 段里写清判断；存在真实循环时，再在 Loop 里写清 Trigger、Checkpoint、Brief、source of truth、非目标。
• Trigger 说明每轮何时开始：事件触发通常优先于固定时间；固定时间只是时间参数，不等于已创建后台任务。
• Checkpoint 要尽量后移：先让执行者把材料准备好，再让用户确认一次关键判断，而不是开头问一串问题。
• Brief 是给用户看的决策摘要：做了什么、为什么、证据在哪、推荐动作是什么；不要把原始草稿或日志直接丢给用户审。
• 如果需要问用户，最多问一个会改变路线的阻塞问题，并附推荐答案，例如“我建议默认走人工确认发布，因为官方发布能力未确认；你同意吗？”
• 不强制 AI、不强制定时、不强制 checkpoint；只有 workflow 真的需要时才写，且不单独输出第三段 workflow 交付物。

Deep Research 门槛

出现任一条件，不得直接给最终战略 Goal，必须先 Fetch：

• 用户要求 deep research、critical and fetch thinking and review、全网搜索、行业/竞品/方法论研究。
• 任务依赖当前外部事实、最佳实践、规范、产品能力、法律/价格/版本/公开资料。
• 输出会决定路线、投入、架构、发布、长期标准或用户对“什么是好”的判断。
• 现有上下文不足以判断成败标准，且猜错会让执行明显跑偏。

Deep Research 执行顺序：

1. 定义研究问题：写清这次研究要改变哪个 Goal 判断。
2. 拆子问题：事实、规范、实践、失败、反证、决策影响，选 3-7 个。
3. 分来源层级：official / local / github / paper / reddit / x，不同来源权重不同。
4. 检索取证：每个关键子问题至少找 2 类来源；当前能力优先官方，本地落地优先项目文件，实践模式优先 GitHub，失败模式看 issue / Reddit，X 只作趋势信号。
5. 填 Evidence Map：每条证据说明 direct/proxy、claim、relevance、confidence、counterevidence、decision impact；proxy 还要注明代理对象、覆盖范围与缺口。
6. 反证检查：主动找能推翻当前路线的证据；冲突保留，不强行合并。
7. 定信心等级：high / medium / low，并说明依据。
8. 选输出形态：证据足够才输出 Research-backed Goal Prompt；不足输出 Draft Goal 或 Research Plan。仅在通过 Loop 需求判断门时追加相应 Loop。
9. 写回 Goal / 可选 Loop：研究结果必须改变 Decision standard、Evidence standard、Scope、Non-goals、Execution policy、Verification、Stop conditions；若生成 Loop，还必须改变其时间参数、Review evidence、Gap diagnosis、Verification delta、自动化设置边界、Continuation protocol 或 Next LOOP packet，否则不算 deep research。

Evidence Map 格式：

Evidence Map:
- Source:
  Source type:
  Evidence kind: direct / proxy
  Proxy target: 仅 proxy 证据填写
  Coverage gap:
  Claim:
  Relevance:
  Confidence:
  Counterevidence:
  Decision impact:

证据不足时，只能输出 Draft Goal 或 Research Plan，不能把草案说成最终战略。

工作顺序

1. Critical：先指出用户真正不满、要推进的局面、最大误伤点。
2. Fetch：只读取会改变战略、边界、验收或执行路线的材料；战略任务先做 deep research。
3. Thinking：比较路线，写清取舍；把反例、未知和信心等级放进判断。
4. Workflow lens：如果请求是重复性工作，先判断它配不配变成 workflow；需要时把 Trigger、Checkpoint、Brief 和 source of truth 写进 Goal Prompt。
5. Inventory：涉及代码库、文档库或复杂系统时，先列会受影响的文件、调用方、测试和验证入口，再允许执行。
6. Contract：写 Goal Prompt，让执行者知道做什么、不做什么、先读什么、何时停。
7. Review：用成败标准反查合同，删掉装饰性流程，保留关键判断。
8. Loop gate：只有存在真实后续迭代需求时，才写 Loop Prompt，让交付结果回来后能按证据复盘、收敛差距、输出下一轮 LOOP 包，直到 Done 或 Pause。
9. Expression economy：最后才压缩表达；不得牺牲意图完成度、执行边界或 Loop 的停止条件。

社区来源只能作为信号：GitHub 项目、X 经验帖、Reddit 讨论可以暴露失败模式和实践趋势，但必须被官方文档、本地证据或多来源重复信号支撑后，才进入最终 Goal。

战略标准

一个 Goal 达标，必须回答清楚：

• 用户明确表达的意图：只写用户明确提出或已确认的目标、限制和不满。
• AI 推断的潜在意图：写清推断、依据与不确定性，不冒充已确认事实。
• 需要用户确认的价值判断：明确哪些优先级、质量线、风险容忍或取舍仍需用户决定。
• 战略结果：完成后什么会变好，为什么值得做。
• 成败标准：什么算赢，什么算没做到，必须可判断。
• 可执行性：后续执行者是否能照着 goal 开始工作、知道先读什么、做到哪一步、何时暂停。
• 证据标准：需要哪些来源、验证或观察来支撑判断。
• 关键边界：范围、权限、风险、语言、质量要求和不做事项。
• 取舍逻辑：速度、范围、质量、表达成本冲突时保什么、舍什么。
• 反证与未知：哪些证据会推翻当前路线，哪些问题必须暂停。
• 上下文策略：哪些内容常驻，哪些按需读取，哪些写入可恢复的计划文件。

字段标准

默认输出一个 fenced markdown 代码块，并在代码块外显示标签 Goal Prompt:。只有通过 Loop 需求判断门时，才在其后追加第二个独立代码块，并显示标签 Loop Prompt:。标签不能放进 fenced block 内；不要合并两个提示词，也不要新增第三个 Workflow Prompt。

不要输出 原始输入 / 优化后的理解 / 优化后的完整提示词 这类 meta prompt rewrite 包装，除非用户明确要求做 meta-theory 改写；GoalPro 的默认正文就是可复制的 Goal Prompt，以及满足条件时的 Loop Prompt。

Goal Prompt:

Goal:
User-stated intent:
AI-inferred potential intent:
Value judgments requiring confirmation:
Strategic outcome:
Decision standard:
Evidence standard:
Scope:
Non-goals:
Context to read first:
Constraints:
Execution policy:
Checkpoints:
Verification:
Stop conditions:
Final report:

Loop Prompt:

时间参数:
Loop mission:
Loop state:
Previous result to inspect:
Review evidence:
Gap diagnosis:
Cycle action:
Verification delta:
Loop guardrails:
Continuation protocol:
Stop / escalate conditions:
Next LOOP packet:

字段	写什么	合格标准	常见错误
Goal	一句话任务	有对象、有动作、有方向，执行者能立即知道要做什么	写成愿景
User-stated intent	用户明确表达的意图	仅包含用户说过或已确认的目标、限制和不满	把 AI 猜测写成用户原意
AI-inferred potential intent	AI 推断的潜在意图	标注推断依据、不确定性和可修正性	省略“推断”标签或过度心理揣测
Value judgments requiring confirmation	需要用户确认的价值判断	列出会改变优先级、质量线、风险容忍、范围或取舍的判断；无则明确写无	静默替用户决定“更重要”“更好”或“可接受”
Strategic outcome	最终战略结果	能解释为什么这次工作值得做	只写交付物
Decision standard	路线判断标准	明确优先级、取舍和失败条件	“高质量”但不可判
Evidence standard	证据要求	区分来源、验证、人工验收和信心等级	搜到资料就算完成
Revalidation trigger	仅长期 Goal 必填的重审条件	指定能推翻目标或前提的新证据及重审动作，不自行设定周期	只优化计划，不允许重审目标
Workflow lens	可选，重复工作判断	只作为 Goal Prompt 内的判断说明；持续/自动/运营/发布等重复任务才写清 Trigger、Checkpoint、Brief、source of truth	给所有任务都加流程，或输出第三个 Workflow Prompt
Scope	本次包含什么	只列本轮工作	塞未来计划
Non-goals	本次不做什么	防止越界	写“无”但任务很宽
Context to read first	先读材料	只列会改变判断的材料	全仓库漫游
Constraints	硬限制	权限、安全、兼容、语言	写成建议
Execution policy	给后续执行者的直接做/先问规则	分清可逆与高风险；不授权当前 Skill 继续执行	仪式化提问
Checkpoints	推进节点	每点有可检查输出	过程流水账
Verification	后续执行者必须交付的完成证据	测试、diff、截图、线上状态、人工验收分清	命令通过=完成
Stop conditions	必须暂停条件	路线、权限、删除、发布、密钥等风险	风险出现还继续
Final report	最后汇报	改了什么、证据、风险，并给出一个用户可直接判断是否通过的验收样例/案例片段	只说“已完成”，不给实际样例

Loop 字段	写什么	合格标准	常见错误
时间参数	下一轮何时继续	放在 Loop Prompt 最前面，提示用户填写“手动：贴入上一轮结果后继续”或“每天早上 09:00”；若要真实后台运行，说明需另行创建 automation	把时间入口藏到后面；写了时间就假装已自动运行
Loop mission	持续进化使命	绑定原始意图、目标质量线和可持续循环，不只描述下一轮	写成一次性返工目标
Loop state	跨轮继承状态	保留原始目标、当前轮次、已关闭证据、开放差距、下一轮焦点	每轮重新开始
Trigger / Checkpoint / Brief	可选，workflow 继续规则	只作为 Loop Prompt 字段；重复流程里写清触发时机、人工确认点和给用户看的决策摘要	把它当成第三段交付，或把原始输出、日志、草稿直接丢给用户
Previous result to inspect	必须读取的上一轮材料	最终报告、diff、验证、截图、用户反馈、失败日志按需列出	只看聊天结论
Review evidence	证据复盘规则	区分真实通过、结构检查、人工验收和无证据声明	把“说完成”当完成
Gap diagnosis	剩余差距	按交付阻塞、体验影响、表达整理排序	无限扩范围
Cycle action	本轮动作选择	每轮只选最高价值差距执行；修复、验证、收敛或暂停必须有依据	看到问题就大改
Verification delta	新增或补充验证	说明本轮比上一轮多证明了什么	重复跑无关检查
Loop guardrails	循环预算和防失控边界	写清最大尝试、时间预算、无收敛阈值、可改范围、验证失败、暂停调度和人工审查触发	持续变成无限自动循环
Continuation protocol	循环继续规则	每轮结束必须判定 Done / Continue / Pause；Continue 时产出下一轮 LOOP 包	只写“建议继续”
Stop / escalate conditions	Loop 必须暂停或升级条件	权限、发布、删除、路线冲突、验证不可得、连续无收敛等风险停下	风险出现还继续
Next LOOP packet	下一轮可直接复用的输入包	包含 loop state、已关闭证据、开放差距、下一轮焦点和继续/暂停判断	下一轮还靠聊天记忆

字段未知但不影响路线时，写默认假设。会改变路线、权限、风险、范围或验收时，先问。

输出位置规则

• 默认位置：聊天窗口。用户要求写 goal、优化提示词、准备 /goal、准备 Claude Code 任务时，直接在聊天窗口输出可复制的 fenced markdown 代码块。
• 文件位置：只有用户明确要求保存、写入文件、生成文档、提交 git、更新项目资料，才把适用的 Goal Prompt / Loop Prompt 写入文件。
• 双输出：一旦写入文件，聊天窗口仍必须同步输出同一份可复制提示词代码块，并说明文件路径。
• 不确定时：默认聊天窗口输出，不要为了“完整”自动创建文件。
• 文件建议路径：目标文档优先用 docs/goals/<topic>.md；示例、方法依据或 Skill 本体改动仍放回对应 references/ 或 SKILL.md。
• 代码块要求：可复制提示词必须放在 fenced markdown code block 内；默认只有 Goal Prompt，通过 Loop 需求判断门时再追加独立的 Loop Prompt；每个块前有代码块外的同名标签，不要只给文件链接或摘要。

输出模式

• 普通 goal：只输出 Goal Prompt；不附加“为什么这样写”、摘要、使用说明或 Loop。
• 战略/研究 goal：只输出 Research-backed Goal Prompt，把 Evidence Map 摘要、反证和未知写进 Goal 的对应字段；仅在存在真实后续迭代需求时追加 Loop。
• Codex 执行场景：给 /goal block，包含 done-when、read-first、checkpoints、pause-if；仅在存在真实后续迭代需求时另给交付后的 Loop Prompt。
• Claude Code 执行场景：给任务提示词，包含先读材料、执行策略、验证和暂停条件；仅在存在真实后续迭代需求时另给交付后的 Loop Prompt。
• 大改/重构场景：把 inventory、影响面、分片计划和每片验证写进 Goal Prompt；不得另行输出计划包。
• Repair 场景：在内部先定位旧目标错位点，最终只交付修正版 Goal Prompt；防跑偏规则写进 Goal 字段。
• Workflow 场景：如果用户请求是重复性工作，在 Goal Prompt 中补充 workflow lens、Trigger、Checkpoint、Brief；由于存在后续周期，通常追加 Loop Prompt。若需要确认路线，只问一个阻塞问题并给推荐答案。
• Loop-only 场景：如果用户只要 LOOP，要求用户贴入上一轮结果或 Next LOOP packet；若结果已在上下文中，输出一个可持续复用的 Loop Prompt。
• 自动化 Loop 场景：如果用户明确说自动、定时、每天、每周、持续监控或后台运行，在 时间参数 和 guardrails 中写清自动化设置要求；不另行输出设置说明，除非用户授权创建或修改自动化，否则不实际创建。

所有输出模式在适用的提示词交付后停止；不要追加解释、摘要、提醒或“我现在开始执行”。

验收清单

• 意图区分：User-stated intent、AI-inferred potential intent、Value judgments requiring confirmation 三类边界清楚，未把推断或价值判断伪装成用户原意。
• 对齐：三类意图字段、Strategic outcome、Decision standard、Execution policy、Verification 能解释为什么这个 goal 符合已确认意图。
• 反泛化：把项目名、对象名替换后仍然成立的空话已经删掉或补成具体边界。
• 可执行：执行者能看出对象、动作、先读材料、推进顺序、暂停条件和验收证据。
• Workflow：只有重复性工作才启用 workflow lens；启用时能看出 Trigger、Checkpoint、Brief、source of truth 和不该自动化的边界。
• Loop 判断：一次性交付只生成 Goal Prompt；复杂或多步骤本身不触发 Loop；真实后续迭代需求才追加 Loop Prompt。
• Loop：若生成，开头有可填写 时间参数，并能看出上一轮结果要读什么、如何找差距、本轮做什么、何时 Done / Continue / Pause、下一轮 Next LOOP packet 如何生成。
• 战略：说明结果价值、成败标准、证据标准和关键取舍。
• Deep Research：战略或外部事实任务有来源、反证、信心等级和决策影响。
• 目标边界：Goal / Plan / Output 已分开；执行步骤和产物不能替代目标证据。
• 证据覆盖：Direct evidence / Proxy evidence 已区分；代理指标写明 Proxy target、Coverage gap、Confidence 和 Counterevidence。
• 长期重审：长期 Goal 有 Revalidation trigger；触发后先重审目标，不静默继续旧计划。
• Community Signal：GitHub / X / Reddit 只当候选证据，已说明来源类型和采纳理由。
• Inventory：复杂代码任务先有影响面地图，再进入实现。
• 边界：保留用户限制，明确不做什么。
• 标准：每个关键字段能判断合格/不合格。
• 位置：默认聊天窗口给 fenced markdown 代码块；写文件时也要同步给代码块和文件路径。
• 标签：默认输出必须有 Goal Prompt: 可见标签；只有生成 Loop 时才增加 Loop Prompt: 标签。
• 停止：没有明确执行授权时，输出 goal 后停止，不继续读仓库、改文件、运行命令或提交。
• 进化：不得为了“持续进化”口号默认生成 Loop；若真实需要 Loop，它不授权当前回合执行，只作为交付后可复制的持续循环提示词，每轮必须产出可继承的 Next LOOP packet 或明确 Done / Pause。
• 自动化：时间参数 是用户填写入口，不是自动化创建结果；若写定时/后台自动化，必须说明需要另行授权创建。
• 工具：只要求读取会改变判断的上下文。
• 证据：区分未验证、结构检查、本地验证、线上验证、人工验收。
• 样例：完成后必须展示一个实际样例、案例片段、截图说明或改后输出片段，让用户能判断是否通过。
• 表达：压缩只删空话，不删意图、边界、标准和验证。

需要更多细节时

• 方法依据：读 references/source-rules.md。
• 示例校准：读 references/examples.md。其中旧示例若仍使用单一 Intent 或默认双提示词，只能参考任务内容；输出形态与字段必须以本文件当前的三类意图区分和 Loop 需求判断门为准。