Define durable Codex work with ak:codex-goal

Use ak:codex-goal to decide whether work belongs in Codex Goal mode and to draft a bounded objective with a verifiable stop condition. The Skill provides guidance; Codex /goal is the feature that attaches persisted goal state to the active chat and continues work toward it.

Choose ak:codex-goal for durable mechanical work

Use ak:codex-goal when all are true

• The task is longer than one normal turn and is mainly mechanical.
• Completion can be proved with tests, an eval, a build, or another explicit artifact.
• Scope and constraints are clear enough that Codex does not need a product or architecture decision at every checkpoint.
• You can keep the relevant workspace and active chat available for the run.

Choose another workflow when

• The outcome is exploratory, vague, or still needs product direction. Plan or clarify it first.
• The work is an unrelated backlog rather than one objective.
• The task changes production credentials, destructive shared infrastructure, budget, publication, provider state, or a live account without repeated human decisions.
• You need generic iteration or dispatch across multiple coding-agent CLIs. Goal mode is one Codex objective, not a multi-provider orchestrator.

Prepare Codex and the goal contract

Before you start:

• Confirm Marketing Kit is installed where you will invoke the helper Skill.
• Confirm /goal appears in the Codex slash-command list for the actual Codex app, CLI, or IDE chat that will own the persisted state.
• Provide one outcome, files to read first, constraints, validation after each checkpoint, and a verifiable stop condition.
• Preserve unrelated changes and define Git, network, secrets, provider, publication, deployment, and destructive-action boundaries.
• Require tests to remain intact; do not weaken, narrow, skip, or delete them to make the goal appear complete.

Run the Skill

Use the AgentKit invocation to draft the contract without starting Goal mode implicitly:

/ak:codex-goal "Draft a Codex goal to migrate the approved campaign schema. Preserve public fields, validate focused tests after each checkpoint, do not commit or deploy, and stop for any product decision"

/ak:codex-goal "Draft a Codex goal to migrate the approved campaign schema. Preserve public fields, validate focused tests after each checkpoint, do not commit or deploy, and stop for any product decision"

$ak:codex-goal "Draft a Codex goal to migrate the approved campaign schema. Preserve public fields, validate focused tests after each checkpoint, do not commit or deploy, and stop for any product decision"

Review the returned contract, then start it in the intended Codex chat with:

/goal Complete <objective>. Read first: <files>. Constraints: <boundaries>. Validate after each checkpoint: <command>. Stop when <verifiable end state>, or when further work needs human input.

Control the persisted goal explicitly

If /goal is absent, the packaged Skill tells you to check [features] with goals = true in config.toml or run codex features enable goals. Current Codex releases may already enable the stable feature by default. Changing configuration is a separate user-level mutation: inspect the active config and approve it before writing.

Understand the stages

1. Apply the use test. The Skill rejects vague exploration, unbounded backlogs, and work whose next step repeatedly needs a human decision.
2. Draft one contract. It names the outcome, first reads, constraints, validation loop, progress-log expectation, and stop condition.
3. Review authority. You decide whether the objective and every mutation class are acceptable before setting persisted state.
4. Start Goal mode in Codex. /goal <objective> attaches the target to the active chat; the AgentKit Skill invocation alone does not do this.
5. Validate at checkpoints. Codex records progress and runs the specified verification without weakening the acceptance evidence.
6. Steer or pause. Add context, inspect status, pause for ambiguity, or clear the state when the objective should no longer continue.
7. Stop on evidence or human input. Completion requires the stated end state; a blocked product, safety, credential, or architecture decision returns to a person.
8. Review final state. Inspect the diff and validation before any separate commit, push, merge, publication, or deployment workflow.

Keep approval and automatic continuation bounded

For concurrent goals, use separate chats and separate worktrees when files may change. Do not give two active goals write access to the same checkout. A goal being persistent does not make its assumptions current or its output correct.

Verify outputs and evidence

A complete preparation should provide:

• One objective with measurable completion criteria.
• Exact first-read files, scope boundaries, non-goals, and prohibited effects.
• A validation command or artifact for each meaningful checkpoint.
• A rule to pause instead of inventing a product or architecture decision.
• A clear distinction between the drafted Skill output and the active Codex /goal state.

A completed goal should leave a concise progress log, the final diff or artifact, validation results, unresolved risks, and the final goal state. Review all of it before clearing the goal or authorizing downstream Git or release actions.

Troubleshoot and respect limits

The Skill cannot make vague work safe, guarantee unattended completion, or preserve state outside the supported Codex surface. Availability and controls can change with Codex, so verify the live slash-command list before relying on them. See Runtime adapters, Projects, artifacts, and checkpoints, and Marketing Kit for surrounding boundaries.