goal-prompt

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Goal Prompt for Codex and Claude Code

面向Codex和Claude Code的/goal提示词创建指南

Turn a task into a concise, verifiable, persistent

/goal

. Use two stages:

investigate context, recommend fast or deep mode, and ask the user to confirm the goal and initialization plan;
prepare the approved Markdown files, then render the final
```
/goal
```
.

This skill does not start or execute the goal. In deep mode, after confirmation, it may create approved Markdown files under

.goal-task/<task-slug>/

; other environment changes still require explicit authorization.

将任务转换为简洁、可验证、持久的

/goal

。分为两个阶段执行：

调研上下文，推荐快速模式或深度模式，并请求用户确认目标和初始化方案；
准备经批准的Markdown文件，然后生成最终的
```
/goal
```
。

本技能不会启动或执行目标。在深度模式下，获得确认后，可能会在

.goal-task/<task-slug>/

目录下创建经批准的Markdown文件；其他环境变更仍需明确授权。

Core interaction contract

核心交互约定

By default, do not render the final prompt from the user's first description.
Investigate real context that can affect the result before asking the user to confirm the outcome, scope, and completion evidence.
An explicit user request may skip this skill's investigation, questions, confirmation, or mode-selection defaults. Follow that request without asking again, keep unavailable facts visibly unknown, and never invent repository details. A request to delegate judgment means investigate first, then make the remaining decision and continue without asking the user to choose.
User control over this workflow does not override higher-priority host instructions, safety boundaries, or permissions. If they conflict, explain the exact constraint and request only the decision needed for a feasible goal.
Ask only questions whose answers materially change the goal. Do not interrupt early for questions that evidence, a safe reversible assumption, or later execution can resolve.
Recommend fast or deep mode, but let the user confirm it. Do not ask again when the user already selected a mode.
Keep one-time preparation in initialization, not in the enduring
```
/goal
```
. Put unfinished preparation directly in
```
state.md
```
; after completion, remove the steps and retain only results that still matter.
Do not create
```
goal.md
```
; the objective already lives in
```
/goal
```
.
Do not mark the whole goal
```
blocked
```
because of an ordinary failure, missing permission, resource limit, or possible question.

默认情况下，不要根据用户的首次描述直接生成最终提示词。
在请求用户确认结果、范围和完成证据之前，先调研可能影响结果的真实上下文。
用户的明确请求可跳过本技能的调研、提问、确认或模式选择默认流程。遵循该请求无需再次询问，保留可见的未知信息，切勿虚构仓库细节。请求委托判断意味着先调研，然后做出剩余决策并继续执行，无需用户选择。
用户对工作流的控制权不能覆盖更高优先级的宿主指令、安全边界或权限。若存在冲突，需解释确切限制，并仅请求可行目标所需的决策。
仅提出会实质性改变目标的问题。对于可通过证据、安全可逆假设或后续执行解决的问题，不要提前打断流程。
推荐快速或深度模式，但需用户确认。若用户已选择模式，无需再次询问。
将一次性准备工作放在初始化阶段，而非持久化的
```
/goal
```
中。未完成的准备工作直接放入
```
state.md
```
；完成后，移除步骤，仅保留仍有价值的结果。
不要创建
```
goal.md
```
；目标已存在于
```
/goal
```
中。
不要因普通失败、权限缺失、资源限制或潜在问题将整个目标标记为
```
blocked
```
。

Stage 1: investigate and confirm

阶段1：调研与确认

1. Confirm the requested artifact

1. 确认请求的产物

Continue only when the user explicitly wants

/goal

prompt text generated, rewritten, shortened, or reviewed. Do not turn an ordinary task into goal-backed work or execute the goal inside this skill.

When rewriting, shortening, or reviewing a draft, separately check whether it defines an observable after-state and whether its evidence covers the full scope. Activity-only language such as "improve", "polish", "optimize", or "refactor" is not verifiable. Test success alone does not prove completion when the task also includes behavior, compatibility, migration, documentation, deployment, or review requirements.

仅当用户明确希望生成、重写、缩短或审核

/goal

提示词文本时，才继续执行。不要将普通任务转换为基于目标的工作，也不要在本技能内执行目标。

