/skill

Autonomous Loops

Original work by ECC. Credit goes to the ECC author and project.

Compatibility note for v1.8.0: autonomous-lo-loops is kept for one release. The main skill is now continuous-agent-loop. Put new loop advice there. Keep this skill only so old work does not break.

Use this skill to run Claude Code in a loop. It covers small claude -p jobs and large plans with many agents.

When to Use This Skill

Use it skill when you need to:

• Run a code task with little or no human help.
• Pick a loop that fits the size of the task.
• Build a job that runs steps in a fixed order.
• Run agents at the same time.
• Keep useful state between loop runs.
• Add checks, stop rules, and cleanup steps.

Do not use a large agent system for a small task. Start with the simplest loop that can do the job.

Pick a Loop Pattern

Safety Rules

Every loop must have clear limits:

1. Set a stop rule, such as a time limit or run count.
2. Stop at once when a required check fails.
3. Do not retry the same failed step forever.
4. Save work only after tests pass.
5. Do not let two agents edit the same files at once.
6. Check the current branch and changed files before a commit.
7. Keep secrets out of prompts, logs, and commit text.
8. Do not delete files unless the task names them.
9. Leave the work tree in a clear state after a stop.
10. Ask a person for help when the next step is not safe or clear.

1. Step-by-Step Pipeline With claude -p

This is the simplest loop. Split the work into small calls. Each call has one clear goal.

The claude -p flag runs one prompt without a chat session. Claude Code exits when the task ends.

#!/usr/bin/env bash
# daily-dev.sh

set -euo pipefail

# Step 1: Build the feature.
claude -p "Read docs/auth-spec.md. Add OAuth2 login in src/auth/. Write tests first. Do not make new doc files. Run the tests for this feature."

# Step 2: Clean up the code.
claude -p "Review the files changed for the OAuth2 task. Remove repeated code and checks that add no value. Keep tests for real app rules. Do not add features. Run the related tests."

# Step 3: Check the full project.
claude -p "Run the build, lint check, type check, and full test set. Fix failures caused by this task. Do not add features. Stop and report any failure you cannot fix safely."

# Step 4: Commit only valid work.
claude -p "Check the current branch and changed files. If all required checks pass, commit only the OAuth2 changes with this message: feat: add OAuth2 login flow. If checks fail or other files are mixed in, do not commit. Report the problem."

How It Works

1. Each call starts with fresh chat context.
2. Later calls use files left by earlier calls.
3. The step order matters.
4. set -euo pipefail stops the script on errors, missing shell values, and failed pipe steps.
5. Each prompt says what to change, what not to change, and how to check the result.

Fresh chat context does not mean fresh files. A bad change from one step can affect every later step.

Common Edge Cases

• A command hangs: Add a time limit in the job runner.
• A step partly works: Make the next step inspect changed files before it acts.
• Tests are flaky: Use a small retry limit. Report the flaky test. Do not loop forever.
• The work tree was already dirty: Do not commit files that were not part of the task.
• A tool is missing: Stop and name the missing tool. Do not guess at the result.
• The branch changed: Stop before a commit or push.
• Two jobs share one folder: Give each job its own worktree or copy.
• A prompt is too broad: Split it into build, cleanup, check, and commit steps.
• No files changed: Treat this as a valid result only if the task was already done. Check before moving on.

2. De-Sloppify Pass

Run this after a build step. Its only job is cleanup.

Ask it to:

• Read the files changed by the task.
• Remove repeated or unused code.
• Remove checks that do not guard a real risk.
• Keep tests for app rules and known bugs.
• Avoid new features.
• Run the right checks after cleanup.

Do not use vague text such as “make it better.” Name the files, limits, and checks.

3. Parallel Agent Loops

Use agents at the same time only when their work does not overlap.

Before they start:

1. Write one task for each agent.
2. Give each agent its own files or folder.
3. State the tests each agent must run.
4. Set a stop rule.
5. Pick one merge owner.

The merge owner must review each result, run all checks, and solve merge issues. Agents must not race to edit or merge the same file.

4. RFC-Based Work

Use an RFC for large work with many parts. The RFC should state:

• The goal.
• What is not part of the goal.
• Each work unit.
• Which units depend on other units.
• The files owned by each unit.
• The tests for each unit.
• The full-project checks.
• The stop and rollback rules.
• Who owns the final merge.

Start a work unit only after all work it needs is done. If the plan changes, update the RFC before more agents start.

5. State Between Runs

Store only the state needed for the next run. Good state includes:

• The task ID.
• The current step.
• The last good commit.
• Checks that passed or failed.
• Retry count.
• A short error note.

Write state in a small, clear file. Update it only after a step ends. If the state file is missing or broken, stop or restart from a known good point.

Do not treat chat history as the only record of progress.

Done Rules

A loop is done only when:

• The requested work exists.
• Required checks pass.
• No unsafe or unknown changes remain.
• The final state is saved.
• The result is reported in plain words.

A loop must stop and ask for help when it cannot meet these rules safely.