cook

# cook ## Purpose The primary orchestrator for feature implementation. Coordinates the entire L2 mesh in a phased TDD workflow. Handles 70% of all user requests — any task that modifies source code routes through cook. <HARD-GATE> Before starting ANY implementation: 1. You MUST understand the codebase first (Phase 1) 2. You MUST have a plan before writing code (Phase 2) 3. You MUST write failing tests before implementation (Phase 3) — unless explicitly skipped This applies to EVERY feature regardless of perceived simplicity. </HARD-GATE> ## Workflow Chains (Predefined) Cook supports predefined workflow chains for common task types. Use these as shortcuts instead of manually determining phases: ``` /rune cook feature → Full TDD pipeline (all phases) /rune cook bugfix → Diagnose → fix → verify (Phase 1 → 4 → 6 → 7) /rune cook refactor → Understand → plan → implement → quality (Phase 1 → 2 → 4 → 5 → 6 → 7) /rune cook security → Full pipeline + sentinel@opus + sast (all phases, security-escalated) /rune cook hotfix → Production Hotfix Protocol: contain → fix → verify → deploy → watchdog → postmortem (see below) /rune cook nano → Trivial: do → verify → done (no phases, ≤3 steps) /rune cook --template <name> → Load pre-built workflow template from installed Pro/Business packs ``` ### Production Hotfix Protocol When `hotfix` chain is active AND triggered from a live incident (not a dev-time fix), follow the full orchestrated chain — not just fix → verify...