# Goal Writer

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

- Skill: `muxuuu/goal-writer` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add muxuuu/goal-writer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/muxuuu/goal-writer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: muxuuu (https://skillmd.com/u/muxuuu)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/muxuuu/goal-writer

---


# 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:

```text
/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:

```markdown
需要先确认一个关键点：<one question>
```

When ready:

````markdown
**推荐 Goal**

```text
/goal ...
```

**审计点**
- 结果：
- 证据：
- 约束：
- 边界：
- 迭代：
- 阻塞：
````

For a one-turn task:

````markdown
这个任务适合普通 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.