work-loop

# Skill: work-loop This is the project's standard inner loop for non-trivial work. It exists because LLM self-assessment is unreliable: agents declare victory when they *feel* done, not when objective gates pass. This skill replaces "feel" with verifiable termination criteria. > **Vocabulary.** "Surface" throughout this skill means: stop the > current loop, emit a short description of the situation in your final > message (what happened, what you tried, what state things are in), > and wait for human direction. It is the project's house verb for > "stop and report." Do not retry, do not redispatch, do not silently > reset. (Reviewers also "surface" findings in the descriptive sense > — "raised" — when they return their report; context disambiguates.) ## When this skill applies - Implementing a spec from `docs/specs/`. - Bug fixes that touch more than one file — including security patches and incident hot-fixes. - Refactors. - Migrations, framework or dependency upgrades, schema or API changes. - Performance work, or infrastructure / build-system changes beyond a single config tweak. - Reverting and re-doing a previous change. - Any task where you'd otherwise be tempted to "just go". For genuine one-line edits (typo, config tweak), skip the loop — the overhead isn't worth it. That triviality test decides *whether* to run the loop; once you're in it, **risk** (not file count) decides *which mode* runs — see [Modes: light and full](#modes-light-and-full) below. ## The loop...