codex-goals
Original:🇺🇸 English
Translated
Patterns and anti-patterns for using OpenAI Codex Goals — the persistent objectives feature introduced in Codex 0.128.0. Use this skill whenever writing, reviewing, or debugging a `/goal` invocation, deciding whether a task should be a Goal at all, drafting a research Goal that needs an evidence ledger, or diagnosing a Goal that completed against the wrong surface. Triggers on `/goal`, "Codex Goal", "Codex goals", "persistent objective", "evidence-based completion", "iteration policy", "blocked stop condition", or any user message describing a multi-turn Codex task with a defined finish line. Trigger even if the user doesn't explicitly mention Goals — if they're typing "/goal" or asking Codex to "keep going until X", this skill applies.
11installs
Sourcepproenca/dot-skills
Added on
NPX Install
npx skill4agent add pproenca/dot-skills codex-goalsTags
Translated version includes tags in frontmatterSKILL.md Content
View Translation Comparison →OpenAI Codex Goals Best Practices
Reference for writing and managing Codex Goals — the persistent objective feature introduced in Codex 0.128.0. "Best practices" here means the patterns and anti-patterns that determine whether a Goal completes against the right evidence vs. silently against the wrong surface. Contains 31 rules across 8 categories, ordered by how much they affect whether a Goal completes correctly. Derived from the official OpenAI cookbook article "Using Goals in Codex".
When to Apply
Reference these guidelines when:
- Deciding whether a task warrants a or a normal prompt
/goal - Drafting or strengthening a invocation
/goal - Reviewing a Goal someone else wrote before activating it
- Debugging a Goal that completed against the wrong verification surface
- Setting up a research Goal where exact proof may not be available
- Managing Goal lifecycle (pause, resume, clear) across thread sessions
- Writing the iteration policy or blocked stop condition for a long-running Goal
- Diagnosing a Goal that hit its budget without completing
Rule Categories by Priority
| Priority | Category | Impact (worst rule) | Prefix |
|---|---|---|---|
| 1 | Goal Fit Decisions | CRITICAL | |
| 2 | Outcome Definition | CRITICAL / HIGH | |
| 3 | Verification Surface | CRITICAL / HIGH | |
| 4 | Boundaries & Iteration | HIGH | |
| 5 | Lifecycle Commands | HIGH | |
| 6 | Evidence-Based Completion | HIGH | |
| 7 | Crafting Strong Goals | MEDIUM | |
| 8 | Research Goals & Anti-Patterns | MEDIUM | |
Individual rule impacts are listed inline in the per-rule frontmatter.
Quick Reference
1. Goal Fit Decisions (CRITICAL)
- — Use a Goal When the Finish Line Is Clear but the Path Is Uncertain
fit-when-to-use - — Require Three Properties Before Setting a Goal — Durable Objective, Evidence Finish Line, Multi-Turn Path
fit-three-required-properties - — Choose a Prompt for Single-Turn Work, a Goal for Outcome-Driven Continuation
fit-prompt-vs-goal - — Skip a Goal When the Finish Line Is Vague
fit-skip-for-vague-targets
2. Outcome Definition (CRITICAL)
- — State the Outcome as a Measurable End State, Not an Activity
outcome-measurable-end-state - — Pin Thresholds with Numbers, Not Relative Comparatives
outcome-quantify-thresholds - — Make the Outcome Narrow Enough to Audit, Broad Enough to Allow Discovery
outcome-narrow-but-discoverable - — For Generated Artifacts, Name the Artifact and Its Validity Conditions
outcome-name-the-artifact
3. Verification Surface (CRITICAL)
- — Always Name the Verification Surface Inside the Goal
verify-name-the-surface - — Include Constraints That Must Not Regress Alongside the Primary Metric
verify-include-constraints - — Use Multiple Verification Surfaces When a Single Check Is Insufficient
verify-multiple-checks-when-needed - — The Verification Surface Must Be Something Codex Can Actually Run or Inspect
verify-surface-must-be-runnable
4. Boundaries & Iteration (HIGH)
- — Bound the Files, Tools, and Repositories Codex May Use
bound-tools-and-files - — Define an Iteration Policy — How Codex Chooses the Next Experiment Between Turns
bound-iteration-policy - — Define a Blocked Stop Condition — What to Report When No Defensible Path Remains
bound-blocked-stop-condition - — Treat the Budget Limit as Halt-and-Summarize, Not Extend
bound-respect-budget
5. Lifecycle Commands (HIGH)
- — Set a Goal with
life-set-with-slash-goal— Available from Codex 0.128.0/goal <text> - — Pause the Goal Before Unrelated Detours, Resume When Returning
life-pause-during-detours - — Clear Stale Goals on Resumed Threads
life-clear-stale-goals - — Use Bare
life-inspect-with-slash-goalto Inspect Current Objective and State Before Continuation/goal
6. Evidence-Based Completion (HIGH)
- — Audit the Objective Against Concrete Evidence Before Marking a Goal Complete
evidence-audit-before-completion - — Reaching the Budget Limit Is Not the Same as Completing the Objective
evidence-budget-is-not-completion - — Surface Blockers Explicitly — Never Substitute a Proxy for the Asked Claim
evidence-honest-blockers
7. Crafting Strong Goals (MEDIUM)
- — Define Six Components in Every Strong Goal — Outcome, Verification, Constraints, Boundaries, Iteration Policy, Blocked Stop
craft-six-components - — Use the Canonical "verified by … while preserving … Use … Between iterations … If blocked …" Pattern
craft-template-pattern - — Ask Codex to Draft the Goal from a Plain-Language Description, Then Tighten
craft-let-codex-draft-it - — Strengthen a Weak Goal by Naming the End State, Verification Surface, and Constraints
craft-strengthen-weak-goals
8. Research Goals & Anti-Patterns (MEDIUM)
- — For Research Goals, Define the Evidence Standard Before Investigation Begins
research-define-evidence-standard-first - — Decompose Research Goals into a Claim Inventory Mapped to Evidence Channels
research-build-claim-inventory - — Final Report Must Preserve Epistemic Levels Per Claim — Use a Structured Ledger Entry
research-preserve-epistemic-ledger - — Avoid the Three Common Goal Anti-Patterns — Keep-Going Wishes, Hidden Uncertainty, Overclaim on Proxy
research-anti-patterns
How to Use
Read individual reference files for detailed explanations and worked examples comparing weak vs strong Goal text:
- Section definitions — Category structure and impact levels
- Rule template — Template for adding new rules
Each rule file contains:
- A 2-4 sentence explanation of WHY the rule matters
- An "Incorrect" example of a weak Goal or anti-pattern
- A "Correct" example showing how to strengthen it
- Reference back to the cookbook section it derives from
Reference Files
| File | Description |
|---|---|
| AGENTS.md | Compiled TOC built by |
| references/_sections.md | Category definitions and impact ordering |
| assets/templates/_template.md | Template for new rules |
| metadata.json | Version and reference information |
| gotchas.md | Failure points discovered through use |