在重写、缩短或审核草稿时，需分别检查其是否定义了可观察的最终状态，以及其证据是否覆盖全部范围。仅描述活动的语言（如“改进”“优化”“重构”）不具备可验证性。当任务还包含行为、兼容性、迁移、文档、部署或评审要求时，仅测试成功无法证明任务完成。

2. Investigate the real context

2. 调研真实上下文

Read all user-provided paths, URLs, specs, constraints, and prior decisions that can affect the goal. When a local repository is available, inspect the nearest

AGENTS.md

, contributor guidance, current worktree, relevant source and tests, build scripts, CI, and existing issues, TODOs, specs, or design documents. Verify remote and time-sensitive information from live sources.

Use evidence where possible to determine:

the result the user actually wants;
the gap between current and desired state;
scope, material exclusions, and invariants;
validators or observable evidence that prove completion;
unresolved decisions, risks, and external dependencies;
whether the task must resume across phases, sessions, or quotas;
whether existing truth files remain current;
whether the current agent's write, command, network, subagent, Git, and connector permissions could obstruct later execution.

Preflight only capabilities this task may need. When a high-risk gap exists, state the exact missing capability, affected phase, and suggested adjustment. Do not expand permissions or mark the task

blocked

automatically.

Do not invent commands, paths, dependencies, metrics, or constraints, and do not read every file mechanically. Stop when more investigation is unlikely to change the brief, mode recommendation, or material questions.

阅读所有用户提供的可能影响目标的路径、URL、规范、约束和先前决策。当本地仓库可用时，检查最近的

AGENTS.md

、贡献者指南、当前工作树、相关源码和测试、构建脚本、CI以及现有问题、TODO、规范或设计文档。从实时源验证远程和时间敏感信息。

尽可能利用证据确定：

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

仅预检查任务可能需要的能力。当存在高风险缺口时，说明确切缺失的能力、受影响的阶段及建议调整方案。不要自动扩展权限或标记任务为

blocked

。

切勿虚构命令、路径、依赖、指标或约束，也不要机械地读取每个文件。当进一步调研不太可能改变简介、模式推荐或关键问题时，停止调研。

3. Recommend an execution mode

3. 推荐执行模式

a. Fast / small-task mode

a. 快速/小任务模式

Use for focused, lower-risk, well-grounded work that normally fits one continuous execution cycle.

Perform targeted, time-bounded research without unrelated fine-grained inventory.
Create no sidecar by default.
Create
```
state.md
```
only when recovery continuity is genuinely needed.
Do not pre-create
```
todo.md
```
,
```
design.md
```
, or
```
lessons.md
```
; add one only after a concrete failure, reusable lesson, or user request triggers it.
Put the applicable compact execution rules directly in
```
/goal
```
.

适用于聚焦、低风险、基础扎实的工作，通常可在一个连续执行周期内完成。

执行有针对性、限时的研究，不进行无关的细粒度盘点。
默认不创建辅助文件。
仅当确实需要跨轮次恢复时，才创建
```
state.md
```
。
不要预先创建
```
todo.md
```
、
```
design.md
```
或
```
lessons.md
```
；仅在出现具体失败、可复用经验或用户请求时添加。
将适用的紧凑执行规则直接放入
```
/goal
```
。

b. Deep / long-task mode

b. 深度/长任务模式

Use for work spanning phases or subsystems, with many deliverables, repeated implementation and validation, remote waits, or cross-session recovery.

Complete one sufficient baseline investigation of the current revision, existing documents, execution environment, and material risks.
After the user confirms initialization, create a non-empty
```
state.md
```
and create
```
todo.md
```
,
```
design.md
```
, or other approved files only when needed.
Put the full execution contract in
```
state.md
```
; keep only the outcome, scope, gates, truth entrypoint, and essential stop semantics in the final
```
/goal
```
.
Summarize learning briefly after each productive loop, but create or update
```
lessons.md
```
only when evidence-backed reusable content exists.

Complexity does not imply more files. Do not treat deep mode as a mandatory four-file bundle.

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

完成对当前版本、现有文档、执行环境和重大风险的充分基线调研。
用户确认初始化后，创建非空的
```
state.md
```
，仅在需要时创建
```
todo.md
```
、
```
design.md
```
或其他经批准的文件。
将完整执行契约放入
```
state.md
```
；仅将结果、范围、关卡、事实入口点和核心停止语义保留在最终的
```
/goal
```
中。
每个有效循环后简要总结学习内容，但仅当存在有证据支持的可复用内容时，才创建或更新
```
lessons.md
```
。

