goal-prompt-builder

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

/goal Prompt Builder

/goal 提示词构建器

This skill turns a fuzzy task description ("我想让 Codex 帮我重构鉴权") into a complete, audit-friendly

/goal

command that's ready to paste into Codex CLI 0.128+.

此技能可将模糊的任务描述（如“我想让 Codex 帮我重构鉴权”）转换为完整的、审计友好的

/goal

命令，可直接粘贴到Codex CLI 0.128+中使用。

Why this skill exists

此技能的存在意义

Codex 0.128 added

/goal

as a persistent objective with a runtime-injected audit prompt (

continuation.md

). The audit prompt forces the model to build a "prompt-to-artifact checklist" — but only if the user's goal text can be mapped to one. Vague goals produce vague checklists, which produce false completions. This skill exists to make sure every

/goal

you generate has the structure that lets the audit mechanism actually work.

Codex 0.128版本新增了

/goal

作为持久化目标，同时引入了运行时注入的审计提示词（

continuation.md

）。该审计提示词会强制模型生成“提示词到产物的检查清单”——但只有当用户的goal文本可以映射到该清单时才会生效。模糊的goal会生成模糊的检查清单，进而导致错误完成。此技能的作用是确保你生成的每一条

/goal

都具备能让审计机制正常工作的结构。

The golden template (5 sections, in this order)

黄金模板（5个部分，按以下顺序排列）

Every

/goal

Claude generates with this skill follows this structure exactly:

/goal <objective>.

[Optional: First action: read X, Y, Z and report counts. Wait for ack.]

Scope: <files / subsystem / feature area>.

Constraints:
  - <what not to change>
  - <compatibility / permission boundaries>
  - <project-specific rules from AGENTS.md / CLAUDE.md>

Done when:
  1. <verifiable artifact 1 — cite file or command>
  2. <verifiable artifact 2>
  ...

Stop if:
  - <mechanically detectable condition 1>
  - <mechanically detectable condition 2>
  ...

Use a token budget of <N> tokens for this goal.

Why this order: matches

continuation.md

's expected reading flow — objective first, then scope to bound the search, then constraints to prune options, then acceptance to define success, then stop-if as runtime guards.

使用此技能生成的每一条

/goal

都会严格遵循以下结构：

/goal <objective>.

[可选：第一步操作：读取X、Y、Z并报告统计数据。等待确认。]

Scope: <文件/子系统/功能区域>.

Constraints:
  - <不可修改的内容>
  - <兼容性/权限边界>
  - <来自AGENTS.md / CLAUDE.md的项目特定规则>

Done when:
  1. <可验证的产物1 — 引用文件或命令>
  2. <可验证的产物2>
  ...

Stop if:
  - <可机械检测的条件1>
  - <可机械检测的条件2>
  ...

Use a token budget of <N> tokens for this goal.

为何采用此顺序：与

continuation.md

预期的阅读流程一致——先明确目标，再通过范围限定搜索边界，接着通过约束筛选选项，然后通过验收标准定义成功，最后通过停止条件作为运行时防护。

Workflow

工作流程

When this skill triggers, walk the user through these 6 steps. Step 0 (interaction mode) and Step 1 (project detection) happen automatically — Step 0 needs one user choice, Step 1 needs zero if filesystem is accessible. Don't skip steps unless the user explicitly says "I'll fill it in myself, just give me the template".

当触发此技能时，将引导用户完成以下6个步骤。步骤0（交互模式）和步骤1（项目检测）会自动执行——步骤0需要用户选择一次，若可访问文件系统则步骤1无需用户操作。除非用户明确表示“我自己来填，给我模板就行”，否则不要跳过任何步骤。

Step 0: Pick interaction mode

步骤0：选择交互模式

This skill supports three interaction modes. Ask once at the start:

你希望用哪种方式生成 /goal？

A. 询问式 — 我一段一段问你（最稳，适合第一次写 /goal）

B. 全描述式 — 你一句话描述需求，我拆解后只问你确认不确定的地方（最快，适合熟手）

