Build audit-friendly /goal prompts for OpenAI Codex
Catalog skill by win4r: Build audit-friendly /goal prompts for OpenAI Codex Install into Cursor, Claude, Codex, or VS Code from this page or review the source for goal-prompt-builder.
Ads
git clone https://github.com/win4r/goal-prompt-builder
Install guides: Cursor skills, Claude Code skills, Codex skills, or VS Code Copilot skills.
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 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.
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.
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".
This skill supports three interaction modes. Ask once at the start:
你希望用哪种方式生成 /goal？
- A. 询问式 — 我一段一段问你（最稳，适合第一次写 /goal）
- B. 全描述式 — 你一句话描述需求，我拆解后只问你确认不确定的地方（最快，适合熟手）
- C. 混合式（默认） — 先选场景模板，再问 3-5 个关键问题（推荐）
Once chosen, follow the matching flow:
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.
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 / TypeScriptpyproject.toml or requirements.txt or setup.py → Python*.xcodeproj/ or Package.swift → Swift / iOSCargo.toml → Rustgo.mod → Goastro.config.* / next.config.* / _config.yml / mkdocs.yml → Static / docs projectFetch the repo if the user gave a URL (only if web tools available):
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.
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.
Ask only what's still missing. Don't ask all 5 at once — ask incrementally so the user can think.
3a. Objective (一句话)
3b. Scope (改什么、不改什么)
3c. Constraints (硬约束)
3d. Done when (验收清单)
<exact command> exits 0; paste summary"3e. Stop if (停止条件)
Before showing the final command, internally score it (don't show the math, just the verdict):
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 大小）
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>
几个关键设计选择：
Keep this explanation under 8 short lines. The user is here for the command, not a lecture.
When the project type is known, read the corresponding reference:
references/project-types.md (Node section)references/project-types.md (Python section)references/project-types.md (Swift section)references/project-types.md (Go section)references/project-types.md (Rust section)references/project-types.md (Static section)Each section provides:
For the chosen scenario, read the corresponding skeleton:
references/scenarios.md § Refactorreferences/scenarios.md § Featurereferences/scenarios.md § Batchreferences/scenarios.md § Archaeologyreferences/scenarios.md § UI Auditreferences/scenarios.md § GatekeeperEach scenario has its own emphasis — e.g., archaeology goals emphasize Constraints (禁区), feature goals emphasize "First action: read SPEC + report counts".
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:
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.
These are non-negotiable. They come from continuation.md's actual behavior.
@filename reference uncertainty and exposes loading failures early./goal for the user — it only generates the textgit status checks, no test runs)/goal doesn't exist there/plan, /compact, or other Codex commandsFinal output is always:
/goal command (so the user can copy)That's it. No long lecture. The user is here for a command.