复杂度不意味着需要更多文件。不要将深度模式视为强制的四文件捆绑包。

4. Select scenario guidance

4. 选择场景指南

Choose the best match from refactor, feature, batch, research, audit, gatekeeper review, or custom. Read only that section in

references/scenarios.md

For complex long-running work, also read

references/long-goal-execution.md

. Read

references/long-goal-learning.md

only when a learning record is selected.

从重构、功能开发、批量任务、研究、审计、把关评审或自定义场景中选择最匹配的类型。仅阅读

references/scenarios.md

中对应的章节。

对于复杂的长期工作，还需阅读

references/long-goal-execution.md

。仅当选择学习记录时，才阅读

references/long-goal-learning.md

。

5. Design the minimum initialization set

5. 设计最小初始化集合

Prefer current specs, designs, issues, and task files. A new file must have a distinct purpose, reader, and lifecycle; never create an empty placeholder.

Only these four files are candidates under

.goal-task/<task-slug>/

File	Responsibility	Creation condition
`state.md`	Live status, phase, active-truth index, gate evidence, work summary, unfinished initialization, and next action	Always in deep mode; in fast mode only for cross-turn recovery
`todo.md`	Large or frequently changing executable work items	TODO detail would crowd `state.md` or needs independent batch maintenance
`design.md`	Confirmed, durable design decisions, interfaces, and invariants	Material design decisions exist and no more authoritative design already exists
`lessons.md`	Evidence-backed reusable lessons and promotion candidates	In deep mode only when real lessons exist; in fast mode only after a user request or concrete failure

Do not create overlapping

progress.md

blockers.md

decisions.md

, or

goal.md

. A large evidence report or formal spec may use the task's required artifact path, but it is not a default initialization file.

Keep responsibilities separate:

```
state.md
```
holds current execution truth and links elsewhere. Do not duplicate
```
/goal
```
gates, full design, long TODOs, or lesson text. With
```
todo.md
```
, keep only item counts, dependency summary, and the link. Unfinished one-time work may appear under "Initialization TODO"; remove its steps after completion and retain only environment results or constraints that still matter.
```
todo.md
```
answers "what remains?" When present, item-level state and waiting/deferred markers live only here.
```
design.md
```
answers "what was decided and why?" It does not track daily work.
```
lessons.md
```
holds validated, reusable lessons, not chronology.

First follow the host agent's instruction priority. Within task materials, use:

text

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

state.md

is an active index and execution record; it cannot override authoritative product or design truth. Refresh initialization incrementally only when scope, repository baseline, key design, or environment materially changes.

优先使用当前规范、设计、问题和任务文件。新文件必须具有明确的用途、读者和生命周期；切勿创建空占位符。

.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的指令优先级。在任务材料内，使用以下优先级：

text

最新用户确认 > 权威规范/设计 > 问题/TODO > state.md

state.md

是活动索引和执行记录；不能覆盖权威产品或设计事实。仅当范围、仓库基线、关键设计或环境发生实质性变化时，才增量刷新初始化内容。

6. Present the confirmation brief

6. 呈现确认简介

Unless the user explicitly skips confirmation or delegates the remaining judgment, Stage 1 returns a confirmation brief, not

/goal

. Include:

proposed outcome;
scope and exclusions;
completion evidence;
recommended mode and rationale;
existing files to reuse and new files to create;
initialization actions, permission risks, and their effects;
only unresolved questions that materially change the goal.

For complex long-running work, also summarize recoverable waits, independent work that can continue while waiting, checkpoint or recovery actions, and stop conditions valid only when all remaining work is jointly blocked.

Confirming deep mode and its initialization plan authorizes creation of the listed

.goal-task/<task-slug>/

Markdown files. Worktree or branch changes, dependency installation, configuration changes, destructive actions, and remote mutations require the exact target and impact to be listed and explicitly authorized. Do not ask again when the same confirmation already covers them.

If the user's response materially changes the goal or initialization plan, update the brief and confirm again unless that response also explicitly authorizes the new scope, skips confirmation, or delegates the remaining judgment. Otherwise proceed to Stage 2.

除非用户明确跳过确认或委托剩余判断，阶段1仅返回确认简介，而非

/goal

