autonomous-loops

Chain non-interactive `claude -p` calls in a shell script, where each call is an isolated step such as implement, cleanup, verify, and commit. Use `set -e` so failures stop the pipeline, and always define exit conditions like max runs or max cost.

Use a sequential pipeline for single focused changes and a DAG orchestrator like Ralphinho when you have multiple interdependent work units needing parallel implementation. The decision matrix in the Skill maps task shape, spec availability, and parallelism needs to the right pattern.

Each `claude -p` call starts with a fresh context window, so bridge state through the filesystem. A SHARED_TASK_NOTES.md file that Claude reads at the start and updates at the end of each iteration is the standard approach.

A reviewer that wrote the code suffers author bias and misses its own mistakes. Running review in a separate agent process with its own context window, as in the Ralphinho pipeline stages, produces more objective quality and security checks.

Use a merge queue that rebases each unit onto main, runs tests, and evicts failures with full conflict context captured. The eviction context is fed back to the implementer agent so the retry resolves the conflict intelligently instead of blindly repeating.

Always set bounds: --max-runs for iteration count, --max-cost for spend, --max-duration for wall time, or a completion signal phrase that stops the loop after consecutive detections. Unbounded loops are listed as a primary anti-pattern.