Build Robust AI Loops with Claude Code: A Step‑by‑Step Guide

What Is a Real "Claude Loop"?

A loop is not merely repeating the same prompt; it is a reusable workflow built around a large model that defines a trigger, the context to read, the action to perform, verification, state storage, and decision points.

The Six Essential Elements of Every Claude Loop

Trigger : What event starts the run (manual command, cron, file change, CI failure, Git commit).

Context : Which files or information Claude must read before acting.

Action : The concrete task Claude should perform (e.g., write a report, draft a bug‑fix plan).

Verification : How the result is validated (checklist, test suite, safety rules).

State Update : What information is persisted for the next run (PROGRESS.md).

Decision : Whether to continue, stop, or request human intervention.

Missing any of these elements leads to blind confidence, loss of state, or endless loops.

Minimal "4‑File System" (No Complex Architecture)

my-loop/
├── TASK.md
├── LOOP_INSTRUCTIONS.md
├── PROGRESS.md
└── outputs/
    └── daily-review.md

TASK.md : Declares the ultimate goal of the loop.

LOOP_INSTRUCTIONS.md : SOP that specifies what Claude may read, write, what is forbidden, and how to verify results.

PROGRESS.md : Stores the latest state, blockers, and next‑run focus.

outputs/ : Holds the final artefacts produced by the loop.

Claude reads the files at the start of each run and updates them before exiting, enabling true continuation across sessions.

Step‑by‑Step Construction

Step 1 – Write TASK.md

State the high‑level goal without embedding detailed actions (those belong in LOOP_INSTRUCTIONS.md). Example template:

# Daily Project Review Loop

## Goal
Review the current project folder, summarize changes, identify blockers, and output a short daily review report.

## Expected Output
- outputs/daily-review.md
- PROGRESS.md

## Scope
Claude may read files and write to outputs/, but must not delete or rename files or send messages.

Step 2 – Write PROGRESS.md

This is the loop’s memory. Include current state, last run summary, open items, blockers, and whether human review is needed. Keep it concise; treat it as a control panel, not a full history archive.

# Loop Progress
## Current State
- Status: Active
- Core Task: Daily Project Review
- Focus: [Write the most important work]
- Last Updated: [date]

## Last Run
- Date: 
- Summary: 
- Files Reviewed: 
- Outputs: 

## Open Items
- 

## Blockers
- 

## Needs Human Review
- 

## Next Run Focus
- 

## Decisions Made
-

Step 3 – Write LOOP_INSTRUCTIONS.md

Define the SOP, safety rules, and failure policy. Example excerpt:

## Before You Start
1. Read TASK.md
2. Read PROGRESS.md
3. Inspect the project folder
4. Identify changes, unfinished parts, and items needing human input

## What You Should Do
- Write a short daily review report to `outputs/daily-review.md` containing:
  * Overall status summary
  * List of reviewed files
  * Concrete changes made
  * Blockers or open questions
  * Suggested next steps
- Update PROGRESS.md with date, summary, checked files, next focus, and human‑review flag.

## Safety Rules
- Never delete files
- Never rename or move files
- Never modify source code files directly

## Failure Policy
1. If a required section is missing, retry once.
2. If PROGRESS.md is not updated, retry once.
3. If any non‑allowed file was modified, stop immediately.
4. If verification fails twice consecutively, mark the run as "Needs Human Review".

Manual Testing Before Automation

Run the loop manually in Claude Code with a prompt that references the three files, verify that the outputs and PROGRESS.md are correct, and simulate a few project changes to ensure state persistence.

Verification (The Often‑Ignored Weak Spot)

Run a separate verifier that only reads the latest outputs and checks them against the verification checklist defined in LOOP_INSTRUCTIONS.md. Strong verification requires all checklist items to pass before the run is considered accepted.

“Help me see if this result looks good.” – weak verification.

“Only when all seven hard metrics are green should the run be marked Accepted.” – strong verification.

Permission Ladder

Gradually increase Claude’s permissions:

Level 1 – Read Only: Claude can only read files, tickets, logs.
Level 2 – Draft Outputs: Claude may write drafts to `outputs/` but cannot interact externally.
Level 3 – Sandbox Edits: Claude may edit code inside an isolated Docker container or temporary Git branch.
Level 4 – Draft External Actions: Claude can prepare PR descriptions or Slack messages but cannot send them.
Level 5 – Human‑Approved Actions: Claude may act only after explicit human approval.
Level 6 – Automated Low‑Risk: Claude can perform narrow, low‑risk automation with strict logging and rollback.

Start any new loop at Level 1 or 2 and only promote after repeated successful runs.

Automated Scheduling with /loop

Once manual testing is stable, use Claude Code’s built‑in /loop command to schedule runs (e.g., /loop 24h for daily execution). Optional intervals include 15m, 1h, 24h, 7d. The command merely triggers the prompt at the specified cadence; the real intelligence resides in the four‑file system and verification logic.

/loop 24h Please run the daily project review loop. Strictly follow LOOP_INSTRUCTIONS.md. Read TASK.md and PROGRESS.md first. Write the report to outputs/daily-review.md and update PROGRESS.md. Execute the verification checklist. If no meaningful changes, keep the report brief. If human intervention is needed, mark it explicitly in PROGRESS.md. Do not modify any files other than the two mentioned.

Tool and Connector Integration

When the loop is stable, add connectors (GitHub, Slack, Linear/Jira) with explicit allow/deny rules in LOOP_INSTRUCTIONS.md. Each new tool expands the potential blast radius, so follow the same read‑then‑draft‑then‑approve pattern.

## Tool Permissions Policy
### GitHub
Allowed: read open issues, read PR status, read CI status, draft summary in outputs/github-review.md
Not allowed: post comments without review

### Slack
Allowed: draft message in outputs/slack-update.md
Not allowed: send messages or @‑mention users

### Linear / Jira
Allowed: read assigned tickets, draft updates in a designated folder
Not allowed: change ticket status or create tickets without review

Common Pitfalls and How to Avoid Them

No stop condition → endless runs.

No verification → blind confidence.

No state persistence → each run starts from zero.

Vague goals → cannot be expressed as a checklist.

Design loops with clear schedules, limited scope, predictable outputs, and safe permission boundaries.

Ten Practical Loops You Can Build This Week

Daily project review.

Meeting follow‑up extractor.

Folder cleanup planner.

CI/CD failure triage.

GitHub issue summarizer.

PR review assistant.

Newsletter research loop.

Documentation gap finder.

Daily stand‑up drafter (reads PROGRESS.md).

Weekly retrospective loop.

All start from the same four‑file system; only TASK.md and LOOP_INSTRUCTIONS.md need to be customized.

Conclusion

Moving from prompt‑only interactions to full loops teaches AI "how to work" rather than just "what to say". The four‑file system (TASK.md, LOOP_INSTRUCTIONS.md, PROGRESS.md, outputs/) solves the two biggest pain points of current LLM usage: loss of state and uncontrolled behavior. By treating PROGRESS.md as a control panel, enforcing strong verification, and progressing through the permission ladder, developers can safely automate repetitive work and become true AI system architects.