Claude Code Kit
Recipes

Loop Recipes

Named /loop workflows with explicit exit conditions and anti-gaming guardrails — babysit PRs, hunt a flaky test, bump dependencies safely.

/loop is the bundled skill that re-runs a prompt on a schedule inside the open session/loop 15m <prompt> on a fixed interval, /loop <prompt> to let Claude pace itself, or a bare /loop for the built-in maintenance prompt. It pairs with the kit's floor: session-start re-fires every iteration (so the loop can't drift off-plan), the PreToolUse deny hooks and permissions.deny list still hold, and stop-gate still gates completion each turn.

What turns a raw /loop into a recipe is three things the prompt has to carry:

  1. a trigger — interval or self-paced;
  2. an explicit exit condition + iteration cap, so the loop converges instead of churning;
  3. an anti-gaming guardrail, so a loop under pressure to finish can't "succeed" by lowering the bar.

The guardrail every loop recipe includes. An unattended loop runs under standing pressure to reach its exit condition, and the failure mode is a model that succeeds by cheating rather than by finishing the work. Put these lines in every kickoff prompt:

  • Don't touch the gate. Never weaken, skip, xfail, or delete the failing test; never relax the check declared in .claude/commands.json; never set SKIP_QUALITY_GATE=1 to walk past a failure your own change caused.
  • No fabricated success. Don't declare the exit condition met unless the real check actually passes.
  • Stuck is a stop, not a shortcut. If the goal isn't genuinely met after the iteration cap — or you're going in circles — halt and report the blocker instead of forcing an exit.

This mirrors the kit's own guidance in agent_docs/auto-mode.mdDon't let the loop game the gate.

Recipe: Babysit PRs to green

Keep an eye on open PRs and tend their CI until they're mergeable — without you refreshing the tab.

  • Trigger: interval — /loop 15m <prompt>
  • Exit condition: every target PR is merged or explicitly reported as blocked
  • Iteration cap: ~20 (about 5 hours at 15-minute ticks)
/loop 15m Check the open PRs I own on this repo. For each: if CI is green and it's
mergeable, say so and (only if I've pre-approved merging) merge it; if CI is red,
read the failing job, and if the failure is in my change, fix it on the branch and
push; if the failure is unrelated infra, note that and move on. Stop when every PR
is merged or blocked-and-reported, or after 20 iterations — whichever comes first.
Guardrail: never edit or skip a failing check to make CI pass; if you can't make a
PR green honestly, report why and leave it. Do not merge anything I haven't approved.

Watching CI this way spends GitHub API budget on every tick — a 15-minute interval is deliberate. Don't drop it to seconds.

Recipe: Hunt a flaky test

Reproduce an intermittent failure by re-running the suite until it flakes — then capture it instead of shrugging.

  • Trigger: self-paced — /loop <prompt>
  • Exit condition: the flake reproduced (capture it) or N consecutive green runs (declare it stable)
  • Iteration cap: N (e.g. 20)
/loop Run the test suite. If it passes, run it again. Keep going until either a run
fails or you've seen 20 consecutive green runs. On the first failure, stop and save
the exact command, the seed/ordering, and the full failing output to a note — that
captured trigger is the bug. If you reach 20 green runs, stop and report the suite
as stable over 20 runs. Guardrail: don't quarantine, retry, or delete the test to
make the run "pass" — the goal is to catch the flake, not to hide it.

The captured trigger is what makes the fix verifiable later: re-run that exact input after a fix and require it to pass (the kit's re-attack rung, agent_docs/debugging.mdVerify).

Recipe: Bump dependencies, one verified at a time

Work through a list of dependency bumps, gating each on the verification suite and reverting the ones that regress — instead of a big-bang upgrade that fails opaquely.

  • Trigger: self-paced — /loop <prompt>
  • Exit condition: every planned bump is either merged-green or reverted-and-reported
  • Iteration cap: one per dependency on the list
/loop Take the next dependency on my bump list. Bump only that one. Run the full
verification gate (typecheck, lint, tests, build). If it's green, commit the bump on
its own commit and move to the next. If it's red, revert the bump, record why it
failed, and move to the next — don't fix forward on a red tree. Stop when the list is
empty. Guardrail: never loosen a version constraint, skip a test, or edit the gate to
force a bump green; a bump that can't pass the real suite gets reverted and reported.

Reverting on regression rather than fixing forward keeps every other bump able to build on a green tree — the same discipline as the worktree merge-gate (agent_docs/worktrees.md).

Making a recipe the session default

A loop.md file (.claude/loop.md, falling back to ~/.claude/loop.md) replaces the built-in prompt for a bare /loop. It's inherently project-specific — "keep release/next green", "drain the migration backlog" — so the kit ships none. If you write one, keep the done-condition in one line so the loop converges, and phrase it so it can only be satisfied honestly ("if the suite is green and the feature actually runs, say so and stop" — not "stop when the errors go away", which a deleted test also satisfies).

These recipes target the kit's own /loop skill and its hooks. They're kickoff prompts, not a separate config format — copy one, adjust the specifics, and run it.