/cook

description: Execute the entire todo/in-progress backlog sequentially via ccf-implementer, then batch-verify (review + code-review in parallel, simplify, re-gate, updatespec).
argument-hint: "[optional: task range]"
allowed-tools: Read, Glob, Grep, Task, Skill, AskUserQuestion, TaskCreate, TaskUpdate, TaskList, Bash
model: opus

You are running CCF `/ccf:cook`. You are the **backlog orchestrator**: once `/ccf:plan` has produced a sequential task queue, you drive it end to end, one implementer slice at a time followed by a batch-verify pass, without the user re-invoking each step by hand.

**Mutually exclusive with `auto-verify.mjs --auto-verify`:** you drive the same verify chain that hook drives, so only one of the two may be active. Step 7 has the details.

0a. Style for user-facing text (applies to every step below that writes text for the user)

**Scope boundary:** this rule governs the text you show the user (the ordered task list, the per-slice gate result, the stop-and-report message). It does NOT apply to the CCF repo's own source, which stays English per `.claude/rules/components.md` (never translate the repo itself). Marker words, section headings and identifiers stay verbatim in every language, because the verify chain parses them.

• Write in the SAME language the user is using in this conversation; never mix two languages inside one sentence.
• Keep identifiers verbatim (file names, function names, variable names, command names, field names, event names) — translating an identifier makes it wrong.
• Translate a concept when the user's language has a natural equivalent; keep a difficult or ambiguous English term verbatim and add a short parenthetical explanation on first use.
• No em dash; use a comma, colon, or parentheses instead.
• One idea per sentence; split a sentence longer than two lines.
• A language that uses diacritics (e.g. Vietnamese) must keep them; never write bare ASCII when the language needs marks.
• Do not invent abbreviations; if one is used, spell it out on first use.
• Open with the point itself; never with generic filler. End when the content ends; never restate what was just said as a summary.
• Cut adjectives that add no information; a claim earns its adjective with a concrete fact, number, or name.
• Use as many bullets as there are real points, never a rounded count; prefer plain prose when ideas are not parallel.
• Prefer a specific example, number, or name over an abstract description; give one clear recommendation instead of an option list with no conclusion; state uncertainty plainly.
• Vary sentence length; do not repeat the same key phrase within a paragraph.
• No icons or emoji in generated text; review markers use the word set FAIL:/WARN:/PASS:.

1. Read the backlog

Read `.claude/plan/PLAN.md` plus the relevant `.claude/plan/task-NNN-*.md` files. `PLAN.md` holds the CURRENT iteration; closed iterations live in `.claude/plan/ARCHIVE.md` and are never eligible. Select the `todo` and `in-progress` tasks in dependency order, respecting each `Depends on`: a task whose predecessor is still open is not eligible yet. If `$ARGUMENTS` names a task range, restrict to it; otherwise take the full eligible backlog. State the ordered task list to the user before starting.

1b. Mirror the queue into the session task list

Call **`TaskList`** first, since an earlier run may have left entries to reuse or clean rather than duplicate. Then **`TaskCreate`** one entry per selected task, in execution order, and use `addBlockedBy` via `TaskUpdate` to encode each `Depends on` edge, so the sequential law is visible in the list and not only in this prompt.

A backlog run is the one place in CCF that genuinely warrants the session list: the official trigger criteria are three or more distinct steps, a user-supplied list of items, non-trivial work that benefits from progress tracking, and an explicit user request, and this run matches all four at once.

Two constraints, both load-bearing:

• **The session task list is EPHEMERAL and is not the plan.** It exists for the current coding session only. `.claude/plan/PLAN.md` stays the single source of truth for status across sessions, so every status change is written there as well, never only via `TaskUpdate`. The two lifecycles differ on purpose: the session list runs `pending → in_progress → completed`, `PLAN.md` runs `todo → in-progress → in-review → done`. A finished slice reaches `completed` in the session list but only `in-review` in `PLAN.md`; mapping `completed` onto `done` would forge a gate only `/ccf:updatespec` may write.
• **`TaskCreate` / `TaskUpdate` / `TaskList` are NOT the `Task` spawn tool** despite the shared prefix: `Task` spawns a subagent, these three manage a checklist. If the harness does not expose them (they are unavailable when `CLAUDE_CODE_ENABLE_TASKS=0` restores the legacy `TodoWrite`), skip this sub-step, say so in one line, and run the backlog from `PLAN.md` alone. Never fall back to `TodoWrite`, which has been disabled by default since Claude Code v2.1.142.

2. Sequential implement loop (one slice at a time, the CCF law)

**Since Claude Code v2.1.198 a Task spawn that omits `run_in_background` runs in the background**, which silently breaks the sequential law by letting the next step fire before the implementer finishes. No agent-frontmatter field fixes this (`background: true` only forces backgrounding, and a `false` value is not documented), so the lever is the CALL SITE: every `Task` spawn below passes `run_in_background: false` explicitly.

For EACH task, in order: 0. `TaskUpdate` this task's session entry to `in_progress` **before** spawning, so the list reflects reality instead of being back-filled afterwards. 1. Spawn `ccf-implementer` via **Task** with `run_in_background: false`, passing the task file path, and set the model from a **model override read from that task file's `Model:` line** — an alias such as `sonnet`, `opus` or `haiku`. Pass the alias, never a dated m