A Practical Guide to Loop Engineering: 14 Steps to Automate Repetitive Tasks

The author shares a 14‑step practical manual for Loop Engineering, synthesizing insights from Anthropic’s engineering docs, Addy Osmani’s long‑form article, and recent research with real‑world data.

1. Decide if you need a loop

Before building, ask four questions: (1) Is the task repetitive enough to amortize the loop’s cost? (2) Is there an automatic check (tests, type‑checking, linter, build script) that can detect failure? (3) Can your token budget absorb the inevitable waste? (4) Can the agent run the code you write (logging, reproducibility, crash visibility)? An additional fifth question is whether you intend to review the generated code; if not, don’t build a loop.

Suitable teams have strong test suites for CI triage, dependency upgrades, lint‑and‑fix, or turning issues into PR drafts. Unsuitable are personal developers on consumer‑grade plans, codebases with insufficient test coverage, or teams whose bottleneck is manual review rather than typing speed.

2. Five core Loop Engineering components

Automations – the heartbeat that triggers on a schedule or event, runs a round, then pauses until the next trigger. Stop conditions must be hard‑coded to avoid infinite runs.

Worktrees – give each agent an isolated Git worktree so parallel agents don’t clash on the same files; results are merged later.

Skills – a stored description of project context (frameworks, conventions, known pitfalls) that agents can read each round instead of being re‑explained.

Connectors – bridge the loop to real tools (GitHub for PRs, Linear/Jira for tickets, Slack for summaries, Sentry for alerts) so the loop truly participates in the workflow.

Sub‑agents – separate the writing agent from a verification agent with different instructions, catching issues that a self‑scoring model might miss.

3. Build a minimal, non‑pitting loop

Follow these steps in order:

Create an Automation that triggers on a rhythm and stops on explicit conditions.

Define a Skill that records project background to avoid re‑explaining each round.

Add a state file to record what has been done and what to do next.

Introduce a hard gate that rejects work failing tests, type checks, or builds.

Monitor the cost per accepted change; if acceptance falls below 50 % the loop is losing money.

After a stable manual run, convert the skill into a loop, then schedule the automation (e.g., using /goal with a stop condition). Use Git worktrees for parallel agents, attach connectors for PRs, tickets, and Slack, and finally split writing and verification into sub‑agents.

# Loop state · ci-triage
# 上次运行
2026-06-09 03:30 UTC · 7 个失败已分类，3 个草拟修复，4 个上报
# 进行中
- claude/fix-auth-token-refresh — 本地测试通过，等 CI
# 今日完成
- claude/bump-axios-1.7.4 → 已合并（CI 绿，依赖 loop 已验证）
# 上报给人
- src/billing/refund.ts — 测试三种崩法，根因不明
# 经验教训（写这里，别写在聊天里）
- 2026-06-08: 这台 Windows runner 上 PowerShell 撞 TLS 1.2 问题，改用 bash。

4. Anticipate failure modes and security risks

After deployment, loops can fail in three ways: (1) pretending to finish – agents signal completion early without doing the work, caused by missing hard gates; (2) understanding debt – rapid delivery of unfamiliar code widens the gap between repository contents and team knowledge, making future debugging hard; (3) cognitive surrender – developers stop judging output and accept whatever the loop returns. Additionally, an unattended loop expands the attack surface.

Mitigations include adding SAST, dependency audit, and credential scanning to the gate; ensuring skills do not leak credentials (17022 skills, 520 leak credentials); disabling verbose logs in production; and reviewing permissions regularly (e.g., add write permission only after a 30‑day review).

5. The 14‑step roadmap

The full roadmap compresses into three sections: (1) decide – five questions; (2) build – eight concrete steps (manual run, skill, state, gate, automation, worktree, connectors, sub‑agents); (3) maintain – monitor cost per accepted change, periodic permission reviews, diff checks, and prevent the loop from touching core architecture.

Two years of experience show that prompt quality, context, and one‑shot output were the main levers; now, robust workflow automation has become the real moat.