/cook

description: Execute the entire todo/in-progress backlog sequentially in this session, then run /ccf:check once and /ccf: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, implementing each task directly in this session, one at a time, then run a single verify step, without the user re-invoking each task by hand.

**Mutually exclusive with `auto-verify.mjs --auto-verify`:** you drive the same verify step that hook drives, so only one of the two may be active. Step 6 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 step 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, directly in this session (one slice at a time, the CCF law)

Implement each task **yourself, in this same session** — do not spawn a `Task`/subagent to write the code. A spawned coding subagent means waiting on a separate context with its own setup and its own result to read back, which is strictly slower than writing the code directly with the plan and codebase already loaded in this conversation; that is why CCF reserves its subagents for read-only work (codebase discovery, best-practice research, spec review) and implements everything else here.

For EACH task, in order: 0. `TaskUpdate` this task's session entry to `in_progress` **before** starting, so the list reflects reality instead of being back-filled afterwards. 1. Read the task file: goal, spec refs, acceptance criteria, files to touch, the test to write first. When it needs a DB schema or library documentation, use whatever MCP the project provide