C. 混合式（默认） — 先选场景模板，再问 3-5 个关键问题（推荐）

Once chosen, follow the matching flow:

A. 询问式 → Step 1 → Step 2 → Step 3a → 3b → 3c → 3d → 3e → Step 4 → Step 5 (each input gathered separately)
B. 全描述式 → Step 1 → ask "用一段话描述你想做什么 / scope / 验收 / 不希望发生什么" → parse into 5 sections → Step 4 → ask user to confirm only the gaps → Step 5
C. 混合式 → Step 1 → Step 2 → Step 3 (batched: ask all missing fields at once) → Step 4 → Step 5

Mode B is most powerful when the user has thought about the task. Mode A is safest when they haven't. Mode C is the default sweet spot.

If the user doesn't answer this question explicitly, default to mode C and proceed.

此技能支持三种交互模式。开始时仅需询问一次：

你希望用哪种方式生成 /goal？

A. 询问式 — 我一段一段向你提问（最稳妥，适合首次编写/goal）

B. 全描述式 — 你用一句话描述需求，我拆解后仅询问你不确定的部分（最快，适合熟练用户）

C. 混合式（默认） — 先选择场景模板，再询问3-5个关键问题（推荐）

用户选择后，遵循对应的流程：

A. 询问式 → 步骤1 → 步骤2 → 步骤3a → 3b → 3c → 3d → 3e → 步骤4 → 步骤5（逐个收集输入）
B. 全描述式 → 步骤1 → 询问“用一段话描述你想做什么/范围/验收标准/不希望发生的情况” → 拆分为5个部分 → 步骤4 → 仅询问用户确认有疑问的部分 → 步骤5
C. 混合式 → 步骤1 → 步骤2 → 步骤3（批量：一次性询问所有缺失字段） → 步骤4 → 步骤5

当用户已经思考过任务时，模式B最为高效。当用户对任务还不清晰时，模式A最稳妥。模式C是默认的最优选择。

如果用户未明确回答此问题，默认采用模式C并继续执行。

