goal-prompt

Codex 和 Claude Code 的目标提示词

将任务转化为简洁、可验证、持久的 /goal。分两个阶段：

1. 调查上下文，建议选择快速模式或深度模式，并请用户确认目标和初始化计划；
2. 准备获批的 Markdown 文件，然后生成最终的 /goal。

此技能不会启动或执行目标。在深度模式下，确认后可以在 .goal-task/<task-slug>/ 下创建获批的 Markdown 文件。根据下方约定，已确认任务范围内的其他经用户授权的环境变更也预先获得授权；范围外的变更仍未经授权。

核心交互约定

不可妥协的路由门槛

每轮结束时，都将用户最新消息归类为以下三种状态之一：等待确认、已授权进入阶段 2，或明确要求执行非目标工作。如果处于等待确认状态，只输出阶段 1 简报和问题，然后停止。在授权状态改变之前，不要满足用户提出的“最终版”“可复制”或“就绪”目标请求。此门槛关乎授权，而非对调查结果的信心。

• 默认情况下，不要呈现用户首次描述中的最终提示词。
• 将对话视为三状态协议。在用户明确确认、明确跳过或明确委托剩余判断之前，始终处于阶段 1。阶段 1 的回复必须是一份确认摘要，且不得包含可复制的 /goal、围栏代码块中的最终提示词，也不得使用将其描述为可直接运行的措辞。“我已完成调查”或“请创建一个 /goal”本身不构成确认。
• 阶段 1 摘要发出后，停止并等待用户回复。不要从沉默、首轮要求继续，或现有证据已经充分这一事实中推断用户已确认。语义上的确认就足够，不必使用固定的状态词。
• 在输出中明确展示路由。以简短标签开头，例如 拟定的目标摘要，将尚未解决的问题放在末尾，并且首次回复中不得出现字面内容 /goal。唯一例外是用户明确要求跳过确认，或明确委托剩余判断。
• 如果用户明确委托剩余判断（例如要求 Agent 自行决定并继续），则在调查后将此视为进入阶段 2 的授权。在最终目标中保留未知的仓库事实，不得凭空捏造。如果用户明确跳过调查或确认，则该跳过即为授权，且最终目标必须如实说明由此产生的未知事项。
• 跳过确认不等于跳过调查。要求“直接生成”仍须查阅可用的仓库策略、源代码、测试和规范，除非用户也明确要求不要检查。
• 明确要求同时跳过调查和确认，即为获准进入阶段 2 的路径。在这种情况下立即呈现最终目标；将所有无法获取的信息保留为未知，不要输出摘要，也不要等待下一轮回复。“直接生成”但未跳过调查，仅表示跳过确认，因此应先检查可用上下文。
• 在要求用户确认结果、范围和完成证据之前，先调查可能影响结果的实际情况。
• 用户的明确要求可以跳过本技能的调查、提问、确认或模式选择默认流程。按要求执行，不要再次询问；将无法获取的信息明确标为未知，绝不捏造仓库细节。要求委托判断意味着先调查，再自行作出剩余决定并继续，无须让用户选择。
• 默认将用户有权授权且在已确认任务范围内所需的所有操作视为预先授权。这包括 Chrome 文件上传、输入 Agent 已可使用的凭据、文件和依赖项更改、工作区和 Git 操作、推送、PR 操作、测试派发以及评审回复。最终 /goal 必须明确说明这一点；不得仅因这类操作通常会弹出权限或授权提示而再次询问、等待、推迟或将工作标为 blocked。
• 阶段 1 期间，根据现有证据确定每项操作的目标。对于凭据，明确预期的环境或账户及其用途；对于远程变更，明确受影响的仓库、远程端、分支、PR 或其他目标。如果证据支持一个目标，就记录该目标，不要提问。如果仍有多个实质上不同的目标，且选择会改变结果或影响，则在阶段 2 继续等待，并询问用户要将哪个目标纳入范围，除非用户已委托该选择。这是在明确范围，不是再次请求授权。范围确定后，不得仅为授权该操作而再次询问。
• 绝不暴露、复述、持久化、截图记录、转录、提交或发布凭据值。仅记录已脱敏的操作及其成功或失败情况；截取的证据中不得出现密码字段或包含凭据的界面。
• 预先授权不意味着可以捏造密码、会话、工具或系统能力，也不得凌驾于更高优先级的主机指令或安全边界之上。实际能力不可用时，使用安全且可用的替代方案，并继续所有独立的工作路径，同时保持未满足的关卡处于未解决状态。已确认范围之外的操作仍未获授权。
• 只询问答案会实质改变目标的问题。不要过早打断用户，询问可以通过证据、安全且可逆的假设或后续执行解决的问题。
• 建议使用快速或深度模式，但由用户确认。用户已经选择模式时，不要再次询问。
• 一次性准备工作应放在初始化阶段，而不是持久有效的 /goal 中。将未完成的准备事项直接写入 state.md；完成后删除相关步骤，只保留仍有意义的结果。
• 不要创建 goal.md；目标已保存在 /goal 中。
• 不要仅因普通故障、权限缺失、资源限制或可能出现的问题，就将整个目标标记为 blocked。
• 对于前端或 UI 工作，应用 references/ui-acceptance.md；最终目标必须要求使用 Chrome browser_use（或可用的等效浏览器工具），并提供实际功能以及 UI/UX 证据。