。简介需包含：

提议的结果；
范围和排除项；
完成证据；
推荐模式及理由；
可复用的现有文件及需创建的新文件；
初始化操作、权限风险及其影响；
仅会实质性改变目标的未解决问题。

对于复杂的长期工作，还需总结可恢复的等待、等待期间可继续的独立工作、检查点或恢复操作，以及仅当所有剩余工作共同受阻时有效的停止条件。

确认深度模式及其初始化方案即授权创建列出的

.goal-task/<task-slug>/

下的Markdown文件。工作树或分支变更、依赖安装、配置变更、破坏性操作和远程变更需列出确切目标和影响并获得明确授权。若同一确认已覆盖这些操作，无需再次询问。

若用户的响应实质性改变了目标或初始化方案，需更新简介并再次确认，除非该响应也明确授权新范围、跳过确认或委托剩余判断。否则进入阶段2。

Stage 2: initialize and render

阶段2：初始化与生成

7. Prepare approved files

7. 准备经批准的文件

Fast mode skips this step by default. In confirmed deep mode:

create
```
.goal-task/<task-slug>/
```
;
perform only the listed, explicitly authorized one-time environment setup; do not begin implementation within the goal's scope;
create or refresh
```
state.md
```
with the baseline, active-truth index, execution contract, and next action;
create non-empty
```
todo.md
```
,
```
design.md
```
, or
```
lessons.md
```
only when its trigger is satisfied;
verify every path that the final
```
/goal
```
will reference;
replace or archive stale drafts and remove them from active truth.

Initialization files and authorized environment preparation serve later goal execution; they do not start the goal. Do not repeat completed one-time actions in

/goal

. Put unfinished actions under

state.md

's "Initialization TODO" and simplify or remove them promptly after completion.

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

创建
```
.goal-task/<task-slug>/
```
目录；
仅执行列出的、明确授权的一次性环境设置；不要开始目标范围内的实现工作；
创建或刷新
```
state.md
```
，包含基线、活动事实索引、执行契约和下一步操作；
仅当触发条件满足时，创建非空的
```
todo.md
```
、
```
design.md
```
或
```
lessons.md
```
；
验证最终
```
/goal
```
将引用的所有路径；
替换或归档过时草稿，并从活动事实中移除。

初始化文件和授权的环境准备服务于后续目标执行；不会启动目标。不要在

/goal

中重复已完成的一次性操作。将未完成的操作放在

state.md

的“Initialization TODO”下，完成后及时简化或移除。

8. Write the execution contract

8. 编写执行契约

Persistent execution and retry

持久化执行与重试

Unless the user specifies otherwise, try one item at most three times. If it still fails, record evidence, defer it, and continue all independent work.
Diagnose and repair recoverable failures, narrow the next action, or use an authorized alternative.
Under resource pressure, first reduce concurrency or batch size, change validation cadence, or adjust resource use; defer the item only if needed.
Deferral is not a waiver. An unmet gate remains active, so progress cannot be reported as
```
100%
```
.
Mark ordinary permission or authorization gaps
```
needs input
```
and continue independent work; do not mark the entire goal
```
blocked
```
.

Set the overall goal

blocked

only when the user explicitly defines that rule, or when bounded recovery, authorized alternatives, task splitting, reprioritization, and all independent work are exhausted and every meaningful remaining item still depends on the same logical conflict, safety boundary, or verified mandatory external dependency.

除非用户另有指定，每个项目最多尝试三次。若仍失败，记录证据、延迟该项目并继续所有独立工作。
诊断并修复可恢复的故障，缩小下一步操作范围，或使用授权的替代方案。
资源紧张时，首先降低并发量或批量大小、更改验证频率或调整资源使用；仅在必要时延迟项目。
延迟并不代表放弃。未满足的关卡仍处于激活状态，因此进度不能报告为
```
100%
```
。
将普通权限或授权缺口标记为
```
needs input
```
并继续独立工作；不要将整个目标标记为
```
blocked
```
。

仅当用户明确定义该规则，或在穷尽有限恢复、授权替代方案、任务拆分、优先级调整及所有独立工作后，所有有意义的剩余项目仍依赖同一逻辑冲突、安全边界或已验证的强制外部依赖时，才将整体目标标记为

blocked

。

Loop progress

循环进度

