ce-optimize

Runs metric-driven, iterative optimization loops: define a measurable goal, build measurement scaffolding, run parallel experiments, score each against hard gates or LLM-as-judge rubrics, keep the improvements, and converge on the best solution. Use it to optimize outcomes such as clustering quality, search relevance, build performance, or prompt quality - anything measurable that benefits from systematic experimentation. Input is either a path to an optimization spec YAML or a free-text description of the goal; if no input is given, it asks what to optimize. When it needs to ask the user a question it uses the platform's blocking question tool, falling back to numbered chat options only when no such tool exists.

The skill is organized into phases. Phase 0 determines whether the input is a spec file or a goal description, then loads and validates the spec against a schema - checking required fields, a lowercase-kebab-case name safe for git refs and worktree paths, a metric type of hard or judge (with a judge section containing rubric and scoring when applicable), at least one degenerate gate, a non-empty measurement command, populated mutable and immutable scope, valid gate operators, and an execution max_concurrent of at least one and no more than six on the worktree backend. It references separate schema files for the spec, the experiment log, and an example usage guide, and recommends conservative first runs - serial execution, capped iterations and hours, hard specs when the metric is cheap and objective, and small sample, batch, and cost limits for judge mode.

Persistence discipline is central. The experiment log on disk is treated as the single source of truth because the skill runs for hours and context windows compact or sessions crash. Core rules require writing each experiment result to disk immediately after measurement and verifying the write by reading it back, re-reading state from disk at every phase boundary and decision, keeping the experiment log append-only during the experiment phase, writing per-experiment result.yaml markers for crash recovery, and never presenting results to the user before they are written and verified. Mandatory disk checkpoints (CP-0 through CP-5) map each milestone - spec saved, baseline recorded, hypothesis backlog, each experiment result, batch summary, and final summary - to specific files under a .context/compound-engineering/ce-optimize/<spec-name>/ directory, and a defined resume procedure recovers measured-but-unlogged experiments.