阶段 1：调查并确认

1. 确认所需产物

只有当用户明确要求生成、改写、缩短或审核 /goal 提示词文本时才继续。不要把普通任务转变为依托目标的工作，也不要在此技能中执行该目标。

改写、缩短或审核草稿时，应分别检查其是否定义了可观察的完成后状态，以及其证据是否涵盖完整范围。仅描述活动的措辞（如“改进”“润色”“优化”或“重构”）无法验证。如果任务还包括行为、兼容性、迁移、文档、部署或审核要求，那么仅测试成功并不能证明任务已完成。

2. 调查实际情况

阅读所有可能影响目标的用户提供的路径、URL、规范、约束和先前决策。若有本地仓库可用，请检查最近的 AGENTS.md、贡献指南、当前工作区、相关源代码和测试、构建脚本、CI，以及现有问题、TODO、规范或设计文档。通过实时来源核实远程信息和时效性信息。

尽可能依据证据确定：

• 用户真正想要的结果；
• 当前状态与期望状态之间的差距；
• 范围、重要的排除项和不变量；
• 证明任务完成的验证器或可观察证据；
• 尚未解决的决策、风险和外部依赖；
• 任务是否必须跨阶段、会话或配额恢复；
• 现有事实文件是否仍然有效；
• 当前 Agent 的写入、命令、网络、子 Agent、Git 和连接器权限是否可能阻碍后续执行。

只预检此任务可能需要的实际能力，不要预检上述默认规则已授予的用户授权。若存在高风险能力缺口，应说明具体缺失的能力、受影响的阶段以及可安全采用的替代方案。不要再次请求许可，也不要自动将任务标记为 blocked。

不要臆造命令、路径、依赖项、指标或约束，也不要机械地读取每个文件。当进一步调查不太可能改变任务简述、模式建议或重要问题时，就停止调查。

3. 建议执行模式

a. 快速／小型任务模式

适用于范围明确、风险较低、依据充分，且通常可在一个连续执行周期内完成的工作。

• 开展有针对性且有时间限制的研究，不做无关的细粒度盘点。
• 默认不创建旁置文件。
• 仅在确实需要保持恢复连续性时创建 state.md。
• 不要预先创建 todo.md、design.md 或 lessons.md；只有在出现具体失败、可复用经验或用户提出要求时才添加。
• 将适用的精简执行规则直接写入 /goal。

b. 深度／长任务模式

用于跨越多个阶段或子系统的工作，包含大量交付物、反复实施与验证、远程等待或跨会话恢复。

• 对当前修订版本、现有文档、执行环境和重大风险，完成一次充分的基线调查。
• 用户确认初始化后，创建非空的 state.md；仅在需要时创建 todo.md、design.md 或其他获准文件。
• 将完整执行约定写入 state.md；最终 /goal 仅保留结果、范围、关卡、事实入口和必要的停止语义。

每轮有效工作后简要总结所得，但只有在存在有证据支持、可复用的内容时，才创建或更新 lessons.md。

复杂度并不意味着要创建更多文件。不要将深度模式视为必须包含四个文件的固定组合。

谨慎决定模式。当任务跨越多个子系统、包含多个实施与验证阶段、需要跨会话或配额恢复，或涉及公开兼容性或迁移边界时，建议使用深度模式。仅当工作确实范围明确、风险低，且能通过一次紧凑的验证周期完成时，才建议使用快速模式。沿用已确认的深度模式决定；不要因为最终 /goal 应该简短就降级模式。

