Seven patterns turn recurring prompts into repository routines
Loop Engineering documents 7 patterns for agent jobs that repeat on a schedule, including daily triage, pull-request babysitting, CI sweeps, and changelog drafting. Each loop combines written state, an isolated worktree, a maker and checker split, verification, and a human decision when an action is risky. The repository has examples for Claude Code, Codex, Grok, OpenCode, and GitHub Actions.
This is a reference repository and toolkit, not a hosted automation service. Its 568-file checkout contains starters and npm CLIs that initialize project files, audit readiness, estimate token cost, check state drift, manage context, expose pattern data over MCP, and create isolated worktrees. Scheduling and operation remain the adopter's responsibility.
The front-door loop package reduces the initial choice: init scaffolds a pattern, while doctor combines checks and returns the next actions. Start there rather than adopting every companion repository and CLI named in the README. The root install added only 8 packages, but that small dependency count does not represent the coding agent or scheduler a real loop needs.
L1 reporting is the sensible starting boundary
The README defines 3 autonomy levels: L1 reports or drafts, L2 permits assisted fixes, and L3 runs unattended. That progression gives a team time to observe failure modes before expanding permissions. The included material covers denied paths, auto-merge boundaries, MCP scopes, run logs, budgets, and conditions for killing a loop.
Its caveats are refreshingly specific. Sub-agents and frequent loops can burn through tokens. Automated verification does not remove the engineer's responsibility. Reading less of what an agent ships creates comprehension debt. Two developers can run the same pattern and get opposing results because the agent still depends on judgment and context. Begin with one repository chore and keep the first output read-only.
The readiness score is a prompt for inspection. A high score means expected files and controls are present. It does not establish that an agent understood the task or that an MCP credential has minimum permissions. Our root checkout had 21 CI workflow files, yet no root test target, so the presence of automation files alone is not proof that a chosen loop works.
What happened when we ran it
We cloned commit a6b41ab into a fresh Debian container with 3 CPUs, 8 GB of RAM, Node 22, no secrets, and an unprivileged user. The repository contained 568 files, about 14,918 lines of source, and occupied 3.1 MB when checked out. Our root npm install succeeded in 3 seconds, added 8 packages, and used 5 MB on disk. npm audit found 0 known vulnerabilities: 0 critical, high, moderate, or low.
There was no root build target, so we skipped the build. There was also no root test target and no tests directory, so we skipped tests. The README's contributor commands tell you to enter directories such as tools/loop, tools/loop-init, and tools/loop-audit before running their tests. A root install therefore gives no single pass or fail signal for the collection.
We also found 21 CI workflow files and no Dockerfile. That workflow count cannot replace a test run in our sandbox. Anyone evaluating a specific CLI should test that tool in its own directory, then try the generated loop on a disposable branch or repository.
The 5 MB install covers only the scaffold
Our install added 8 packages and used 5 MB, while an operational loop still needs a coding agent and scheduler. The quickest path uses npx @cobusgreyling/loop init . with a pattern and agent choice, followed by loop doctor .. That command writes skills, state, budget, and constraint files into an existing project. GitHub-oriented loops need repository access, and MCP examples need access to whichever connector they call.
Runtime details vary by pattern. Some examples use cron or systemd, some use GitHub Actions, and isolated fixes rely on Git worktrees. The README points to Windows and CRLF notes, yet much of the operational language is shell-oriented. The 3-second install says nothing about path handling, locking, cleanup behavior, or whether a selected agent can run unattended on your runner.
Cost also belongs in setup. A pull-request watcher running every 5 to 15 minutes differs sharply from a daily changelog draft. The project labels cadence and rough token cost by pattern, and its cost CLI can estimate a proposed loop. Set a provider spending limit and make the loop stop cleanly when its state is missing or malformed.
A 2026-08-26 push shows active maintenance
The last push was 2026-08-26, and GitHub listed 11 open issues when we fetched the project. Pull requests merged that day fixed fork contributions and documented a refactor path; other August merges addressed a negative success-rate metric, MCP cost error labeling, and sensitive-path matching. The latest tagged release remains v1.6.0 from 2026-07-20, so recent repository work matters more than the older tag alone.
The README links to pattern details, a quick start, tool-specific examples, architecture diagrams, failure modes, safety guidance, and contributor instructions. Navigation takes time because Loop Ready, Foundry, Outerloop, memory engineering, and fleet engineering appear early. Most new users need one of the 7 patterns and the front-door CLI, not the entire named ecosystem.
Choose Loop Engineering when useful agent work has become repetitive and needs a recorded state, budget, worktree, and approval policy. For a single coding session, Superpowers is simpler. For specification-led product work, Spec Kit is a closer fit. The absent root build and test targets mean your trial should end with the exact CLI and loop you intend to operate, not with the 3-second root install.