/superloopy-loop

name: superloopy-loop
description: Use Superloopy's lightweight strict-evidence loop for Codex tasks that need durable progress, criteria, and artifact-backed completion.
metadata:
  short-description: Lightweight strict-evidence loop harness

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.
• Full Loopy runs default to direct, concise, complete user-facing progress and final responses. Exact `say-it-straight off` / `직설 모드 끄기` and `say-it-straight on` / `직설 모드 켜기` controls apply only to the current incomplete loop; new loops reset this default to enabled.
• This output overlay changes wording only. It never silently rewrites supplied prose, task artifacts, code, documentation, comments, evidence, quotations, or user source text; direct artifact editing remains explicit-only. `i-have-adhd` still owns structure, and `humanize-korean` still owns Korean artifact rewriting.

Load on demand

These references hold the situational detail. Read the one a row names when its condition holds; the rules above and below apply to every run.

| Read | When | |---|---| | [CLI flow](references/cli-flow.md) | Running Superloopy commands beyond the loop engineer's `begin` → `guide` → `prove` → `check` → `finish` path: `create`, `capture`, manual `evidence`, `trace`, `report`, a blocked `check` repair plan, custom `review`/`checkpoint` gate workflows, or a cache-satisfied final proof. | | [Continuation engine](references/continuation.md) | The Stop hook re-prompted you ("Superloopy continuation"), a loop shown `blocked` or `paused` in `superloopy loop status`, a quota/usage limit, or scheduling an auto-resume. | | [Evidence audit](references/evidence-audit.md) | Running `superloopy loop audit`, dispatching `assayer`, or handling a failed, `inconclusive`, or `blocked` audit. | | [Crew](references/crew.md) | Before dispatching any subagent (solo light delegation or `loopy team`/crew): parent responsibilities, `handoff`/`fleet` bookkeeping, the self-contained dispatch contract, subagent lifecycle, and agent allocation. | | [Reassurance copy](references/reassurance-copy.md) | The reassurance-copy condition below applies. |

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>" --mode light --json`; do not create a second plan if one is active.
• Drive each step from `superloopy loop guide --json`, prove criteria with `superloopy loop prove -- <command>`, preflight with `superloopy loop check`, then finish with `superloopy loop finish --evidence "<summary>" --artifact .superloopy/evidence/gate.json --json`.
• The user types only `loopy <task>`. You run every Superloopy command and report progress as criteria proven and the next step.
• `loopy` with no task asks what to build; `loopy` mid-loop resumes from existing state. After a `loopy` prompt, the packaged Stop hook keeps this session going while criteria remain, until the user sends a plain prompt (`SUPERLOOPY_STOP_HOOK=on` drives every session, `off` disables it). If it reports a worker that stopped without proof, treat that worker's reply as unproven.

Execution discipline

The loop engineer directive carries three rules distilled from a component-level harness study (arXiv 2609.20804). For strong models, most avoidable cost is redundant verification, unchanged re-runs of a failing check, and many small re-patches.

• Prove each criterion once with the narrowest command that decides it, then move on. Do not re-run passing proof or broad suites between criteria; `loop finish` re-runs every passed command-backed criterion before it completes (trusted commands only; commandless proof gets an artifact-existence check). `loop check` validates artifacts and does not re-run anything.
• When a proof fails, its output is already in the capture artifact. Read the failing part (tail or search), then change the code or the proof command before proving again; if the criterion itself is wrong, ask the user to revise it with a `revise_criterion` steer. After 3 consecutive failures of one criterion with the same command, exit, and normalized output tail, `prove`, `capture`, `trace`, `check`, and `report` emit a `repeated-failing-proof` warning. Normalization ignores run-to-run noise (timestamps, durations, labeled PIDs and ports, UUIDs, hashes, temp paths, stack positions, numbers of 10+ digits such as epoch times) but keeps other numbers, so a changed assertion value or pass/fail count breaks the streak. Any other evidence for that criterion, including a pass, a manual `loop evidence` record, or a revised criterion, resets it. The warning is advisory and never blocks; with `SUPERLOOPY_STOP_H