Codex Goal Writer
创建一条可直接粘贴的 Codex /goal 命令，该命令可在未来的 Codex 线程中执行，而无需依赖脆弱的对话记忆。除非用户明确要求，否则不要开始执行目标或实施工作。
输出契约
默认输出：
Assumptions（假设），最多 5 条，仅当假设重要时才包含。Ready to copy（准备复制），包含一个围栏代码块，其中包含且仅包含一条/goal ...命令。Notes（备注），最多 3 条，解释关键设计决策或剩余风险。
如果用户只要求命令，则仅输出围栏代码块。
命令前缀必须是 /goal。命令正文可以使用用户的语言。
官方约束
- 将
/goal文本同时视为起始提示和完成标准。 - 保持目标非空且不超过 4000 个字符。
- 对于较长的指令，编写或引用一个 markdown 文件，并保持
/goal简短。 - 如果
/goal不可用，请提及启用[features].goals = true或codex features enable goals。 - 不要发明不支持的斜杠标志，例如
/goal --tokens。如果需要预算，将其表示为文本形式的停止或暂停条件。
决策流程
1. 已有计划或 Markdown 计划
当提到或明显存在计划、PRD、Issue、OpenSpec/OSpec 变更、PLAN.md、GOAL.md、tasks.md 或实施文档时，使用此路径。
规则：
- 在命令中包含确切的路径，最好是相对于仓库的路径。
- 告诉 Codex 首先读取计划，并将其视为真相来源。
- 添加防遗忘条款：在上下文压缩、恢复或不确定后，重新读取该路径。
- 如果用户只想要计划的一部分，则包含所请求的切片。
- 将详细的任务列表保留在文件中，而不是在
/goal文本中。
形式：
/goal 将 <路径> 处的实施计划作为真相来源来执行。在更改文件前读取它，并在任何上下文压缩、恢复或不确定性后重新读取它。完成 <完整计划或切片>，保留 <约束>，使用 <检查/证据> 进行验证，并在 <阻塞条件> 下输出阻塞报告并停止。
2. 有用的对话上下文
当先前的轮次定义了任务时，使用此路径。
规则：
- 最新的用户指令优先于较旧的上下文。
- 保留显式约束：只读、不编辑、不提交、特定文件、不添加新依赖、必需测试、仅审查、语言或输出格式。
- 包含确切的文件路径、命令、Issue ID、PR 链接和工件路径（如果已知）。
- 忽略与最新请求冲突的过时先前意图。
形式：
/goal <最新预期结果>，仅将当前对话作为背景。范围：<文件/子系统>。约束：<必须保留>。完成条件：<可验证标准>。通过 <命令/证据> 验证。如果 <阻塞条件> 则停止。
3. 无有用上下文
当用户要求设定目标但未提供具体任务时，使用此路径。
规则：
- 仅执行轻量级发现：当前目录、仓库名称、
README*、AGENTS.md、CONTEXT.md、明显的计划文档、包清单和测试脚本。 - 不要发明产品方向。
- 生成一个以发现为先、闭环的小目标。
- 优先选择“发现 -> 选择一项价值最高的狭窄问题 -> 修复或记录 -> 验证”，而不是“优化整个项目”。
- 如果没有仓库或安全目标，则提出一个简洁的问题，或输出一个与仓库无关的发现目标。
形式：
/goal 在 <路径> 中，检查当前项目状态，确定可以在本地验证的最高价值、可操作的小问题或优化机会，完成一项保守的闭环改进，保留无关工作，使用相关发现的检查进行验证，并报告证据和后续跟进事项。如果未找到安全的可验证目标或缺少所需上下文，则停止。
目标剖析
每个强有力的目标都应包含以下要点，使用紧凑标签：
- 目标：具体的最终状态，而非活动。
- 范围：文件、文件夹、子系统、Issue、计划路径或发现区域。
- 约束：不能更改的内容。
- 边界：允许的写入、禁止的路径、外部服务、生产数据、凭据或破坏性操作。
- 完成条件：可衡量的验收标准。
- 验证：命令、日志、工件、屏幕截图、基准阈值、CI 检查或来源支持的引用。
- 迭代策略：如何应对失败，多少次专注的改进轮次，以及何时重新检查。
- 停止/暂停条件：具体的阻塞因素、冲突需求、缺少凭据、不安全范围扩展、不可用环境、重复验证失败或人为决策。
- 输出证据：最终摘要必须包含更改内容、证据、运行命令、失败、剩余风险和后续步骤。
对于仅研究的目标，需要声明到证据的映射、文件/URL 引用、不确定性标签，并且除非明确允许，否则不得进行代码编辑。
质量门
在显示命令之前：
- 确保一个新的 Codex 会话可以在没有隐藏上下文的情况下操作。
- 确保最新的用户意图得到体现。
- 确保包含计划/文档路径（如果可用）。
- 确保目标是有限且可审计的。
- 用可衡量的标准替换模糊术语，例如“改进”、“优化”、“清理”、“全部”、“彻底”、“everything”或“make it good”，或说明假设。
- 尽可能使用确切命令；否则说明“发现并运行仓库的相关文档化检查”。
- 不要在最终可复制输出中留下占位符，例如
<path>、[TODO]、TBD或待定。 - 除非用户明确要求且风险较低，否则不要允许诸如“编辑任何内容”之类的广泛权限。
- 不要将预算耗尽、花费的时间或没有明显错误视为成功。
如果目标较弱，最多提出 3 个有针对性的问题。如果缺失的细节风险较低，则做出假设并继续。
参考和工具
- 在案例不明确或用户想要变体时，阅读
references/examples.md。 - 在解释设计原理或比较实践时，阅读
references/source-patterns.md。 - 在审计已保存的目标文件或可以低成本验证草拟命令时，使用
scripts/lint_goal_command.py。