Skip to content
Guides/Starter

Build Your First Loop

Short answer

Start with one small loop you can personally review. Pick one discovery source, one outcome, one validation step, one checker, one stop rule, and one place to save the run note.

Why it matters

The first loop should teach you trust, not replace your judgment. A small CI, review, or content-maintenance loop is easier to inspect, cheaper to run, and safer to improve than a broad autonomous workflow.

A good first loop path

  1. 01Need a concrete signal?Use CI failures or review comments
  2. 02Need a safe workspace?Use a branch, worktree, or sandbox
  3. 03Need proof it worked?Run the same checks a human would run
  4. 04Need to avoid drift?Write a run note before stopping

Practical checklist

  • Choose one discovery source: CI failures, pull request comments, issues, or a small inbox
  • Write the goal as an outcome, not a list of instructions
  • Add the validation command, score, artifact, or checklist that proves the work is done
  • Name the independent checker and what it must reject
  • Set max iterations, budget limit, fallback, and human approval before merge or deploy
  • Save a short run note: what was seen, what changed, checks run, and what to do next

Example

First loop: every weekday morning, read failed CI on open pull requests. If a failure is small and reproducible, draft the smallest fix in an isolated worktree, run lint/test/build, ask a separate checker to review the diff, then stop for human approval.

Common failure modes

Starting with a broad goal like “improve the repo”
Scheduling the loop before it has passed several manual runs
Skipping the run note, so every pass starts cold
Letting the loop merge, deploy, delete, or contact people without approval

Related templates

FAQ

Not immediately. Run it manually until the checker and stop rule feel boringly reliable, then consider a schedule.

Sources & further reading