goal-looplisted

# Goal Loop A loop that only checks the criteria it shows the implementer will, eventually, produce an implementer that's very good at passing exactly those criteria and nothing more — memorizing the test, not solving the problem. This skill treats "loop until it works" as gradient descent: forward → loss → gradient → update, with a held-out set the implementer never sees, so the final verdict can tell the difference between "solved" and "gamed the visible checks." ## When to use this - "Keep iterating until this passes", "loop until the goal is actually met." - Bug fixes, feature completion, or refactors with fuzzy or compositional acceptance criteria — where a narrow visible test could pass without the real problem being solved. - **Skip it** for one-shot deterministic tasks with no real risk of overfitting the checks (a config change, a straightforward CRUD endpoint with a spec that's already unambiguous) — the loop machinery is overhead you don't need there. ## Instructions ### 1. Set up the goal contract before looping - State the goal as something checkable, not a vibe: "the cache handles concurrent writes without corruption," not "make the cache better." - Split evidence into two sets: - **Visible checks** — what the implementer is told to satisfy this iteration (a specific failing test, a described scenario). This is the implementer's target. - **Held-out checks** — compositional or edge-case scenarios written separately, covering what the