| name | goal-writer |
| description | Use when the user wants to write, refine, audit, or strengthen a Codex `/goal` prompt for long-running work, including debugging, optimization, flaky tests, migrations, refactors, research reproduction, experiment campaigns, and evidence-backed deliverables. |
Goal Writer
Turn a rough task into a strong Codex /goal prompt. A strong Goal is a thread-scoped completion contract: it defines the target, the evidence that proves progress, the constraints, the working boundary, the iteration rule, and the blocked-stop report.
Source Principles
This skill follows the OpenAI Goals practice:
- A Goal fits work with a durable objective, an evidence-based finish line, and a path that may need several turns.
- Completion must be checked against concrete evidence: tests, benchmarks, logs, files, generated artifacts, command output, or research evidence.
- The Goal should preserve uncertainty explicitly when exact proof may be unavailable.
- A vague finish line should trigger clarification before drafting.
- One-turn edits, simple explanations, short reviews, and single-answer questions should receive a normal prompt recommendation.
Readiness Gate
Before writing /goal, check whether the request has enough information.
Required:
- Outcome: what should be true when done.
- Verification surface: what concrete evidence proves it.
Important:
- Constraints: behavior, APIs, quality bars, accuracy standards, or files that must stay intact.
- Boundaries: allowed files, repositories, data, tools, commands, or external sources.
- Blocked stop condition: when Codex should stop and what it should report.
Ask one concise question when Outcome or Verification surface is absent. Ask one question per turn. Choose the highest-impact absent field. Stop asking once the Goal can be audited.
Default question limit: 3. After 3 questions, either write the strongest defensible Goal from confirmed information or state the single absent item blocking a defensible Goal.
Question Priority
- Verification: what tests, benchmark, logs, artifact, report, or source material should decide completion?
- Outcome: what exact state, behavior, threshold, or deliverable should exist at the end?
- Constraints: what behavior, interface, result, data, or file must stay intact?
- Boundaries: what files, folders, repositories, commands, data, tools, or sources may Codex use?
- Blocked stop: what should the final report contain if completion stays blocked?
Drafting Pattern
Use this shape when ready:
/goal <desired end state>, verified by <specific evidence>, while preserving <constraints>. Use <allowed inputs, tools, files, data, or repositories>. Between iterations, <how Codex should choose and report the next best action>. If blocked or valid paths are exhausted, stop with <attempted paths, evidence gathered, blocker, and next input needed>.
Keep the final Goal compact. Prefer one recommended Goal. Add a strict version only when the user asks for tighter control or the task has high blast radius.
For examples by task type, read references/goal_patterns.md.
Output Format
When more information is needed:
需要先确认一个关键点：<one question>
When ready:
**推荐 Goal**
```text
/goal ...
```
**审计点**
- 结果：
- 证据：
- 约束：
- 边界：
- 迭代：
- 阻塞：
For a one-turn task:
这个任务适合普通 prompt：
```text
...
```
Quality Bar
- Preserve user-provided facts exactly.
- Use only user-confirmed tests, commands, metrics, files, tools, or source material.
- Ask before choosing verification evidence when the evidence surface is unclear.
- For research, separate confirmed findings, approximate support, blocked claims, and remaining uncertainty.
- For coding work, include regression protection and explicit verification commands when the user provides them.
- For experiment campaigns, require a result ledger, run identifiers, metrics, and stop criteria.
