How to Create Loops with Claude Code

Most Claude workflows are still one-shot.

You write a prompt. Claude responds. Session ends. Tomorrow you start from zero.

That's fine for one-off tasks.

But for repetitive work — daily reviews, CI triage, project monitoring, meeting follow-ups — you're rebuilding the same context every single day.

That's not a workflow. That's manual labor with AI sprinkles.

The better abstraction is a loop.

Save this. You'll use it.

What a Claude loop actually is

A loop is not "just ask Claude again."

A loop is a repeatable workflow structure around the model.

It defines:

→ What triggers the run

→ What context Claude reads before acting

→ What Claude is allowed to do → How the output is verified

→ Where the state is stored

→ When to stop, repeat, or ask for human review

The model still does the reasoning.

The loop provides the operating structure.

The shift matters because Claude sessions are temporary.

Without a loop, every run starts from zero. With a loop, Claude reads what happened before and continues from there.

6 parts every Claude loop needs

A loop without structure is just a prompt that runs twice.

Here are the 6 parts that make a loop actually work:

→ 1. Trigger

What starts the run.

Manual command. Scheduled timer. File change. CI failure. Git event.

→ 2. Context

What Claude reads before acting.

Task definition. Previous progress. Project files. Instructions.

→ 3. Action

What Claude does.

Write a report. Draft a fix. Classify failures. Update a document.

→ 4. Verification

How you check the result.

Checklist. Test suite. Required sections. Safety boundary check.

→ 5. State update

What gets remembered for next time.

PROGRESS.md updated. Blockers recorded. Next run guided.

→ 6. Decision

Stop. Repeat. Or escalate to human.

That's the full loop.

And every step matters.

Skip verification → the loop trusts itself blindly.

Skip state → every run starts from zero.

Skip the decision → the loop never knows when to stop.

The 4-file system that makes loops work

You don't need infrastructure.

You need 4 files and a folder.

1my-loop/
2├── TASK.md
3├── LOOP_INSTRUCTIONS.md
4├── PROGRESS.md
5└── outputs/
6    └── daily-review.md

TASK.md — The goal. What this loop is trying to accomplish.

LOOP_INSTRUCTIONS.md — The operating procedure. How Claude should run, what it's allowed to do, how to verify.

PROGRESS.md — The memory. What happened last time, what's blocked, what the next run should focus on.

outputs/ — Where Claude writes results. Predictable. Inspectable. Safe.

That's it.

Claude reads these files at the start of every run. Updates them at the end. Next run continues from where the last one stopped.

This is what makes loops different from repeated prompts.

State lives outside the chat.

TASK.md — Define the goal clearly

This file tells Claude what the loop is for.

Keep it high-level. Don't put operating details here. Those go in LOOP_INSTRUCTIONS.md.

Copy this template:

1# Daily Project Review Loop
2
3## Goal
4Review this project folder, summarize what changed,
5identify blockers, and produce a short daily review report.
6
7## Expected Output
8Each run should produce or update:
9- `outputs/daily-review.md`
10- `PROGRESS.md`
11
12## Scope
13Claude may inspect files in this workspace and write
14reports to the `outputs/` folder.
15
16Claude should NOT:
17- Modify source files
18- Delete or rename files
19- Send messages or open tickets

Notice the last section.

The first version of any loop should have explicit "do not" rules.

This is not Claude being untrusted.

This is you being a good engineer.

PROGRESS.md — The loop's memory

This is the most important file in the system.

Without it, every run starts from scratch. With it, Claude knows what happened and continues from there.

The structure that actually works:

1# Loop Progress
2
3## Current State
4- Status: Active
5- Main objective: Daily project review
6- Current focus: [what matters right now]
7- Last updated: [date]
8
9## Last Run
10- Date:
11- Summary:
12- Files reviewed:
13- Output produced:
14
15## Open Items
16-
17
18## Blockers
19-
20
21## Needs Human Review
22-
23
24## Next Run Should
25-
26
27## Decisions Made
28-
29
30## Do Not Repeat
31-

