superloopy-loop

# superloopy-loop Use this skill when the user asks for Superloopy, loopywork, lpy, a loop harness, durable criteria, evidence-backed completion, strict-but-light task flow, or guided next actions. ## Contract - State lives in `.superloopy/`, or `.superloopy/sessions/<id>/` when `--session-id` is used. - Do not hand-edit `.superloopy/goals.json`; use the CLI. - A criterion can pass only after a real artifact exists under the active evidence root. - User steering must use `SUPERLOOPY_STEER` JSON; do not hand-edit `.superloopy/goals.json`. - Executor receipts should end with `SUPERLOOPY_EVIDENCE: <path-under-active-evidence-root>`. - Legacy `EVIDENCE_RECORDED` receipts remain accepted for compatibility. - Tests are useful evidence, but completion requires the Superloopy evidence artifact. - Use `superloopy loop prove` when an active goal needs command-backed evidence for its next unresolved criterion. - Keep the workflow lightweight unless the task genuinely needs heavier review. - A leading `loopy` keyword wakes the loop engineer: take the rest of the prompt as the brief, run the loop yourself, and report progress instead of asking the user to type Superloopy commands. - `loopywork`, `$lpy`, and `lpy` are lighter prompt triggers; they inject guidance but never mutate `.superloopy/` state by themselves. ## Loop engineer (`loopy` keyword) When the user opens a message with `loopy <task>`, act as the loop engineer: - Start once with `superloopy loop begin --brief "<task>" -...