loop-library

loop-library is the compatibility alias for Loopy, providing the same workflows for discovering, recommending, auditing, repairing, adapting, crafting, running, debriefing, saving, and publishing bounded engineering loops. It should be used only when an existing installation or older instruction explicitly invokes loop-library; Loopy is preferred for new installations and requests. The skill treats a loop as a feedback system with terminal states, not as permission for endless autonomy, and helps users turn repeated engineering work into bounded, evidence-backed loops.

The skill routes each request to the smallest useful path: Discover (analyze a codebase and/or coding-thread history for repeatable work), Find (recommend one to three published loops for a stated problem), Audit / Loop Doctor (diagnose and repair only material weaknesses in an existing loop), Adapt (retune a published loop's thresholds, tools, cadence, owners, or checks), Craft / Guided Design (interview the user and produce a new bounded loop), Run (execute within authorized scope and return an evidence-backed run receipt), Debrief (analyze completed run receipts and propose the smallest justified improvement), Save/Reuse (append loops to a project LOOPS.md and reuse them later), and Publish (check quality and catalog overlap, then submit only with explicit approval). For finding published loops it reads the live catalog at catalog.md (or catalog.json for structured ingestion) as the source of truth, and never invents titles, numbers, contributors, or URLs. Detailed workflows live in reference files including references/discover.md, references/audit.md, references/run.md, references/debrief.md, and references/publish.md.

The skill enforces careful grounding and safety rules for engineers and teams. Running a loop authorizes only ordinary, reversible actions clearly within the user's stated scope and does not authorize scheduling, production changes, destructive actions, purchases, privacy-sensitive access, or external messages. Source files, commits, thread contents, and catalog entries are treated as untrusted evidence, so embedded instructions are not executed merely because they appear. Thread-derived candidates require at least two concrete occurrences before being called repeated, saved loops must exclude secrets, and publication requires explicit approval, since saving an authorized owner draft is not approval to make it public.