CDD Master Chef

Use this skill for a clean OpenClaw-native autonomous workflow.

References:

• {baseDir}/MASTER-CHEF-RUNBOOK.md
• {baseDir}/MASTER-CHEF-TEST-HARNESS.md

Operating contract:

1. Use this skill for non-trivial development where Master Chef ownership is wanted.
   • Preferred path: an existing repo that is already CDD-ready with AGENTS.md, README.md, and TODO.md or TODO-*.md
   • Allowed bootstrap path: a new or adoptable project folder that should be brought into the CDD contract first via cdd-init-project
2. The main OpenClaw session is always Master Chef.
3. The Builder runs as an OpenClaw subagent, not ACP.
4. There is no watchdog cron or separate supervising agent; Master Chef checks Builder health directly in the main session when active.
5. State is durable and repo-local:
   • .cdd-runtime/master-chef/run.json
   • .cdd-runtime/master-chef/run.lock.json
   • .cdd-runtime/master-chef/master-chef.jsonl
   • .cdd-runtime/master-chef/builder.jsonl
6. Before kickoff, resolve the Run config:
   • if the current prompt includes a Run config block, use that
   • otherwise, if ~/.openclaw/config/master-chef/default-run-config.yaml exists, read it, surface the resolved config back to the human, and use it as the starting Run config for that run
   • the resolved Run config must contain master_model, master_thinking, builder_model, and builder_thinking
   • treat the resolved Run config as the only per-run source of truth; do not infer model settings from repo docs, USER.md, memory, previous run.json, or earlier runs
   • keep shared docs and commits free of local-only operator overrides
7. Before autonomous work starts, inspect:
   • current git status and branch
   • upstream branch when present
   • active TODO file when present
   • last completed step when present
   • next runnable TODO step when present
   • whether the repo first needs cdd-init-project before the normal TODO loop can start
8. Master Chef chooses the internal cdd-* routing model.
   • For a new or not-yet-CDD project, propose and normally start with cdd-init-project in the main session before any autonomous TODO execution.
   • Builder default: cdd-implement-todo for the next runnable TODO step.
   • Builder optional: cdd-index when Master Chef explicitly wants an index refresh as the delegated action.
   • Master Chef direct: cdd-init-project, cdd-plan, and cdd-refactor stay in the main session rather than being delegated to Builder.
   • Excluded from the normal flow: cdd-audit-and-implement, unless the process is explicitly adapted for its mixed role.
   • Treat the installed cdd-* skills as internal OpenClaw workflows, not user slash commands.
9. Before implementation starts, present one kickoff approval that covers:
   • proposed next action
   • the approved Run config
   • runtime initialization under .cdd-runtime/master-chef/
   • run lease creation
10. Spawn the Builder as a subagent with the exact builder_model and builder_thinking from the approved Run config, for exactly one approved delegated action, and tell it which internal cdd-* skill path to use.
11. Use one-step Builder runs only.

• One Builder run equals one approved delegated action.
• After a step passes, blocks, or is abandoned as stale, Master Chef must re-inspect repo state and spawn a fresh Builder for the next delegated action, normally via cdd-implement-todo.
• Do not treat Builder session resurrection or multi-step continuation as a normal path.

12. Both Master Chef and Builder must append JSONL logs with concrete evidence for step start, validation, blockers, completion, and reporting.
13. Use hard_gate and soft_signal validation classes:

• hard_gate: failing tests, lint, typecheck, migrations, pushability, or repo-defined must-pass checks
• soft_signal: discovery greps, file-presence scans, or other non-blocking heuristics

14. Use working-tree-aware discovery checks when unstaged files matter:

• rg --files
• git ls-files --cached --others --exclude-standard

15. For each passed step:

• ensure the Builder updated only the selected step in TODO*.md
• run Master Chef QA
• approve step-level UAT with explicit evidence
• commit
• push
• send the full result, evidence, and decision trail in the current Master Chef session

16. Reporting is session-native.

• The current Master Chef session is the control plane and reporting surface for this shared skill.
• Report lifecycle events such as START, STEP_PASS, STEP_BLOCKED, RUN_COMPLETE, and explicit stops in-session.
• Keep shared skill docs and runtime state free of extra route config.

17. When Master Chef performs a Builder check in the main session, it may:

• inspect runtime files and logs
• inspect Builder health
• replace the Builder with a fresh subagent run if stale
• report blockers or completion

18. Direct Builder checks must not create a second control loop. Recovery stays in the main session, using fresh Builder replacement rather than normal session resurrection.
19. Healthy Builder checks may stay quiet, but they do not cancel in-session lifecycle reporting for events such as START, STEP_PASS, STEP_BLOCKED, RUN_COMPLETE, or an explicit stop.
20. If repeated Builder replacements fail without progress, stop quickly and report STEP_BLOCKED or DEADLOCK_STOPPED rather than limping on.

Canonical run.json fields:

• run_id
• repo
• master_model
• master_thinking
• builder_model
• builder_thinking
• builder_runtime
• master_session_key
• builder_session_key
• active_todo_path
• active_step
• phase
• branch
• upstream
• pre_step_head_sha
• last_pass_head_sha
• last_progress_at_utc
• last_master_log_at_utc
• last_builder_log_at_utc
• builder_restart_count
• dispute_loop_count
• current_blocker

Report events:

• START
• BUILDER_RESTARTED
• STEP_PASS
• STEP_BLOCKED
• BLOCKER_CLEARED
• RUN_STOPPED
• DEADLOCK_STOPPED
• RUN_COMPLETE

Reporting surface:

• the current Master Chef session carries full operational detail and lifecycle reporting