simple-experiment-looplisted

# Simple Experiment Loop A zero-admin skill for driving a **tight** inner loop. Use this for deterministic developer tasks where success is defined entirely by a terminal command. If your success signal is subjective (e.g. aesthetic choices, generative art), convert it to objective gates first. A stochastic judge can go green by luck, oscillate forever, and invites reward-hacking where the loop optimizes for the judge's idiosyncrasies. ## Designing your Feedback Command The loop is only as good as the command. - **Multi-sample, not single-sample:** Judging one artifact chases noise; use fixed hold-out cases. - **Named faults, not a scalar:** `seed[0] primary_pct=3 (want 6..24)` maps onto a parameter; "7/10" is unactionable. - **Report every violation, not just the first:** Seeing all faults at once reveals collateral damage from your last mutation, and stops the loop from fixing them one slow round at a time. - **Gates you cannot tune to pass.** ## 1. Baseline Before changing any code, establish the **red** state. 1. Identify the **Target** (the specific file or files to be modified) and the **Feedback Command** (the terminal command that evaluates success, e.g., `npm test`, `pytest`, `cargo build`). Ask the user if these are not obvious; when running unattended, stop and report ambiguity rather than guessing. Freeze the Target before baseline. If no Feedback Command exists yet, **author it before establishing the baseline.** Writing the gate is setup, not part of th