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.