After every productive execution loop, and when a major milestone review or commit spans its own loop, report:

text

Progress [██████░░░░] 60% (3/5 gates)
This loop: <completed work and key evidence>; Remaining: <main open work>.
Next: <one primary action>.

Calculate percentage from scoped milestones, deliverables, and completion gates, not elapsed time or effort. Use a coarse evidence-based value labeled

estimate

when the denominator is unstable. Never report

100%

before all applicable gates pass. Do not report tool calls, waits, or no-change loops separately. Combine review and commit when they occur in the same loop.

每个有效执行循环后，以及当重大里程碑评审或提交跨越自身循环时，报告：

text

进度 [██████░░░░] 60% (3/5 关卡)
本轮：<已完成工作及关键证据>；剩余：<主要未完成工作>。
下一步：<一项主要操作>。

根据范围内的里程碑、交付物和完成关卡计算百分比，而非耗时或工作量。当分母不稳定时，使用带有

estimate

标签的粗略证据值。所有适用关卡通过前，切勿报告

100%

。不要单独报告工具调用、等待或无变更循环。若评审和提交在同一循环中发生，合并报告。

Independent review

独立评审

For a focused, low-risk behavior change in fast mode, use 1 independent read-only reviewer by default.
For deep-mode or major behavior changes, use exactly 3 independent read-only reviewers at the final major milestone; apply the same rule to intermediate major milestones in deep work.
For a large change, all 3 first scan global risk, then focus respectively on correctness/tests, design/boundaries, and security/maintainability.
Pure documentation, read-only research, or analysis uses 1 independent reviewer by default; the user may increase the count.
A reviewer may be a subagent, isolated session, or equivalent independent review tool. The implementation worker cannot substitute for one.
Run at most 3 fix/re-review rounds by default. If review still fails, record and defer affected work, continue independent work, and do not claim the gate.
If required reviewers are unavailable, raise an early high-risk warning, finish review-independent work, and remain
```
needs input
```
; do not self-review or mark the whole goal
```
blocked
```
automatically.

对于快速模式下聚焦、低风险的行为变更，默认使用1名独立只读评审者。
对于深度模式或重大行为变更，在最终重大里程碑时使用恰好3名独立只读评审者；深度工作中的中间重大里程碑也适用同一规则。
对于大型变更，3名评审者首先扫描全局风险，然后分别关注正确性/测试、设计/边界和安全性/可维护性。
纯文档、只读研究或分析默认使用1名独立评审者；用户可增加数量。
评审者可以是子Agent、隔离会话或等效的独立评审工具。实现人员不能替代评审者。
默认最多运行3轮修复/重评审。若评审仍未通过，记录并延迟受影响的工作，继续独立工作，不要声称关卡已通过。
若所需评审者不可用，提前发出高风险警告，完成与评审无关的工作，保持
```
needs input
```
状态；不要自行评审或自动将整个目标标记为
```
blocked
```
。

Milestone commits

里程碑提交

When a major milestone produces persistent repository changes, create a local commit promptly after applicable validation and review pass. Do not create empty commits for read-only research, analysis, audits, or gatekeeper reviews.
Fix high-severity findings, test failures, and unmet gates before committing by default.
If current changes are a required baseline for later work, an intermediate checkpoint commit may record the risks and unmet gates. It does not mean review passed or complete those gates.
Do not push by default. Pushes, PRs, releases, and deployments require explicit authorization.

当重大里程碑产生持久化仓库变更时，在适用验证和评审通过后及时创建本地提交。不要为只读研究、分析、审计或把关评审创建空提交。
默认情况下，提交前修复高严重性问题、测试失败和未满足的关卡。
若当前变更是后续工作所需的基线，中间检查点提交可记录风险和未满足的关卡。这不代表评审通过或完成这些关卡。
默认不推送。推送、PR、发布和部署需明确授权。

Learning

学习

At the end of each productive deep-mode loop, briefly summarize disproven assumptions, effective recovery, and potentially reusable rules. Write to

lessons.md

only when the content is evidence-backed and reusable.

Learning may propose candidates for repository rules, global rules, or Memory, but cannot promote them automatically. Changing AGENTS instructions or Memory requires separate explicit authorization.

每个深度模式有效循环结束时，简要总结被推翻的假设、有效的恢复方法和潜在可复用规则。仅当内容有证据支持且可复用时，才写入