The "Do Not Repeat" section is critical.

It prevents Claude from retrying things that already failed.

The "Needs Human Review" section is critical.

It stops the loop from silently continuing when it shouldn't.

Two rules for keeping PROGRESS.md useful:

→ If Claude needs it to decide the next action → keep it in PROGRESS.md → If you just want a record → move it to outputs/history/

State files that grow forever become useless.

Keep PROGRESS.md as a control panel, not an archive.

LOOP_INSTRUCTIONS.md — The operating procedure

This file is the control layer around Claude.

It tells Claude exactly what to read, what to write, what not to touch, and how to verify the result before stopping.

The template that works:

1# Loop Instructions
2
3You are running a daily project review loop.
4
5## Before You Start
61. Read `TASK.md`
72. Read `PROGRESS.md`
83. Inspect the project folder
94. Identify what changed, what's incomplete, what needs human review
10
11## What You Should Do
12Write a short daily review to `outputs/daily-review.md` including:
13- Summary of current state
14- Files reviewed
15- Meaningful changes
16- Blockers or unresolved questions
17- Recommended next actions
18
19After writing, update `PROGRESS.md` with:
20- Date of this run
21- Summary of what happened
22- Files checked
23- What the next run should do
24- Whether human review is needed
25
26## Safety Rules
27- Do not delete files
28- Do not rename or move files
29- Do not modify source files
30- Only write to `outputs/daily-review.md` and `PROGRESS.md`
31- If unsure whether an action is allowed → stop and ask
32
33## Verification Checklist
34Before ending the run, confirm:
35- `outputs/daily-review.md` exists with all required sections
36- `PROGRESS.md` was updated
37- No files outside allowed paths were modified
38
39## Failure Policy
40If verification fails:
411. Missing section in report → fix once
422. PROGRESS.md not updated → update once
433. Forbidden file modified → stop immediately
444. Same check fails twice → mark as needing human review

Notice the failure policy at the bottom.

Most loops have no failure policy.

So when something goes wrong, Claude improvises.

That's where loops create problems.

Define the failure path explicitly. Always.

Running your first loop manually

Don't schedule yet.

Run manually first.

Open the folder in Claude Code or Claude Desktop/Cowork. Use this prompt:

1Run the daily project review loop for this workspace.
2
3Follow `LOOP_INSTRUCTIONS.md` exactly.
4
5Before acting, read:
6- `TASK.md`
7- `PROGRESS.md`
8- `LOOP_INSTRUCTIONS.md`
9
10Then inspect the workspace, write the daily review to
11`outputs/daily-review.md`, update `PROGRESS.md`,
12run the verification checklist, and report what changed.
13
14Do not modify any files except
15`outputs/daily-review.md` and `PROGRESS.md`.

After the run, check two things:

→ outputs/daily-review.md — structured report with all sections

→ PROGRESS.md — updated state, next run guidance, human review flags

If both look right → the loop is working.

Now run it 3-5 more times with small changes.

Add a notes file. Add a blocker to PROGRESS.md. Change something in the workspace.

Each run should pick up the changes without starting from zero.

That continuity is the whole point.

Verification: the part most people skip

Here's the failure mode nobody talks about.

Claude runs the loop. Says it's done. Updates the state. Stops.

Everything looks fine.

But the report is missing required sections. Or PROGRESS.md wasn't actually updated. Or Claude quietly edited a file it shouldn't have.

You only find out when something breaks.

That's why verification exists.

The loop should not stop because Claude says it's finished.

It stops because a concrete condition was checked.

Good verification looks like this:

Run a verification pass for the latest loop execution.

Check the output against the Verification Checklist

in \LOOP_INSTRUCTIONS.md\.

Report:

1. Which checks passed
2. Which checks failed
3. Which files were modified
4. Whether the run is safe to accept
5. Whether human review is required

Do not modify any files during this verification pass.

Run the worker. Then run the verifier. Separately.

Over time you can merge them. But during early testing, keep them apart.

The verifier needs a pass/fail standard.

