---
name: autonomous-loops
description: Patterns for running autonomous agent workflows — from simple pipelines to complex multi-agent DAGs. Reference for setting up build-fix loops, continuous PRs, and de-sloppify passes.
disable-model-invocation: true
---

# Autonomous Loop Patterns

Reference guide for autonomous agent workflows, ranked by complexity.

## Pattern 1: Sequential Pipeline

**Complexity**: Low
**Use when**: Simple one-shot tasks chained together

```bash
# Run a sequence of claude commands
claude -p "Implement feature X" --output-format json | \
claude -p "Write tests for the implementation" --output-format json | \
claude -p "Review the code for issues"
```

**Pros**: Simple, predictable, easy to debug
**Cons**: No error recovery, no parallelism

## Pattern 2: Build-Fix Loop

**Complexity**: Medium
**Use when**: Making the build green after changes

```bash
MAX_CYCLES=5
CYCLE=0

while [ $CYCLE -lt $MAX_CYCLES ]; do
  CYCLE=$((CYCLE + 1))
  echo "=== Cycle $CYCLE ==="

  # Run build/tests
  BUILD_OUTPUT=$(npm run build 2>&1)
  if [ $? -eq 0 ]; then
    echo "Build passed on cycle $CYCLE"
    break
  fi

  # Fix errors
  claude -p "Fix these build errors. Make minimal changes only:
$BUILD_OUTPUT"

  if [ $CYCLE -eq $MAX_CYCLES ]; then
    echo "STALLED after $MAX_CYCLES cycles — escalating"
    exit 1
  fi
done
```

**Key rules**:
- Set a MAX_CYCLES limit (3-5 is reasonable)
- Detect stalls (same error repeating)
- Use the `loop-operator` agent for monitoring

## Pattern 3: Test-Driven Fix Loop

**Complexity**: Medium
**Use when**: Fixing failing tests one at a time

```bash
# Get failing tests
FAILURES=$(npm test 2>&1 | grep "FAIL")

for test_file in $FAILURES; do
  claude -p "Fix this failing test. Read the test to understand intent,
then fix the implementation (not the test):
File: $test_file"
done

# Verify all tests pass
npm test
```

**Key rules**:
- Fix implementation, not tests (unless test is wrong)
- Run full suite after fixes to catch regressions
- Stop if fix count exceeds threshold

## Pattern 4: Continuous PR Loop

**Complexity**: High
**Use when**: Processing a backlog of tasks as PRs

```bash
# Process tasks from a list
while IFS= read -r task; do
  BRANCH="auto/$(echo "$task" | tr ' ' '-' | head -c 40)"
  git checkout -b "$BRANCH" main

  claude -p "Implement: $task
Requirements:
- Create a single focused PR
- Include tests
- Follow RULES.md conventions"

  # Run verification
  claude -p "/verification-loop"

  # Create PR if verification passes
  if [ $? -eq 0 ]; then
    git push -u origin "$BRANCH"
    gh pr create --title "$task" --body "Automated implementation"
  fi

  git checkout main
done < tasks.txt
```

**Key rules**:
- One task = one branch = one PR
- Run verification before creating PR
- Set cost/time limits per task
- Skip tasks that fail after N attempts

## Pattern 5: De-Sloppify Pass

**Complexity**: Medium
**Use when**: Cleaning up after a fast implementation pass

The insight: **Two focused agents outperform one constrained agent**. First implement fast, then clean up.

```bash
# Phase 1: Fast implementation (allow some sloppiness)
claude -p "Implement feature X quickly. Focus on correctness, not polish."

# Phase 2: Cleanup pass
claude -p "Review and clean up the recent changes:
1. Remove console.log/debug statements
2. Add missing error handling
3. Fix type safety issues (no 'any')
4. Ensure consistent naming
5. Add missing JSDoc for public APIs

Do NOT change behavior or add features. Only clean up."
```

**Key rules**:
- Cleanup agent must not change behavior
- Use git diff to scope the cleanup
- Run tests after cleanup to verify no regressions

## Pattern 6: Multi-Agent DAG

**Complexity**: Very High
**Use when**: Large features requiring coordinated parallel work

```
     ┌─────────┐
     │ Planner │
     └────┬────┘
          │
    ┌─────┼─────┐
    ▼     ▼     ▼
  [API] [UI]  [DB]     ← Parallel agents in worktrees
    │     │     │
    └─────┼─────┘
          ▼
    ┌───────────┐
    │ Integrator│      ← Merges and resolves conflicts
    └─────┬─────┘
          ▼
    ┌───────────┐
    │ Reviewer  │      ← Final quality check
    └───────────┘
```

**Implementation**:

1. **Planner** decomposes the spec into independent tasks with dependencies
2. Independent tasks run in **parallel worktrees** (isolated git branches)
3. **Integrator** merges worktrees, resolves conflicts
4. **Reviewer** does final quality check

**Key rules**:
- Use git worktrees for isolation
- Each agent gets a focused, self-contained task
- Integrator handles merge conflicts
- Full verification after integration

## Choosing a Pattern

| Situation | Pattern |
|-----------|---------|
| Single task, no iteration needed | 1 (Sequential) |
| Build is broken, need to fix | 2 (Build-Fix) |
| Tests are failing | 3 (Test-Driven Fix) |
| Backlog of independent tasks | 4 (Continuous PR) |
| Fast implementation needs polish | 5 (De-Sloppify) |
| Large feature, multiple concerns | 6 (Multi-Agent DAG) |

## Safety Rules (All Patterns)

1. **Always set limits** — Max cycles, max time, max cost
2. **Always verify** — Run tests/build after each change
3. **Always detect stalls** — Same error 3x = stop
4. **Always preserve work** — Commit before risky operations
5. **Always escalate** — When stuck, stop and ask for human input