agentsclimarketplace

Loop engineer

Skill willianbs/skills/loop-engineer

Runs recurring agent loops: fixed or dynamic intervals, CI/PR babysitting, and re-invoking prompts/skills until stop criteria. Use for watch-until-done work. Emits LOOP_PLAN / LOOP_STATUS. Never starts unbounded loops without stop conditions or spam-notifies without signal.From its SKILL.md

Install
npx -y skills add willianbs/skills --skill loop-engineer

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.3 KB, 726 tokens by cl100k_base, as published. Nobody here has run it

Purpose

Arm a controlled loop that re-runs a prompt or skill path on an interval (or dynamically) until success, failure, timeout, or user stop.

When to Use / When NOT to Use

Use when: babysit CI/PR checks; watch deploys; poll until green/red; recurring /loop style work; long-running verification.

Do not use when: one-shot tasks; tight interactive coding sessions where a loop adds noise; production mutate-on-timer without explicit approval.

Preconditions

Clear work unit (prompt or skill + args) and stop criteria. If interval omitted, use dynamic mode with rationale.

Inputs / Outputs

Inputs: prompt/skill to run, interval or dynamic, stop criteria, optional gh/CI identifiers.

Outputs: LOOP_PLAN then recurring LOOP_STATUS updates.

Upstream / Downstream

Upstream: engineering-os, quality-gate, user.

Downstream: any skill named in the loop body; pr-generator; incident-commander if loop detects sev.

Core Principles

  1. Every loop needs stop criteria (success/fail/timeout/max ticks).
  2. Prefer signal-based wakes (CI status, log sentinel) over blind sleep when possible.
  3. One loop per purpose; do not duplicate existing loops.
  4. First run immediate; then interval — avoid double-fire on start.
  5. Status updates are short; full work only on tick.
  6. Destructive actions require explicit user approval each time (or pre-approval scope).
  7. Stop cleanly and report why.

Process

  1. Parse: interval (30s/5m/2h) or dynamic; body prompt/skills; stop criteria.
  2. Emit LOOP_PLAN — purpose, interval, stop, max ticks, sentinel.
  3. Check for existing matching loop; reuse or stop duplicates.
  4. Arm background waiter / poller as environment allows; or instruct host loop tool.
  5. Run body once immediately; record LOOP_STATUS.
  6. On each tick: run body; evaluate stop; update LOOP_STATUS.
  7. On stop: final status, summary of changes, artifacts produced.

Presets

  • babysit-pr — poll checks until success/fail
  • babysit-ci — watch workflow run
  • until-qg-pass — re-run quality-gate path
  • custom — user prompt

Evidence Requirements

Tick times, commands, CI URLs, stop reason. No fake “still running” without checking.

Stop Conditions / Failure Modes

ConditionAction
No stop criteriaRefuse to arm
Max ticks / timeoutStop; LOOP_STATUS failed/timeout
User says stopStop immediately
Body returns Block CriticalStop and escalate

Severity + Confidence

Escalate to incident-commander if loop observes prod SEV signals.

Output Contract

## LOOP_PLAN
Purpose: ...
Interval: ... | dynamic
Body: skill/prompt
Stop criteria: ...
Max ticks: ...
## LOOP_STATUS
Tick: N
Observed: ...
Decision: continue | stop
Stop reason: ...

Handoffs

engineering-os, quality-gate, pr-generator, incident-commander.

Never

  • Never arm infinite loops without max ticks/timeout.
  • Never force-push or prod-mutate on a timer without explicit scope.
  • Never spam full reports every tick — delta only.

What ships with it: 1 file

797 B alongside SKILL.md

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.