"Review this and tell me if it looks good" is NOT a verifier.

"Check these 7 conditions and mark the run accepted only if all 7 pass" IS a verifier.

Scheduling with /loop

The loop is running reliably manually.

Now schedule it.

In Claude Code, use /loop:

1/loop 24h Run the daily project review loop for this workspace.
2
3Follow `LOOP_INSTRUCTIONS.md` exactly.
4Read `TASK.md` and `PROGRESS.md` first.
5Write the report to `outputs/daily-review.md`.
6Update `PROGRESS.md` before stopping.
7Run the verification checklist.
8If no meaningful changes → keep the report short.
9If human review needed → mark clearly in `PROGRESS.md`.
10Do not modify any files except `outputs/daily-review.md`
11and `PROGRESS.md`.

The interval options:

→ /loop 15m — Testing cadence (use while watching)

→ /loop 1h — Hourly monitoring

→ /loop 24h — Daily review

→ /loop 7d — Weekly cleanup or summary

Important: /loop is not magic.

It just repeats the prompt.

The quality of the loop comes from the structure around the prompt — the files, the instructions, the verification, the state.

/loop only provides the trigger.

Also know about /goal:

/loop = run again because time passed.

/goal = keep running until a condition is met.

1/goal outputs/daily-review.md exists, PROGRESS.md is updated,
2verification checklist passes, no forbidden files modified.

Use /loop for time-based work (daily reviews, monitoring).

Use /goal for completion-based work (fix until tests pass, write until all sections done).

The permission ladder

This is where most loops go wrong.

People build a loop that works. Then immediately give it too much power.

The loop posts to Slack directly. Pushes code without review. Closes tickets automatically.

Then something goes wrong and it's a mess.

Use the permission ladder instead:

1Level 1 — Read only
2Claude reads files, tickets, logs, issues.
3
4Level 2 — Draft outputs
5Claude writes to outputs/ only.
6Reports, plans, recommendations.
7Nothing external.
8
9Level 3 — Sandbox edits
10Claude modifies files inside a controlled sandbox.
11Isolated branch or worktree.
12
13Level 4 — Draft external actions
14Claude prepares PR, Slack message, ticket update.
15Does NOT send or merge.
16
17Level 5 — Human-approved actions
18Claude applies changes only after explicit approval.
19
20Level 6 — Automated low-risk actions
21Claude completes narrowly scoped tasks automatically.
22With logs, limits, and rollback.

Your first loop should live at Level 1 or Level 2.

That's not weakness. That's engineering.

Level 1 and 2 loops can still be enormously valuable.

Claude can inspect your GitHub issues, read CI failures, review PRDs, and summarize everything — all without touching anything important.

Prove the loop works at Level 2 first.

Then decide whether it deserves Level 3.

When loops go wrong (and how to prevent it)

Bad first loop:

Every day, improve the product strategy until it feels stronger.

→ No stop condition → No verification → No state → "Feels stronger" is not a checklist item

This loop will either do nothing useful or change things it shouldn't.

Good first loop:

Every Friday, review the product strategy document.

Identify sections that changed this week.

List unresolved assumptions.

Write a structured review note to outputs/strategy-review.md.

Do not edit the strategy document directly.

→ Clear schedule → Limited scope → Predictable output file → Safe permission boundary

The difference isn't intelligence. It's design.

The 5 things that sink loops:

→ Scheduling before manual testing

→ No state file — every run restarts from zero

→ No verification — the loop trusts itself

→ No failure policy — bad outcomes improvise

→ Too many tools too early — blast radius expands

Fix all five before the first /loop command.

Adding tools and connectors

Once the local loop is stable, you can extend it.

GitHub. Slack. Linear. Jira. CI logs.

But every new tool expands the blast radius.

Follow the same principle: read first, draft second, write only after repeated successful runs.

Tool-specific rules go in LOOP_INSTRUCTIONS.md:

