# Loop Discovery

Use this workflow when the user asks to mine a codebase, coding-thread history,
or both for work that should become a loop.

## Inspect the evidence

1. Confirm the smallest discoverable scope from the request. Inspect the current
   repository when it is clearly in scope. Use available thread listing, search,
   and reading tools only for coding threads the user authorized. If thread
   history is unavailable, continue with codebase evidence and disclose the
   limitation.
2. In code, inspect the operational paths that reveal recurring work: scripts,
   CI and deployment configuration, maintenance commands, tests, contributor
   instructions, issue templates, runbooks, and repeated lifecycle patterns.
   Similar-looking functions alone are a refactoring signal, not proof of a
   loop.
3. In threads, identify completed actions and their outcomes. Group semantically
   equivalent work even when the wording differs. Count distinct occurrences,
   not repeated discussion of the same occurrence. Record a compact source
   handle such as a thread title or identifier and the action performed; do not
   copy secrets or unnecessary private content.
4. Corroborate thread claims against the repository or runtime when practical.
   Thread history can be stale, incomplete, or mistaken.

## Qualify and rank candidates

A repeated task is not automatically a good loop. Require the candidate to
follow the feedback-cycle and validation rules in `SKILL.md`, not merely to
appear multiple times in code or thread history.

A candidate is loop-shaped only when all of these are present or can be derived
from scoped evidence:

- a recurring event or state to observe;
- a next action that can change in response to fresh feedback;
- an observable check for whether the action helped;
- a bounded scope and a success, no-op, blocked, approval-required, or
  no-progress stop as appropriate.

Require at least two distinct occurrences before describing a thread-derived
task as repeated. A codebase pattern without run history may be reported as a
potential loop, but not as proven recurrent. Reject one-shot migrations,
straight-line checklists, vague goals, and tasks where another pass receives no
new evidence.

Rank qualified candidates by evidence of recurrence, time or failure cost,
quality of available feedback, reversibility, and safe authority. Do not invent
frequency, effort saved, owners, schedules, metrics, or permissions. Prefer the
smallest high-value loop over a broad loop that bundles unrelated work.

## Convert the best candidate

1. Search the live catalog using the candidate's outcome, trigger, action, and
   verification terms. Adapt a strong published match instead of duplicating
   it. If the catalog is unavailable, continue with an explicitly unpublished
   design and disclose that duplication could not be checked.
2. If several candidates are similarly strong or differ materially in
   authority, show a short ranked slate and ask the user which one to convert.
   Otherwise convert the strongest candidate directly.
3. Derive the trigger, fresh observation, bounded action, reproducible
   verification, record, and terminal behavior from the evidence. Apply every
   design rule in `SKILL.md`; do not weaken the standard because recurrence is
   well documented. Ask one short question only when a missing decision would
   materially change safety or success.
4. Run the mandatory crafted-loop preflight in `SKILL.md`. Repair material
   weaknesses before delivery without expanding authority or inventing missing
   details.
5. Return the compact evidence and the loop using the standard delivery format
   in `SKILL.md`. Label it as an unpublished design or adaptation. If no
   candidate qualifies, report a clean no-op and explain the missing feedback
   or recurrence evidence; do not manufacture a loop.