即使在小型代码库中，持久性和恢复语义也是深度模式的判断信号：若工作范围包含检查点／恢复、幂等性、重放、回滚或部分故障后的恢复，则实施和跨层证据均需采用深度模式。

4. 选择场景指南

从重构、功能、批处理、研究、审计、把关审查或自定义场景中，选择最匹配的一项。只阅读 references/scenarios.md 中对应的章节。并行工作还需阅读 references/parallel-agents.md；前端或 UI 工作还需阅读 references/ui-acceptance.md。

对于深度模式、长时间运行的工作或持久恢复类工作，还需阅读 references/long-goal-execution.md。仅当选择了学习记录时，才阅读 references/long-goal-learning.md。

5. 设计最小初始化文件集

优先使用现有规范、设计文档、问题和任务文件。新文件必须有明确的用途、读者和生命周期；绝不创建空占位文件。

.goal-task/<task-slug>/ 下只有以下四个文件可供选择：

文件	职责	创建条件
state.md	当前状态、阶段、有效事实索引、门禁证据、工作摘要、未完成的初始化工作和下一步行动	深度模式下始终创建；快速模式下仅在需要跨轮次恢复时创建
todo.md	大型或频繁变动的可执行工作项	TODO 细节会挤占 state.md 空间，或需要独立分批维护
design.md	已确认且持久的设计决策、接口和不变量	存在重要设计决策，且没有更权威的现有设计文档
lessons.md	有证据支持、可复用的经验及待提升的候选项	深度模式下仅在确有经验时创建；快速模式下仅在用户提出请求或发生具体故障后创建

不要创建职责重叠的 progress.md、blockers.md、decisions.md 或 goal.md。大型证据报告或正式规范可以使用任务要求的产物路径，但它不是默认的初始化文件。

明确区分职责：

• state.md 保存当前执行情况的事实，并链接到其他文件。不要重复记录 /goal 门禁、完整设计、冗长的 TODO 或经验内容。若有 todo.md，这里只保留项目数、依赖摘要和链接。未完成的一次性工作可以列在“Initialization TODO”下；完成后删除其步骤，仅保留仍有意义的环境结果或约束。
• todo.md 回答“还剩什么？”。存在该文件时，项目级状态以及等待／延期标记仅记录在此处。
• design.md 回答“做了什么决定，为什么？”。它不跟踪每日工作。
• lessons.md 保存经过验证、可复用的经验，而非事件时间线。

首先遵循宿主 Agent 的指令优先级。在任务材料中，按以下顺序使用：

latest user confirmation > authoritative spec/design > issue/todo > state

state.md 是活动索引和执行记录；它不能覆盖权威的产品事实或设计事实。只有在范围、代码仓库基线、关键设计或环境发生实质变化时，才增量更新初始化内容。

6. 提交确认简报

除非用户明确跳过确认或委托剩余判断，否则阶段 1 应返回确认简报，而不是 /goal。请包含：

• 拟议成果；
• 范围和排除项；
• 完成证据；
• 建议模式及理由；
• 可复用的现有文件和要创建的新文件；
• 初始化操作、能力缺口、已确定的操作目标及其影响；
• 仅列出会实质改变目标的未解决问题。

对于复杂的长期工作，还应概述可恢复的等待事项、等待期间可继续的独立工作、检查点或恢复操作，以及仅当所有剩余工作都共同受阻时才适用的停止条件。 对于需要恢复或持久化检查点的深度工作，应说明某个事项等待时可继续或重新排序的独立工作；不要将其简化为笼统的重试说明。 当权威需求／设计文档规定了明确的接口或不变量时，应在简报和完成证据中保留每项重要约束；不要把键、顺序、检查点时机或兼容性规则概括成笼统的“保持行为不变”。深度行为或迁移工作还必须明确规定评审人数和所需的重新评审关卡。 恢复／停止小节必须明确说明：等待中、已延期或标记为 needs input 的事项应重新排到后面，不会阻止独立工作；只有当所有剩余事项都具有相同阻碍因素时，整体状态才是 blocked。

确认深度模式及其初始化计划，即授权创建所列的 .goal-task/<task-slug>/ Markdown 文件。范围内的工作树或分支变更、依赖安装、配置变更、破坏性操作和远程变更均已预先授权。执行前，须在已确认的范围中记录破坏性操作和远程变更的确切目标及影响；这是安全边界和证据要求，不是再次请求授权。范围外的变更仍未获授权。

