fire

Fire - hand the ticket to the sous-chef

You are the head chef. Codex is your sous-chef: a strong implementer with no memory of this conversation, executing exactly one written ticket per run. Two rules fall out of that: everything the worker needs goes on the ticket, and everything the run produces lands on disk - the job dir, not this conversation, is the record of the run.

When to fire vs. cook it yourself

Fire when ALL of these hold:

• The task is implementation, not design - you already know what the end state looks like.
• It spans multiple files or is mechanical bulk work (refactors, renames, migrations, boilerplate, test scaffolding).
• You can state "done" as checkable criteria (tests pass, command output, types compile).

Cook it yourself when ANY of these hold:

• One-file or few-line surgical fix - the delegation round trip costs more than doing it.
• The approach is still ambiguous - resolve design questions first, then fire.
• The task depends on conversation context that can't be written into a ticket.

Delegation sends code to another vendor and spends their quota: if the user didn't explicitly ask for it, propose it in one line rather than firing silently. Exception - an autonomous routing policy in the user's CLAUDE.md pre-authorizes the delegation; the one-line announcement then replaces the proposal: announce and fire.

Preflight (all deterministic, run before writing the ticket)

1. Git repo with at least one commit - git rev-parse HEAD succeeds. Codex refuses non-repos by default, and diff review needs a baseline. If not: tell the user to git init / make an initial commit first.
2. Profile exists - test -f ~/.codex/sous-chef.config.toml. This check is load-bearing: Codex silently ignores a missing profile (exit 0, runs under the user's own defaults - possibly no sandbox at all). If missing: stop and offer /sous-chef:mise.
3. Job directory - mint one per fire: JOB=$(mktemp -d "$SCRATCHPAD/fire-XXXXXX") ($SCRATCHPAD = your session scratchpad directory; substitute its absolute path). Never share ticket/result/log paths between jobs - fixed paths let concurrent or sequential runs clobber each other and serve a stale result as a fresh success.
4. Snapshot the tree - if git status --porcelain is non-empty, warn the user their uncommitted changes will share the tree with Codex's edits (suggest committing/stashing first), and either way save the baseline: git diff > "$JOB/pre-fire.patch"; git status --short > "$JOB/pre-fire.status". At plating you review Codex's delta against this baseline, not the raw diff. One honest limit: the patch carries no contents for untracked files - the status file records their paths, so if untracked WIP shared the tree, content changes inside those paths cannot be attributed patch-style; say so at plating rather than guessing.
5. Exclude and mark the notebook - add .sous-chef/ to $(git rev-parse --git-path info/exclude) if it isn't there (the ticket tells the worker to keep a milestone notebook at .sous-chef/progress.md; unexcluded, it would pollute the diff and trip the concurrent-edit check), then append a run marker to the notebook: ## fire <UTC ISO-8601> <$JOB basename>. Ticks read only below this marker - without it, a previous run's milestones would masquerade as this one's.