Autonomous Loops Skill

Compatibility note (v1.8.0): autonomous-loops is retained for one release. The canonical skill name is now continuous-agent-loop. New loop guidance should be authored there, while this skill remains available to avoid breaking existing workflows.

Patterns, architectures, and reference implementations for running Claude Code autonomously in loops. Covers everything from simple claude -p pipelines to full RFC-driven multi-agent DAG orchestration.

When to Use

• Setting up autonomous development workflows that run without human intervention
• Choosing the right loop architecture for your problem (simple vs complex)
• Building CI/CD-style continuous development pipelines
• Running parallel agents with merge coordination
• Implementing context persistence across loop iterations
• Adding quality gates and cleanup passes to autonomous workflows

Loop Pattern Spectrum

From simplest to most sophisticated:

1. Sequential Pipeline (claude -p)

The simplest loop. Break daily development into a sequence of non-interactive claude -p calls. Each call is a focused step with a clear prompt.

Core Insight

If you can't figure out a loop like this, it means you can't even drive the LLM to fix your code in interactive mode.

The claude -p flag runs Claude Code non-interactively with a prompt, exits when done. Chain calls to build a pipeline:

#!/bin/bash
# daily-dev.sh — Sequential pipeline for a feature branch

set -e

# Step 1: Implement the feature
claude -p "Read the spec in docs/auth-spec.md. Implement OAuth2 login in src/auth/. Write tests first (TDD). Do NOT create any new documentation files."

# Step 2: De-sloppify (cleanup pass)
claude -p "Review all files changed by the previous commit. Remove any unnecessary type tests, overly defensive checks, or testing of language features (e.g., testing that TypeScript generics work). Keep real business logic tests. Run the test suite after cleanup."

# Step 3: Verify
claude -p "Run the full build, lint, type check, and test suite. Fix any failures. Do not add new features."

# Step 4: Commit
claude -p "Create a conventional commit for all staged changes. Use 'feat: add OAuth2 login flow' as the message."

Key Design Principles

1. Each step is isolated — A fresh context window per claude -p call means no context bleed between steps.
2. Order matters — Steps execute sequentially. Each builds on the filesystem state left by the previous.
3. Negative instructions are dangerous — Don't say "don't test type systems." Instead, add a separate cleanup step (see De-Sloppify Pattern).
4. Exit codes propagate — set -e stops the pipeline on failure.

Variations

With model routing:

# Research with Opus (deep reasoning)
claude -p --model opus "Analyze the codebase architecture and write a plan for adding caching..."

# Implement with Sonnet (fast, capable)
claude -p "Implement the caching layer according to the plan in docs/caching-plan.md..."

# Review with Opus (thorough)
claude -p --model opus "Review all changes for security issues, race conditions, and edge cases..."

With environment context:

# Pass context via files, not prompt length
echo "Focus areas: auth module, API rate limiting" > .claude-context.md
claude -p "Read .claude-context.md for priorities. Work through them in order."
rm .claude-context.md

With --allowedTools restrictions:

# Read-only analysis pass
claude -p --allowedTools "Read,Grep,Glob" "Audit this codebase for security vulnerabilities..."

# Write-only implementation pass
claude -p --allowedTools "Read,Write,Edit,Bash" "Implement the fixes from security-audit.md..."

…