goalcraft

Goalcraft

Core Contract

Convert messy intent into a compact, activation-ready Codex /goal objective that keeps the agent moving until real completion evidence exists. The returned goal objective must be 4,000 characters or fewer, and the normal working target is 2,800 characters. Prefer drafting the goal text only. Do not call create_goal, thread/goal/set, or otherwise activate a goal unless the user explicitly asks to start or set it.

For current Codex /goal mechanics, read references/codex-goal-contract.md when the exact runtime behavior matters.

Workflow

1. Identify the rough objective, workspace, and expected end state.

   • If the user supplied a draft, preserve their intent and tighten it.
   • If a repo or files are mentioned, inspect them before finalizing the goal.
   • If a critical success criterion is missing, ask the smallest necessary question; otherwise state assumptions.

2. Shape the goal around evidence, not effort. Use this list as input thinking, not as required output structure.

   • Destination: what must be true at the end.
   • Starting point: current context, repo, branch, artifact, issue, or known state.
   • Core objective: the concrete work to complete.
   • Scope: files, directories, systems, or task boundaries the agent should stay within.
   • Deliverables: concrete artifacts such as code paths, tests, PRs, reports, screenshots, or logs.
   • Must not regress: constraints, behavior to preserve, safety boundaries.
   • Autonomy rules: when to continue, when to ask, what to verify directly.
   • Checkpoint rhythm: how often to test, review, summarize progress, or pause.
   • Verification gates: commands, inspections, screenshots, evals, or other proof loops.
   • Done when: artifact-level acceptance criteria.
   • Stop conditions: blockers, destructive actions, missing credentials, user approval boundaries.
   • Success metric: the observable result that proves completion.

3. Keep the objective usable by Codex.

   • Hard limit: the objective text after /goal must be 4,000 characters or fewer.
   • Normal target: draft to 2,800 characters or fewer.
   • Strict fallback ceiling: do not return a normal goal above 3,400 characters.
   • Treat 3,800 characters or more as a failed draft even if it is technically below the hard limit.
   • Put useful but nonessential detail in companion notes outside the /goal payload.
   • Make every requirement auditable against files, commands, PR state, logs, screenshots, or explicit user confirmation.
   • Include exact commands only when they are already known from the repo or user.
   • Avoid hidden flags in slash text. /goal --tokens 50K ... is literal objective text in the TUI, not parsed syntax.
   • If a token budget is requested, present it separately from the objective text unless the target surface supports a separate budget field.
   • For complex or ambiguous work, recommend a planning/interview pass before setting the goal.
   • For very large work, include subagent/orchestration guidance only when the current Codex environment supports subagents and the work can be split into bounded, reviewable lanes.