Improve Loop

Enrich the user's loosely-specified recurring or open-ended task into a well-formed loop spec ready for Claude Code's /loop or /schedule. The governing bias, from the rule pack itself: prefer a bounded workflow over a fully autonomous loop unless the task is genuinely open-ended — and a fully autonomous loop is NEVER emitted as "ready" without its hard gates.

Pipeline

Run these four steps in order.

1. Load the rule pack

Read ${CLAUDE_PLUGIN_ROOT}/rules/loop-rules.json (equivalently ../../rules/loop-rules.json from this skill's base directory). Every enrichment decision traces to a rule in that pack; the pack maps each rule to the research finding(s) behind it via finding_refs, resolvable in ${CLAUDE_PLUGIN_ROOT}/rules/findings-index.json.

2. Confirm the artifact kind

Invoking this skill is the explicit classification: the draft is a loop. If it clearly reads as a one-shot prompt or a single-end-state goal with no recurrence, surface that mismatch as the first clarifying question. Never silently convert it. In default single-turn mode, honor the explicit invocation: enrich the draft as a loop anyway, with the mismatch question folded in as the first line of the returned spec (naming the kind it appears to be and offering the matching sibling skill). In --interactive mode, ask the mismatch question first, before any other gap.

3. Detect gaps

Run the draft against every rule's gap_check. Produce one internal gap list of {rule_id, finding_refs, description} records — carrying every finding ref the rule cites — feeding both elicitation modes.

4. Elicit and synthesize

Default (single-turn): fold each gap into the returned loop spec as a concise clarifying question. Nothing invented, no placeholder tokens.

--interactive (only when the argument includes the flag): render the same gap list as AskUserQuestion calls — at most 4 questions per call, batched until every gap is resolved — then synthesize with the answers folded in. If the user declines or skips a question, fall back to folding that gap into the spec as a clarifying question — never invent an answer.

What may be defaulted vs what must be asked: loop mechanics (interval, expiry, cadence) may be defaulted from the documented /loop bounds and stated as defaults; facts about the user's task (repos, thresholds, environments, scopes) are never defaulted — fold those as clarifying questions.

Definition — fully autonomous: a loop is fully autonomous when any iteration takes an action with side effects (writes, pushes, deploys, messages) without a human in that iteration. Read-only observe-and-report loops are not fully autonomous and need only the completion condition and bound.

Synthesize by applying every applicable rule:

• If the task decomposes into a bounded workflow (prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer), emit that shape and say why, instead of an autonomous loop.
• A fully autonomous loop MUST carry all three hard gates before it is emitted as ready: sandboxing, a max-iteration cap, and a human checkpoint. Missing any gate, the emitted spec states the loop is NOT ready and folds the gate in as a clarifying question or explicit requirement.
• Where the loop acts through tools, specify ReAct-style interleaved reasoning-then-acting, not plan-once-then-execute.
• Use Claude Code's own documented loop bounds — 1 minute-3 day interval, idle-only firing with no catch-up, deterministic jitter, 7-day auto-expiration — never invented semantics.
• An explicit completion condition and a bound are mandatory, never optional.

Output format

Return ONLY the improved loop spec inside a code block. Nothing else. Exceptions: when the user explicitly asks for the rationale or grounding behind changes, append the per-change citations (rule id → finding @id) after the code block; in --interactive mode, AskUserQuestion turns precede the single code block.

[improved loop spec here]

Example

Improved: "/loop 10m — For each open PR authored by me in this repo: check CI status, new review comments, and unresolved review threads. Report only deltas since the previous iteration (new failures, new comments, newly resolved threads); stay silent when nothing changed. Completion condition: stop when zero authored PRs remain open, or after 3 days, whichever comes first (loop auto-expires at 7 days regardless). Clarify first: should this cover one repository or all repositories I have open PRs in?" </example>

Critical rules

• Return ONLY the code block with the improved loop spec — no analysis, no explanations, no "Changes Made".
• The improved spec must be COMPLETE and READY TO USE immediately with /loop or /schedule, including any clarifying questions needed to proceed — EXCEPT a fully autonomous loop missing any hard gate, which must instead state it is NOT ready and carry each missing gate as an explicit requirement or clarifying question. Never invent gate values to satisfy readiness.
• NEVER use placeholders like [REPO], [INTERVAL], [THRESHOLD]; NEVER create templates. If information is missing, fold a concise clarifying question into the spec; do not invent details.
• NEVER emit a fully autonomous loop as ready without all three hard gates — sandboxing, a max-iteration cap, and a human checkpoint — plus the explicit completion condition and bound that every loop requires (autonomous or not). Hard gates, not style preferences.
• Preserve the original intent.
• When the user asks why a change was made, cite the specific rule id and its finding_refs — resolved via rules/findings-index.json — not a restated heuristic.