Use when main results pass result-to-claim (claim_supported=yes or partial) and ablation studies are needed for paper submission.

Ablation Planner Systematically design ablation studies that answer the questions reviewers will ask. Codex leads the design (reviewer perspective), CC reviews feasibility and implements. Context: $ARGUMENTS When to Use Main results pass /result to claim with claim supported = yes or partial User explicitly requests ablation planning /auto review loop reviewer identifies missing ablations Workflow Step 1: Prepare Context CC reads available project files to build the full picture: Method description and components (from idea stage/docs/research contract.md , legacy docs/research contract.md , or project CLAUDE.md) Current experiment results (from EXPERIMENT LOG.md, EXPERIMENT TRACKER.md, or W&B) Confirmed and intended claims (from result to claim output or project notes) Available compute resources (from CLAUDE.md server config, if present) Step 2: Codex Designs Ablations Step 3: Parse Ablation Plan Normalize Codex response into structured format: Step 4: CC Reviews Feasibility Before running anything, CC checks: Compute budget: can we afford all ablations with available GPUs? Code changes: which ablations need code modifications vs config only changes? Dependencies: which ablations can run in parallel? Cuts: if budget is tight, propose removing lower priority ablations and ask Codex to confirm Step 5: Implement and Run 1. Create configs/scripts for each ablation (config only changes first) 2. Smoke test each ablation before full run 3. Run in suggested order, using descriptive names (e.g., ablation no module X ) 4. Track results in EXPERIMENT LOG.md 5. After all ablations complete → update findings.md with insights Rules Codex leads the design. CC does not pre filter or bias the ablation list before Codex sees it. Codex thinks like a reviewer; CC thinks like an engineer. Every ablation must have a clear what it tests and expected if component matters . No "just try it" experiments. Config only ablations take priority over those needing code changes (faster, less error prone). If total compute exceeds budget, CC proposes cuts and asks Codex to re prioritize — don't silently drop ablations. Component ablations (remove/replace) take priority over hyperparameter sweeps. Do not generate ablations for components identical to the baseline (no op ablations). Record all ablation results in EXPERIMENT LOG.md, including negative results (component removal had no effect = important finding).

ablation-planner