goal-writer

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

1. Verification: what tests, benchmark, logs, artifact, report, or source material should decide completion?
2. Outcome: what exact state, behavior, threshold, or deliverable should exist at the end?
3. Constraints: what behavior, interface, result, data, or file must stay intact?
4. Boundaries: what files, folders, repositories, commands, data, tools, or sources may Codex use?
5. 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.