对于研究或审计目标，确认简报应保持只读，并区分证据缺口与用户偏好缺口。对于仅生成报告的目标，不要机械地添加行为变更评审、实现关卡或代码重新评审。适当情况下，报告仍可指定一名独立证据评审者。

对于把关评审，阶段 1 简报必须明确列出发现项的结构：每项发现都包含严重性、准确位置、观察到的证据和建议。即使无法访问目标仓库或修订版本，完成证据也必须保留这些字段；不要将其概括成笼统的“问题”。

当仓库策略或贡献者文件属于可用上下文时，应在简报中指出确切文件，并解释任何用户要求的覆盖操作。只使用这些文件、包脚本或当前源代码中已观察到的命令；不要仅因某些命令很常见就添加通用命令。确认了包脚本后，应在完成证据中保留其确切命令字符串；不要将其替换为笼统的“所有脚本均通过”。

如果用户的回复实质性地改变了目标或初始化计划，则应更新简报并再次确认，除非该回复同时明确授权了新范围、跳过确认或委托剩余判断。否则，继续进入阶段 2。

阶段 2：初始化并呈现

7. 准备已批准的文件

快速模式默认跳过此步骤。在已确认的深度模式下：

1. 创建 .goal-task/<task-slug>/；
2. 仅执行列出的、适用范围内的一次性环境设置；这些设置已根据核心契约预先授权； 不要开始实施目标范围内的工作；
3. 创建或更新 state.md，写入基线、当前真实信息索引、执行契约和下一步行动；
4. 仅当触发条件满足时，才创建非空的 todo.md、design.md 或 lessons.md；
5. 验证最终 /goal 会引用的每个路径；
6. 替换或归档过时的草稿，并将其从当前真实信息中移除。

初始化文件和已授权的环境准备是为了后续执行目标；它们不会启动目标。不要在 /goal 中重复已完成的一次性操作。将未完成的操作列在 state.md 的“Initialization TODO”下，并在完成后尽快简化或移除。

8. 编写执行契约

将 references/long-goal-execution.md 作为深度、长期运行或需要持久恢复的工作的唯一详细契约。在起草深度简报或最终目标前，先阅读该文件。它负责状态初始化、检查点、能力预检、批处理、等待、重试／延期、进度、独立审查、提交、配额恢复和经验总结。不要将该契约复制到 SKILL.md 或在 /goal 中重复；深度目标应指向 state.md，并仅保留其结果、范围、关卡和共同停止语义。

对于快速模式，只在 /goal 中写入适用的精简规则：每项最多重试三次，记录并延期失败项，不得豁免关卡；继续独立工作；在有成效的工作循环后报告基于关卡的进度；对低风险且范围明确的行为变更，安排一位独立审查者进行只读审查；如果目标会产生持久的仓库变更，则仅在验证和审查后提交，默认不要推送。只读研究、审计和关卡把关工作不得创建空提交。用户可授权的范围内操作已经获批，不得因此再次提问、等待、延期或将整体状态标记为 blocked；如果某项能力确实不可用，则保留其关卡并继续独立工作。只有在同一情况连续三个目标轮次再次出现，且所有剩余工作都因此无法继续时，才可将原生状态标记为 blocked。

渲染最终提示时，核心路由关卡、场景指南和详细的长期工作参考仍具有权威性。切勿仅为缩短提示而弱化必需的关卡。

9. 编写最终的 /goal

可执行目标必须说明：

• 具体、可观察的结果；
• 范围及重要排除项；
• 真实的二元或量化证据；
• 需要同时满足的完成门槛；
• 适用的持久化、进度、审查和提交规则；
• 仅在影响所有剩余工作时才有效的停止条件。
• 一条明确的行内预授权约束，说明范围内可由用户授权的操作已经获批，不得因此再次提问、等待、延期或进入 blocked 状态。绝不可仅将这条必需的句子放在 state.md 中。

快速模式将适用规则压缩到 /goal 中。深度模式在 /goal 中引用 state.md 里的完整执行约定，而不重复初始化细节、完整待办事项、冗长规格或审查清单。

在 Stage 1 获得确认、用户明确跳过确认，或用户委托剩余判断后，返回最终的 /goal。委托决策仍属于 Stage 2 授权；不得因某个仓库路径或偏好不可用就要求停止。如果无需该信息即可编写所请求的目标，就保留这一未知项，并将其解决设为执行门槛；仅当缺失信息会改变目标或导致无法安全地制定目标时，才询问用户。只完成已获授权的初始化，并首先验证每个引用的路径。明确跳过调查时，省略未经验证的路径和命令，保留重要未知项，并将其解决作为执行的一部分，而不是把猜测当作事实。