1## Tool Permissions Policy
2
3### GitHub
4Allowed:
5- Read open issues
6- Read pull request status
7- Read CI status
8- Draft summary in `outputs/github-review.md`
9NOT allowed:
10- Push commits
11- Merge pull requests
12- Close issues
13- Comment publicly without approval
14
15### Slack
16Allowed:
17- Draft message in `outputs/slack-update.md`
18NOT allowed:
19- Send messages
20- Mention users
21- Post to channels
22
23### Linear/Jira
24Allowed:
25- Read assigned tickets
26- Draft suggested updates
27NOT allowed:
28- Change status
29- Close tickets
30- Create tickets without approval

If the tool isn't listed → stop and ask for human review.

This protects you from the loop doing things you didn't think about.

What your first complete loop looks like

Here's the full setup from scratch.

1## Tool Permissions Policy
2
3### GitHub
4Allowed:
5- Read open issues
6- Read pull request status
7- Read CI status
8- Draft summary in `outputs/github-review.md`
9NOT allowed:
10- Push commits
11- Merge pull requests
12- Close issues
13- Comment publicly without approval
14
15### Slack
16Allowed:
17- Draft message in `outputs/slack-update.md`
18NOT allowed:
19- Send messages
20- Mention users
21- Post to channels
22
23### Linear/Jira
24Allowed:
25- Read assigned tickets
26- Draft suggested updates
27NOT allowed:
28- Change status
29- Close tickets
30- Create tickets without approval

Then fill each file (use the templates from above).

Then run manually:

1Run the daily project review loop for this workspace.
2
3Follow `LOOP_INSTRUCTIONS.md` exactly.
4Before acting, read TASK.md, PROGRESS.md,
5and LOOP_INSTRUCTIONS.md.
6Write the daily review to `outputs/daily-review.md`.
7Update `PROGRESS.md` before stopping.
8Run the verification checklist.
9Do not modify any files except
10`outputs/daily-review.md` and `PROGRESS.md`.

Then verify:

1Run a verification pass.
2Check against the Verification Checklist in
3`LOOP_INSTRUCTIONS.md`.
4Report which checks passed, which failed,
5which files were modified, whether human review is required.
6Do not modify any files.

Run 3-5 times manually with small workspace changes.

Then schedule:

1/loop 24h Run the daily project review loop...
2[same prompt as manual, prefixed with /loop 24h]

Review the first week of scheduled outputs before trusting it.

That's the full system.

The shift that changes everything

Before loops:

→ You wrote a prompt

→ Claude answered

→ Tomorrow you wrote the same prompt again

→ Claude had no memory of yesterday

→ You manually tracked what changed

→ Everything reset with each session

After loops:

→ TASK.md defines the goal once

→ PROGRESS.md carries memory across runs

→ LOOP_INSTRUCTIONS.md controls behavior

→ Claude reads, acts, verifies, updates, stops

→ Tomorrow it continues from where it left off

→ You review outputs, not prompts

The bottleneck shifts from generating work to reviewing work.

That's the real leverage.

You're not asking Claude better questions.

You're designing a system that keeps working without you.

10 loops you can build this week

→ Daily project review — reads workspace, writes summary

→ Meeting follow-up extractor — turns notes into action items

→ Folder cleanup planner — organizes, proposes, doesn't touch

→ CI failure triage — reads logs, classifies failures, drafts investigation

→ GitHub issue summarizer — reads open issues, groups by theme

→ PR review assistant — reads diff, flags potential issues

→ Newsletter research loop — gathers sources, drafts summaries

→ Documentation gap finder — reads docs, flags missing sections

→ Daily standup drafter — reads PROGRESS.md, writes standup

→ Weekly retrospective loop — reviews the week, identifies patterns

Every one of these starts with the same 4-file system.

The only thing that changes is TASK.md and LOOP_INSTRUCTIONS.md.

If this was useful:

→ Repost to share it with every developer using Claude

→ Follow @sairahul1 for more systems that work without you

→ Bookmark this — the templates are copy-paste ready

Subscribe to theaibuilders.co for more such interesting articles

I write about AI, building products, and automation systems.