/goalpro

name: goalpro
description: 当用户要写出高质量 Goal Prompt，把模糊、战略性、多步骤、证据不足、持续/自动化或容易跑偏的请求整理成可执行、可验证、可暂停的目标契约时使用。适用于写 goal、优化任务提示词、明确 done/success criteria、deep research 后定战略、大改前 inventory、修复跑偏计划、识别可委托的重复 workflow、为 Codex 或 Claude Code 准备执行任务；默认一次性交付只生成 Goal Prompt，只有存在真实后续迭代需求时才追加 Loop Prompt，不执行 goal 或 loop，也不创建自动化。

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：