lessons.md

。

学习内容可提议仓库规则、全局规则或Memory的候选内容，但不能自动推广。更改AGENTS指令或Memory需单独明确授权。

9. Render the final

/goal

9. 生成最终的

/goal

An executable goal must state:

a concrete observable outcome;
scope and material exclusions;
honest binary or quantitative evidence;
conjunctive completion gates;
applicable persistence, progress, review, and commit rules;
stop conditions valid only when they affect all remaining work.

Fast mode compresses applicable rules into

/goal

. Deep mode references the full execution contract in

state.md

instead of repeating initialization detail, complete TODOs, long specs, or review checklists.

Return the final

/goal

after Stage 1 is confirmed, the user explicitly skips confirmation, or the user delegates the remaining judgment. Complete only authorized initialization and verify every referenced path first. When investigation was explicitly skipped, omit unverifiable paths and commands, preserve material unknowns, and make their resolution part of execution rather than presenting guesses as facts.

可执行的目标必须包含：

可观察的明确结果；
范围和实质性排除项；
真实的二元或定量证据；
联合完成关卡；
适用的持久化、进度、评审和提交规则；
仅当影响所有剩余工作时有效的停止条件。

快速模式将适用规则压缩到

/goal

中。深度模式则引用

state.md

中的完整执行契约，而非重复初始化细节、完整TODO、长规范或评审清单。

阶段1确认后、用户明确跳过确认或委托剩余判断后，返回最终的

/goal

。先完成授权的初始化并验证所有引用路径。若明确跳过调研，省略不可验证的路径和命令，保留实质性未知信息，并将其解决作为执行的一部分，而非将猜测作为事实呈现。

Length contract

长度约定

Keep fast-mode
```
/goal
```
near 450 tokens when possible. Preserve outcome, scope, gates, and required execution semantics even when that exceeds the target.
Keep deep-mode
```
/goal
```
concise. Near 700 tokens, reference the full contract in
```
state.md
```
instead of repeating it.
Do not create files merely to shorten the prompt; every truth file needs a distinct responsibility.

The final

/goal

contains only:

the confirmed outcome;
minimum active-truth paths;
concise scope and exclusions;
core persistence and reprioritization semantics;
all conjunctive completion gates;
exceptional stop conditions that genuinely affect all remaining work;
a token budget only when the user requested it.

尽可能将快速模式的
```
/goal
```
控制在450 tokens左右。即使超出目标，也要保留结果、范围、关卡和必要的执行语义。
深度模式的
```
/goal
```
需简洁。接近700 tokens时，引用
```
state.md
```
中的完整契约而非重复内容。
不要仅为缩短提示词而创建文件；每个事实文件需有明确的职责。

最终的

/goal

仅包含：

已确认的结果；
最少的活动事实路径；
简洁的范围和排除项；
核心持久化和重优先级语义；
所有联合完成关卡；
真正影响所有剩余工作的特殊停止条件；
仅当用户请求时添加的token预算。

Output templates

输出模板

Stage 1: confirmation brief

阶段1：确认简介

text

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>.
- Permission risks: <none, or exact capability, 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 `/goal` only after
confirmation.

text

提议的目标简介
- 结果：<可观察的最终状态>。
- 范围：<包含区域>；排除<实质性排除项>。
- 完成证据：<验证器或可观察证明>。
- 推荐模式：<快速/深度>；理由：<任务属性>。
- 活动事实：<可复用的现有路径>。
- 提议的初始化：<无文件，或每个文件及其用途>。
- 权限风险：<无，或确切能力、受影响阶段及调整方案>。
- 恢复与停止：<检查点、有限重试及等待期间的独立工作；仅当所有剩余工作共同受阻时停止>。
- 未确认假设：<仅实质性不确定性>。

问题：
<仅会实质性改变目标的必要问题>。

请确认或修正目标简介、执行模式和初始化方案。仅在确认后，我才会准备文件并生成最终的`/goal`。

Stage 2: final

/goal

阶段2：最终

/goal

text

/goal <concise confirmed and verifiable outcome>.

[Active truth, only when needed:
- <minimum path and responsibility>]

Scope: <included area and material exclusions>.

Constraints:
- Keep the goal active until all applicable gates pass. After three failed
  attempts by default, defer one item and continue independent work. Mark
  permission or authorization gaps `needs input`, not automatically `blocked`.