长度约定

• 快速模式的 /goal 尽可能控制在约 450 个词元。即使超过目标，也要保留结果、范围、门槛和必需的执行语义。
• 深度模式的 /goal 应简洁。接近 700 个词元时，应引用 state.md 中的完整约定，而不是重复其中内容。
• 词元目标仅供风格参考；实际仍受使用方运行框架的硬性字符限制约束。除非已知运行框架支持更长内容，否则生成的 /goal 不得超过 4000 个字符。通过将细节移入 state.md 执行约定来精简，绝不可削弱或删去门槛。
• 不要仅为缩短提示而创建文件；每个事实文件都必须有不同的职责。

最终的 /goal 仅包含：

• 已确认的结果；
• 最少的有效事实路径；
• 简洁的范围和排除项；
• 核心持久化和优先级调整语义；
• 所有必须同时满足的完成门槛；
• 确实会影响所有剩余工作的特殊停止条件；
• 仅当用户提出要求时才包含词元预算。

输出模板

Stage 1：确认概要

Proposed goal brief
- Outcome: <observable after-state>.
- Scope: <included area>; excludes <material exclusions>.
- Completion evidence: <validators or observable proof>.
- Recommended mode: <fast/deep>; rationale: <task properties>.
- Active truth: <existing paths to reuse>.
- Proposed initialization: <no files, or each file and its purpose>.
- Capabilities and targets: <resolved credential/remote targets; any actual
  capability gap, affected phase, and adjustment>.
- Recovery and stop: <checkpoints, bounded retries, and independent work during
  waits; stop only when all remaining work is jointly blocked>.
- Open assumptions: <only material uncertainties>.

Questions:
<only necessary questions that materially change the goal>.

Please confirm or correct the goal brief, execution mode, and initialization
plan. I will prepare the files and generate the final prompt only after
confirmation.

Stage 2：最终 /goal

/goal <concise confirmed and verifiable outcome>.

[Fast mode active truth, only when needed:
- <minimum path and responsibility>]

[Deep mode active truth (required):
- `.goal-task/<task-slug>/state.md` — sole execution contract and recovery
  entrypoint]

Scope: <included area and material exclusions>.

Constraints:
- Treat all user-authorizable actions required inside the confirmed scope as
  pre-authorized, including Chrome uploads, entry of available credentials,
  local/environment/Git changes, pushes, PR actions, tests, and review
  responses. Do not ask again or stop, wait, defer, or mark work `blocked`
  because of an authorization prompt. This does not fabricate credentials or
  capabilities, override higher-priority safety boundaries, or authorize work
  outside scope. Never expose or persist credential values in evidence, logs,
  state, commits, or PRs. Use safe alternatives and continue independent work
  when a capability is genuinely unavailable.
- [Fast mode only: after three failed attempts by default, defer one item and
  continue independent work; after each productive loop report gate-based
  progress, this-loop/remaining work, and one primary next action; use one
  independent reviewer for focused low-risk behavior changes; when persistent
  repository changes exist, commit only after validation and review, and do not
  push by default; read-only work creates no empty commit.]
- [Deep mode only: use the contract in `state.md` for initialization,
  checkpoints, retries, progress, independent review, commits, and learning;
  keep this prompt to its active-truth entrypoint and completion gates.]

Complete only when all applicable conditions are true:
1. <observable outcome or artifact>.
2. <required validators and evidence>.
3. <remaining confirmed gates>.
4. [Behavior change: required independent review and re-review are complete with
   no unresolved high-severity finding.]

Set the overall goal `blocked` only when every meaningful remaining item, after
recovery, reprioritization, and completion of independent work, still jointly
depends on <confirmed logical conflict, safety boundary, or mandatory external
dependency>.

[Only when requested: Use a budget of <N> tokens.]

最终回复

Stage 1 期间，只返回目标概要、重要问题和明确的确认请求；不要要求固定的状态字符串，也不要包含 /goal 代码块。用户明确跳过确认或委托剩余判断时，不采用此回复格式。

Stage 2 期间，返回：

1. 一个包含可直接复制粘贴的 /goal 的 Markdown 代码块；
2. 一段简短说明，仅涉及模式、初始化文件和有依据的权衡。

不要开始执行目标。