Cook — Full Implementation Pipeline

End-to-end implementation following the 7-phase workflow. TDD is opt-in via --tdd.

Usage

/cook <natural language task OR plan path>
/cook "Add user auth" --fast
/cook "Build payment processor" --tdd       # Strict TDD enforced
/cook tasks/plans/260329-feature/plan.md --auto

Flags: --interactive (default) | --fast | --parallel | --auto | --no-test | --tdd | --verify | --strict | --no-strict

Modifier flags (layer on any mode): --verify [LIGHT] (light browser/artifact check) | --strict [HEAVY] (full evaluator pass) | --no-strict (suppress auto-strict)

Concrete cost depends on the inner harness, model tier, and target surface; treat [LIGHT] vs [HEAVY] as relative ordering only.

--verify is advisory (does not block ship). --strict is a hard gate (FAIL blocks ship and routes back to Phase 3).

TDD mode (--tdd flag)

When --tdd is detected in the invocation, the cook skill MUST write on to .claude/session-state/tdd-mode via a Bash tool call BEFORE any other workflow step:

mkdir -p .claude/session-state && echo on > .claude/session-state/tdd-mode

This sentinel file is read by pre-implement.sh, tdd-detect.sh, and downstream agents to detect TDD mode. Without --tdd, the sentinel is absent and the workflow runs in default mode (Phase 2 optional, no RED-phase gate).

MEOWKIT_TDD=1 env var (set in CI / shell rc) is the highest-precedence opt-in and overrides the sentinel.

When loading an existing plan, scan plan.md and phase files for tdd: true, ## Tests Before, or ## Regression Gate. If any are present but this invocation lacks --tdd and MEOWKIT_TDD is not enabled, warn:

Plan contains TDD sections but cook is not in TDD mode. Re-run with --tdd to enforce RED-first execution, or continue in default mode with TDD guidance only.

HARD GATE

Do NOT write implementation code until a plan exists and Gate 1 is approved. In TDD mode (--tdd / MEOWKIT_TDD=1): do NOT skip Test RED phase — write failing tests BEFORE implementation. In default mode: Phase 2 is optional; the developer may implement directly per the approved plan. Exception: --fast mode skips research but still requires plan + (in TDD mode) TDD-flavored tests. User override: If user explicitly says "just code it" or "skip planning", respect their instruction.

Anti-Rationalization

Generic implementation-phase rationalizations live in .claude/rules/anti-rationalization.md — read before any non-trivial implementation step. Cook-specific addition (TDD mode):

Before starting work, read references/failure-catalog.md for common implementation failure modes (cross-linked to ## Gotchas below).

Smart Intent Detection

See references/intent-detection.md for full detection logic.

Green-field product build (new kanban app, full SaaS from scratch, multi-sprint autonomous build)? Use mk:autobuild instead. Cook handles single features, fixes, and refactors; harness owns the generator↔evaluator loop and adaptive scaffolding density.

Process Flow (Authoritative)

flowchart TD
    A[Phase 0: Orient] --> B{Has plan?}
    B -->|Yes| D[Load Plan]
    B -->|No| SP[Present scout summary to user]
    SP --> C[Phase 1: Research + Plan]
    C --> RQ{5 dims captured?}
    RQ -->|No| C
    RQ -->|Yes| G1[GATE 1: Human Approval]
    G1 -->|approved| D
    G1 -->|rejected| C
    D --> E[Phase 2: Test - RED if --tdd, optional otherwise]
    E --> F[Phase 3: Build GREEN]
    F --> S[mk:simplify — MANDATORY]
    S --> V[mk:verify — MANDATORY]
    V --> G2[Phase 4: Review — GATE 2]
    G2 -->|approved| BV{--verify or --strict?}
    BV -->|"--verify"| P45A["Phase 4.5 --verify advisory"]
    BV -->|"--strict"| P45B["Phase 4.5 --strict blocking"]
    BV -->|neither| H[Phase 5: Ship]
    P45A --> H
    P45B --> BG{evaluator FAIL?}
    BG -->|no| H
    BG -->|yes| F
    G2 -->|rejected| F
    H --> I[Phase 6: Reflect]

This diagram is authoritative. If prose conflicts, follow the diagram.

Scout-First Contract (Phase 0)

Before any clarifying question or plan generation, present a 3–6 bullet codebase-context summary to the user:

1. Project type / language / framework
2. Existing modules/files relevant to the task
3. Current patterns/conventions for similar features
4. In-flight plans (tasks/plans/) or docs (docs/) covering this area
5. Public APIs / schemas / contracts the task could affect

Skip when input is a plan.md / phase-*.md path — the plan already encodes scout output.

In --fast mode the summary is abbreviated (1–3 bullets) but still presented; "skip research" reduces external research depth, not codebase-context handoff to the user.

Exact-Requirements Contract (Phase 1)

mk:plan-creator MUST be able to answer all 5 dimensions in concrete sentences before returning a plan:

1. Expected output — concrete artifact(s) the user will see (paths, behavior, endpoint, CLI flags)
2. Acceptance criteria — specific inputs → outputs / edge cases
3. Scope boundary — what is explicitly OUT of scope this round
4. Non-negotiable constraints — stack, file locations, naming, compat, deadlines, performance
5. Touchpoints — which existing files (from scout) will be modified / which contracts must stay stable

Every clarifying-question option MUST cite scout findings (e.g., file paths). Vague abstract options are a failure mode — see references/failure-catalog.md.

Skip when input is a plan.md / phase-*.md path (plan encodes the 5 dimensions).

Workflow Modes

Gate 1 routing, parallelism, and full per-phase progression live in references/intent-detection.md (canonical Mode Behaviors table).

Gate 2: human approval mandatory in all modes — see .claude/rules/gate-rules.md for the full contract. If the reviewer surfaces a regression / side effect / broken workflow, follow the Regression Recovery Options pattern in references/review-cycle.md rather than silently patching.

Req