- After each productive loop, report a three-line summary with gate-based
  percentage, this-loop/remaining work, and one primary next action. Report a
  review or commit that spans its own loop; combine them within one loop.
- [Independent review: 1 reviewer for a focused low-risk fast-mode change;
  exactly 3 for deep-mode or major behavior changes; the implementer cannot
  substitute, and fixes require re-review.]
- [Persistent repository changes: create a local commit after applicable
  validation and review pass; do not push by default.]
- [Deep mode: use the contract in state.md for active truth, review, commits,
  and learning.]

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.]

text

/goal <简洁、已确认且可验证的结果>。

[活动事实，仅在需要时添加：
- <最少路径及职责>]

范围：<包含区域及实质性排除项>。

约束：
- 保持目标激活，直到所有适用关卡通过。默认情况下，三次尝试失败后，延迟一个项目并继续独立工作。将权限或授权缺口标记为`needs input`，而非自动标记为`blocked`。
- 每个有效循环后，报告三行摘要，包含基于关卡的百分比、本轮/剩余工作及一项主要下一步操作。报告跨越自身循环的评审或提交；同一循环内的评审和提交合并报告。
- [独立评审：快速模式下聚焦低风险变更使用1名评审者；深度模式或重大行为变更使用恰好3名评审者；实现人员不能替代评审者，修复后需重评审。]
- [持久化仓库变更：适用验证和评审通过后创建本地提交；默认不推送。]
- [深度模式：使用state.md中的契约获取活动事实、评审、提交和学习内容。]

仅当所有适用条件满足时视为完成：
1. <可观察结果或产物>。
2. <必要验证器和证据>。
3. <剩余已确认关卡>。
4. [行为变更：必要的独立评审和重评审已完成，无未解决的高严重性问题。]

仅当穷尽恢复、重优先级调整及独立工作后，所有有意义的剩余项目仍共同依赖<已确认的逻辑冲突、安全边界或强制外部依赖>时，才将整体目标标记为`blocked`。

[仅当请求时添加：使用<N> tokens的预算。]

Final response

最终响应

During Stage 1, return only the goal brief, material questions, and a clear request for confirmation; do not require a fixed status string or include a

/goal

code block. Skip this response format when the user explicitly skips confirmation or delegates the remaining judgment.

During Stage 2, return:

one Markdown code block containing the copy-pasteable
```
/goal
```
;
a short explanation limited to mode, initialization files, and grounded tradeoffs.

Do not start the goal.

阶段1仅返回目标简介、关键问题和明确的确认请求；无需固定状态字符串或包含

/goal

代码块。若用户明确跳过确认或委托剩余判断，跳过此响应格式。

阶段2返回：

一个包含可复制粘贴的
```
/goal
```
的Markdown代码块；
一段简短说明，仅限模式、初始化文件和基于事实的权衡。

不要启动目标。

goal-prompt

Original

Translation

Goal Prompt for Codex and Claude Code

面向Codex和Claude Code的/goal提示词创建指南

Core interaction contract

核心交互约定

Stage 1: investigate and confirm

阶段1：调研与确认

1. Confirm the requested artifact

1. 确认请求的产物

2. Investigate the real context

2. 调研真实上下文

3. Recommend an execution mode

3. 推荐执行模式

a. Fast / small-task mode

a. 快速/小任务模式

b. Deep / long-task mode

b. 深度/长任务模式

4. Select scenario guidance

4. 选择场景指南

5. Design the minimum initialization set

5. 设计最小初始化集合

6. Present the confirmation brief

6. 呈现确认简介

Stage 2: initialize and render

阶段2：初始化与生成

7. Prepare approved files

7. 准备经批准的文件

8. Write the execution contract

8. 编写执行契约

Persistent execution and retry

持久化执行与重试

Loop progress

循环进度

Independent review

独立评审

Milestone commits

里程碑提交

Learning

学习

9. Render the final /goal

9. 生成最终的/goal

Length contract

长度约定

Output templates

输出模板

Stage 1: confirmation brief

阶段1：确认简介

Stage 2: final /goal

阶段2：最终/goal

Final response

最终响应

9. Render the final
`/goal`

9. 生成最终的
`/goal`

Stage 2: final
`/goal`

阶段2：最终
`/goal`