Step 1: Detect (don't ask) the project type

步骤1：检测（而非询问）项目类型

Auto-detection comes first. Only fall back to asking if detection fails.

Run this detection sequence:

Check the conversation context. Has the user already provided a repo URL, file path, or code snippet? Read those for hints first.
Probe the filesystem (if you have file tools and the user is in a project directory):
- ```
package.json
```
  exists → Node / TypeScript
- ```
pyproject.toml
```
  or
```
requirements.txt
```
  or
```
setup.py
```
  → Python
- ```
*.xcodeproj/
```
  or
```
Package.swift
```
  → Swift / iOS
- ```
Cargo.toml
```
  → Rust
- ```
go.mod
```
  → Go
- ```
astro.config.*
```
  /
```
next.config.*
```
  /
```
_config.yml
```
  /
```
mkdocs.yml
```
  → Static / docs project
Fetch the repo if the user gave a URL (only if web tools available):
- GitHub URL → fetch the README + try to identify config files
- Read
```
CLAUDE.md
```
  and
```
AGENTS.md
```
  if they exist (these are gold for Constraints)
Fall back to asking only if all auto-detection failed:

我没法自动判断项目类型——这是 Node / Python / Swift / Go / Rust / 静态 / 其他？

When detection succeeds, announce what you found in one sentence so the user can correct you:

检测到这是一个 Swift / iOS 项目（找到 lingolearn.xcodeproj + CLAUDE.md）。我会按 Swift 项目默认约束适配。如果不对，告诉我。

Then load the matching reference from

references/project-types.md

. Also load any
CLAUDE.md
/
AGENTS.md
found — these contain project-specific rules that override defaults.

自动检测优先。仅当检测失败时才 fallback 到询问。

执行以下检测流程：

检查对话上下文：用户是否已提供仓库URL、文件路径或代码片段？优先从这些内容中寻找线索。
探测文件系统（若具备文件工具且用户处于项目目录中）：
- 存在
```
package.json
```
  → Node / TypeScript
- 存在
```
pyproject.toml
```
  或
```
requirements.txt
```
  或
```
setup.py
```
  → Python
- 存在
```
*.xcodeproj/
```
  或
```
Package.swift
```
  → Swift / iOS
- 存在
```
Cargo.toml
```
  → Rust
- 存在
```
go.mod
```
  → Go
- 存在
```
astro.config.*
```
  /
```
next.config.*
```
  /
```
_config.yml
```
  /
```
mkdocs.yml
```
  → 静态/文档项目
若用户提供了URL则拉取仓库（仅当具备网络工具时）：
- GitHub URL → 拉取README并尝试识别配置文件
- 若存在
```
CLAUDE.md
```
  和
```
AGENTS.md
```
  则读取这些文件（这些文件对Constraints部分非常重要）
仅当所有自动检测失败时才询问：

我无法自动判断项目类型——这是Node/Python/Swift/Go/Rust/静态/其他类型？

当检测成功时，用一句话告知用户检测结果，以便用户纠正：

检测到这是一个Swift / iOS项目（找到lingolearn.xcodeproj + CLAUDE.md）。我会按Swift项目的默认约束进行适配。如果有误，请告知我。

然后从

references/project-types.md

中加载对应的参考内容。同时加载找到的任何
CLAUDE.md
/
AGENTS.md
——这些文件包含的项目特定规则会覆盖默认设置。

Step 2: Pick a scenario template

步骤2：选择场景模板

Ask: 这个 goal 属于哪种类型？

选项	说明
A. 重构	改一个文件 / 子系统
B. 新功能实现	已有 SDD spec 的功能
C. 批量补测试 / 修 bug	重复型任务，可枚举来源
D. 代码考古 / 研究	只读不动手
E. UI / 行为 audit	对照文档审实现
F. 守门员 review	评估能否合并，不修改
G. 自定义	让我描述

Each option maps to a different default skeleton — see

references/scenarios.md

for the full templates.

询问：这个goal属于哪种类型？

选项	说明
A. 重构	修改单个文件/子系统
B. 新功能实现	已有SDD规格的功能
C. 批量补测试/修bug	重复型任务，可枚举来源
D. 代码考古/研究	只读不修改
E. UI/行为audit	对照文档审核实现
F. 守门员review	评估能否合并，不修改代码
G. 自定义	由我描述需求

每个选项对应不同的默认框架——完整模板请参考

references/scenarios.md

。

Step 3: Gather the 5 inputs (in this order)

步骤3：收集5项输入（按以下顺序）

Ask only what's still missing. Don't ask all 5 at once — ask incrementally so the user can think.

3a. Objective (一句话)

One sentence describing what changes by the end.
If the user gives a verb-less noun phrase ("Cohere rerank support"), turn it into a verb phrase ("Add Cohere rerank support to retrieval pipeline").
Reject vague verbs like "improve", "optimize", "clean up" — ask for the concrete change.

3b. Scope (改什么、不改什么)

Which files / directories / subsystems are in play
For brownfield projects: probe whether v1.x beta files or sensitive modules exist that should be off-limits

3c. Constraints (硬约束)

Pull from AGENTS.md / CLAUDE.md if available
Add project-type defaults from the loaded reference (e.g., for Swift: "do not modify project.pbxproj")
Ask if there's a "MUST NOT modify" list

3d. Done when (验收清单)

This is the most important section. Push back hard if items are vague.
Each item must cite a file, command, test name, or measurable artifact.
Replace "测试通过" → "
```
<exact command>
```
exits 0; paste summary"
Replace "做完" → enumerate the deliverables
Aim for 5-8 items; fewer than 3 is a red flag

3e. Stop if (停止条件)

Each must be mechanically detectable
Include project-type defaults (e.g., for Node: "needs npm install for new dep")
Include a regression guard: "existing tests start failing — do not fix by editing tests"

仅询问仍缺失的信息。不要一次性询问全部5项——逐步询问，方便用户思考。

3a. Objective（一句话）

用一句话描述最终要实现的变更。
如果用户给出无动词的名词短语（如“Cohere rerank支持”），将其转换为动词短语（如“为检索管道添加Cohere rerank支持”）。
拒绝使用模糊动词，如“improve”“optimize”“clean up”——要求用户说明具体的变更内容。

3b. Scope（修改范围、排除范围）

涉及哪些文件/目录/子系统
对于遗留项目：询问是否存在v1.x测试版文件或敏感模块需要排除在外

3c. Constraints（硬约束）

若有AGENTS.md / CLAUDE.md则从中提取内容
添加从加载的参考内容中获取的项目类型默认约束（例如，对于Swift项目：“请勿修改project.pbxproj”）
询问是否存在“绝对不可修改”的列表

3d. Done when（验收清单）

这是最重要的部分。如果内容模糊，务必要求用户明确。
每一项必须引用文件、命令、测试名称或可衡量的产物。
将“测试通过”替换为“
```
<精确命令>
```
执行退出码为0；粘贴执行摘要”
将“做完”替换为枚举交付物
目标为5-8项；少于3项属于异常情况

3e. Stop if（停止条件）

每一项必须可被机械检测
添加项目类型默认条件（例如，对于Node项目：“需要为新依赖执行npm install”）
添加回归防护：“现有测试开始失败——请勿通过修改测试来‘修复’”

Step 4: Predict audit-friendliness

步骤4：预测审计友好性

Before showing the final command, internally score it (don't show the math, just the verdict):

Acceptance count: 0 = bad, 1-2 = warn, 3-5 = good, 6-8 = excellent
Vague verbs detected: "improve", "optimize", "全部", "彻底", "all", "everything" → flag
Stop-if specificity: "if unclear" = bad, "if file X appears in git diff" = good
Token budget present: missing = warn
Mechanical verifiability: every Done-when item has a cite-able artifact = good

If score is below ~70%, don't ship the command yet. Instead, surface the weak spots and ask the user to refine. Be specific:

⚠ 我发现三处可以加强的地方：

Done when 第 2 条"测试覆盖" → 改成"测试名称 + 退出码"会更准

Stop if 缺少"现有测试 regression"兜底

Token 预算未指定，建议 80K（基于 scope 大小）

在展示最终命令前，内部对其进行评分（无需展示评分过程，仅展示结论）：

验收项数量：0=差，1-2=警告，3-5=良好，6-8=优秀
检测到模糊动词：出现“improve”“optimize”“全部”“彻底”“all”“everything”等词→标记风险
Stop-if特异性：“若不明确则停止”=差，“若git diff中出现文件X则停止”=良好
是否包含Token预算：缺失=警告
机械可验证性：每个Done-when项都有可引用的产物=良好

如果评分低于约70%，暂不输出命令。相反，指出薄弱环节并要求用户优化。要具体：

⚠ 我发现三处可以优化的地方：

Done when第2条“测试覆盖”→改为“测试名称 + 退出码”会更准确

Stop if缺少“现有测试回归”兜底条件

未指定Token预算，建议设置为80K（基于范围大小）

Step 5: Render and cite design choices

步骤5：渲染并说明设计选择

When all checks pass, render the final

/goal

in a code block (so it's copy-pasteable) and follow with a brief explanation of the key design choices — not a tutorial, just enough so the user knows why each choice was made.

Format:

/goal <full command here>

几个关键设计选择：

为什么 Done when 第 N 条这么写
为什么 Stop if 包含某条
为什么预算定这个数

Keep this explanation under 8 short lines. The user is here for the command, not a lecture.

当所有检查通过后，将最终的

/goal

命令渲染到代码块中（方便用户复制），然后附上简短的关键设计选择说明——无需教程，只需让用户了解每个选择的原因即可。

格式：

/goal <完整命令内容>

几个关键设计选择：

为何Done when第N条如此编写
为何Stop if包含某条条件
为何预算设置为该数值

说明部分控制在8行以内。用户的核心需求是获取命令，而非冗长讲解。

Project type loading

项目类型加载

When the project type is known, read the corresponding reference:

Node / TypeScript →
```
references/project-types.md
```
(Node section)
Python →
```
references/project-types.md
```
(Python section)
Swift →
```
references/project-types.md
```
(Swift section)
Go →
```
references/project-types.md
```
(Go section)
Rust →
```
references/project-types.md
```
(Rust section)
Static / docs →
```
references/project-types.md
```
(Static section)

Each section provides:

Default test command with full flags
Default build / type-check command
Project-type-specific Stop-if bullets to include
Common false-completion traps to guard against

当确定项目类型后，读取对应的参考内容：

Node / TypeScript →
```
references/project-types.md
```
（Node章节）
Python →
```
references/project-types.md
```
（Python章节）
Swift →
```
references/project-types.md
```
（Swift章节）
Go →
```
references/project-types.md
```
（Go章节）
Rust →
```
references/project-types.md
```
（Rust章节）
静态/文档 →
```
references/project-types.md
```
（Static章节）

每个章节包含：

带完整参数的默认测试命令
默认构建/类型检查命令
需包含的项目类型特定Stop-if条目
需要防范的常见错误完成陷阱

Scenario templates

场景模板

For the chosen scenario, read the corresponding skeleton:

A. 重构 →
```
references/scenarios.md
```
§ Refactor
B. 新功能实现 →
```
references/scenarios.md
```
§ Feature
C. 批量补测试 / 修 bug →
```
references/scenarios.md
```
§ Batch
D. 代码考古 →
```
references/scenarios.md
```
§ Archaeology
E. UI / 行为 audit →
```
references/scenarios.md
```
§ UI Audit
F. 守门员 review →
```
references/scenarios.md
```
§ Gatekeeper
G. 自定义 → use bare 5-section template, no skeleton

Each scenario has its own emphasis — e.g., archaeology goals emphasize Constraints (禁区), feature goals emphasize "First action: read SPEC + report counts".

根据选择的场景，读取对应的框架：

A. 重构 →
```
references/scenarios.md
```
§ Refactor
B. 新功能实现 →
```
references/scenarios.md
```
§ Feature
C. 批量补测试/修bug →
```
references/scenarios.md
```
§ Batch
D. 代码考古 →
```
references/scenarios.md
```
§ Archaeology
E. UI/行为audit →
```
references/scenarios.md
```
§ UI Audit
F. 守门员review →
```
references/scenarios.md
```
§ Gatekeeper
G. 自定义 → 使用基础的5部分模板，无框架

每个场景有不同的侧重点——例如，考古类goal强调Constraints（禁区），功能类goal强调“第一步操作：读取SPEC并报告统计数据”。

Worked examples

示例演示

When the user's case is ambiguous about how to fill a section, consult

references/examples.md

. It contains 5 end-to-end transformations (vague request → final command) covering the most common patterns:

Refactor (Node/TS) — cleanest baseline
Feature with SDD spec (Swift) — most heavily constrained
Vague request → push back instead of rendering — when not to render
Archaeology (static / docs project) — read-only goals
"Just give me the template" — when to skip the interview

Especially read example 3 for guidance on when to refuse rendering. Don't ship a goal you can't defend — surface the weak spots and ask for refinement first.

当用户的案例在填写某部分时存在歧义，可参考

references/examples.md

。其中包含5个完整的转换示例（模糊请求→最终命令），覆盖最常见的场景：

重构（Node/TS）——最清晰的基线示例
基于SDD规格的功能实现（Swift）——约束最多的示例
模糊请求→拒绝渲染——何时不渲染命令
代码考古（静态/文档项目）——只读类goal示例
“直接给我模板”——何时跳过询问流程

尤其要参考示例3，了解何时拒绝渲染。不要输出你无法保证质量的goal——先指出薄弱环节，要求用户优化。

Hard rules (always follow)

硬性规则（必须遵守）

These are non-negotiable. They come from

continuation.md

's actual behavior.

Never write Stop-if as "if unclear, stop" — that's not mechanically detectable. Ask the user to enumerate concrete conditions.
Never let "all / everything / 全部 / 彻底" through — flag and ask for a number or enumerable source.
Always include a token budget — missing budget = no soft stop = potential runaway.
Always include a "no test-rewriting" stop-if for any goal that touches tested code: "Existing tests start failing — this is a regression, do not 'fix' by editing tests."
For SDD-driven goals (scenario B), the first action is always "read X files and report counts" — bypasses
```
@filename
```
reference uncertainty and exposes loading failures early.
For brownfield projects, always ask about MUST NOT modify list — the absence of one is the #1 cause of scope creep.

这些规则不可协商，源自

continuation.md

的实际行为。

绝不要将Stop-if写为“若不明确则停止”——这无法被机械检测。要求用户枚举具体条件。
绝不要允许“all/everything/全部/彻底”这类表述——标记并要求用户提供具体数量或可枚举的范围。
必须包含Token预算——缺失预算=无软停止机制=可能出现失控情况。
对于涉及已测试代码的所有goal，必须添加“禁止修改测试”的Stop-if条件：“现有测试开始失败——这属于回归问题，请勿通过修改测试来‘修复’。”
对于基于SDD的goal（场景B），第一步操作必须是“读取X文件并报告统计数据”——避免
```
@filename
```
引用不确定性，尽早暴露加载失败问题。
对于遗留项目，必须询问绝对不可修改的列表——缺少该列表是范围蔓延的首要原因。

Common failure modes to coach the user through

需要引导用户规避的常见失败模式

"测试通过"做验收: too vague. Force into "exact command + exit code + paste summary".
没有 Stop if: goal is a one-way door. Add at least 3 mechanically detectable conditions.
预算 > 300K: too big to audit reliably. Suggest splitting into two goals.
Scope = "整个仓库": too wide. Push for a specific directory or subsystem.
"我之后再补 acceptance": this is the failure pattern. Refuse to render until at least 3 items exist.

用“测试通过”作为验收标准：过于模糊。强制转换为“精确命令 + 退出码 + 粘贴执行摘要”。
没有Stop if条件：goal是单向门。至少添加3个可机械检测的条件。
预算>300K：过大导致审计不可靠。建议拆分为两个goal。
范围=“整个仓库”：过于宽泛。要求用户指定具体目录或子系统。
“我之后再补验收标准”：这是失败的前兆。至少有3项验收标准才会渲染命令。

What this skill does NOT do

此技能不具备的功能

Does not run the
```
/goal
```
for the user — it only generates the text
Does not validate the project state (no
```
git status
```
checks, no test runs)
Does not handle Codex versions older than 0.128 —
```
/goal
```
doesn't exist there
Does not generate prompts for
```
/plan
```
,
```
/compact
```
, or other Codex commands

不会为用户运行
```
/goal
```
命令——仅生成命令文本
不会验证项目状态（不执行
```
git status
```
检查，不运行测试）
不支持0.128版本之前的Codex——这些版本中不存在
```
/goal
```
命令
不会为
```
/plan
```
、
```
/compact
```
或其他Codex命令生成提示词

Output format reminder

输出格式提醒

Final output is always:

A markdown code block containing the
```
/goal
```
command (so the user can copy)
A short bullet list of the key design choices (no more than 8 short lines)
Optional: a one-line "audit-friendliness verdict" (e.g., "审计友好度：优秀 · 7 项验收 · 0 风险标记")

That's it. No long lecture. The user is here for a command.

最终输出必须包含：

包含
```
/goal
```
命令的Markdown代码块（方便用户复制）
简短的关键设计选择列表（不超过8行短文本）
可选：一行“审计友好性结论”（例如，“审计友好度：优秀 · 7项验收 · 0风险标记”）

仅此而已。无需冗长讲解。用户的核心需求是获取命令。