Stop Using Claude as a One-Shot Calculator: Building Reusable Workflows with Claude Loops

Most people still interact with Claude in a one-shot pattern. You write a prompt. Claude responds. The session ends. The next day, you rebuild the exact same context from scratch.

That works fine for isolated tasks. But for repetitive work—daily code reviews, CI triage, project monitoring, meeting follow-ups—rebuilding context daily isn’t a workflow. It’s manual labor with AI sprinkles on top.

The better abstraction is a loop.

What a Claude Loop Actually Is (And Why It’s Not Just “Asking Again”)

A Claude Loop is not simply “asking Claude a second time.” It is a repeatable workflow structure built around the model that defines what triggers the run, what context Claude reads before acting, what actions it’s allowed to take, how outputs are verified, where state is stored, and when to stop or escalate to a human.

The model still handles the reasoning. The loop provides the operating framework.

This distinction matters because Claude sessions are temporary. Without a loop, every execution starts from zero. With a loop, Claude reads what happened previously and continues from that exact point.

A complete loop contains six parts. Skip one, and the whole thing breaks:

• Trigger: What starts the run. A manual command, scheduled timer, file change, CI failure, or Git event.
• Context: What Claude reads before acting. Task definitions, previous progress, project files, and instructions.
• Action: What Claude actually does. Writing a report, drafting a fix, classifying failures, or updating a document.
• Verification: How you check the result. Checklists, test suites, required sections, or safety boundary checks.
• State Update: What gets remembered for next time. Updating PROGRESS.md, recording blockers, and guiding the next run.
• Decision: Stop, repeat, or escalate to a human.

Skip verification, and the loop trusts itself blindly. Skip state updates, and every run resets to zero. Skip the decision step, and the loop never knows when to stop.

You Don’t Need Heavy Infrastructure: 4 Files Are All It Takes

You do not need a complex backend or heavy infrastructure to get started. You need a folder and four files.

my-loop/
├── TASK.md
├── LOOP_INSTRUCTIONS.md
├── PROGRESS.md
└── outputs/
    └── 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 is allowed to do, and how it verifies success.
• PROGRESS.md: The memory. What happened last time, what’s blocked, and what the next run should focus on.
• outputs/: Where Claude writes results. The path is predictable, the content is inspectable, and the operation is safe.

Claude reads these files at the start of every run and updates them at the end. The next run picks up exactly where the last one stopped. This persistence outside the chat window is what separates a loop from a repeated prompt.

Writing TASK.md: How to Prevent Claude from Overstepping

TASK.md tells Claude the purpose of the loop. Keep the descriptions high-level. Operating details belong in LOOP_INSTRUCTIONS.md.

Use this template:

# Daily Project Review Loop

## Goal

Review this project folder, summarize what changed,
identify blockers, and produce a short daily review report.

## Expected Output

Each run should produce or update:

- `outputs/daily-review.md`
- `PROGRESS.md`

## Scope

Claude may inspect files in this workspace and write
reports to the `outputs/` folder.

Claude should NOT:

- Modify source files
- Delete or rename files
- Send messages or open tickets

Pay close attention to the “Claude should NOT” section. The first version of any loop must include explicit forbidden actions. This isn’t about distrusting the model; it’s standard engineering practice. You draw the boundary.

Why PROGRESS.md Is the Most Important File in the System

Without PROGRESS.md, every run starts from scratch. With it, Claude knows what happened previously and continues logically.

This structure works reliably in practice:

# Loop Progress

## Current State

- Status: Active
- Main objective: Daily project review
- Current focus: [what matters right now]
- Last updated: [date]

## Last Run

- Date:
- Summary:
- Files reviewed:
- Output produced:

## Open Items

-

## Blockers

-

## Needs Human Review

-

## Next Run Should

-

## Decisions Made

-

## Do Not Repeat

-

Two sections here are critical. “Do Not Repeat” stops Claude from retrying actions that have already failed, preventing infinite loops. “Needs Human Review” halts the loop when it shouldn’t continue silently.

There are two strict rules for maintaining this file. If Claude needs the information to decide its next action, keep it in PROGRESS.md. If you merely want a historical record, move it to outputs/history/. A state file that grows indefinitely becomes useless noise. Treat it as a control panel, not an archive.

LOOP_INSTRUCTIONS.md: Drawing the Guardrails and the Failure Policy

This file acts as the control layer wrapped around Claude. It dictates exactly what to read, what to write, what to avoid, and how to verify the result before stopping.

# Loop Instructions

You are running a daily project review loop.

## Before You Start

1. Read `TASK.md`
2. Read `PROGRESS.md`
3. Inspect the project folder
4. Identify what changed, what's incomplete, what needs human review

## What You Should Do

Write a short daily review to `outputs/daily-review.md` including:

- Summary of current state
- Files reviewed
- Meaningful changes
- Blockers or unresolved questions
- Recommended next actions

After writing, update `PROGRESS.md` with:

- Date of this run
- Summary of what happened
- Files checked
- What the next run should do
- Whether human review is needed

## Safety Rules

- Do not delete files
- Do not rename or move files
- Do not modify source files
- Only write to `outputs/daily-review.md` and `PROGRESS.md`
- If unsure whether an action is allowed → stop and ask

## Verification Checklist

Before ending the run, confirm:

- `outputs/daily-review.md` exists with all required sections
- `PROGRESS.md` was updated
- No files outside allowed paths were modified

## Failure Policy

If verification fails:

1. Missing section in report → fix once
2. PROGRESS.md not updated → update once
3. Forbidden file modified → stop immediately
4. Same check fails twice → mark as needing human review

Look at the Failure Policy at the bottom. Most loops lack one entirely. When something goes wrong, Claude improvises. That is exactly where loops create massive problems. You must define the failure path explicitly.

Don’t Schedule Yet. Run It Manually Five Times First

Do not set up a cron job or schedule yet. Run it manually first.

Open the folder in Claude Code or Claude Desktop/Cowork and use this prompt:

Run the daily project review loop for this workspace.

Follow `LOOP_INSTRUCTIONS.md` exactly.

Before acting, read:
- `TASK.md`
- `PROGRESS.md`
- `LOOP_INSTRUCTIONS.md`

Then inspect the workspace, write the daily review to
`outputs/daily-review.md`, update `PROGRESS.md`,
run the verification checklist, and report what changed.

Do not modify any files except
`outputs/daily-review.md` and `PROGRESS.md`.

After the run, check two things: does outputs/daily-review.md contain a structured report with all required sections, and was PROGRESS.md actually updated with next-run guidance?

If both look correct, run it three to five more times. Introduce small changes—add a notes file, inject a blocker into PROGRESS.md, tweak something in the workspace. Each run should absorb these changes without restarting from zero. That continuity is the entire point.

The Verification Step: The Boring Part That Prevents Loop Disasters

There is a failure mode nobody talks about. Claude runs the loop, says it is done, updates the state, and stops. On the surface, 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 touched. You only find out when something downstream breaks.

That is why verification exists. A loop should not stop because Claude says “I’m finished.” It stops because a concrete condition was checked and passed.

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. You can merge them later, but during early testing, keep them isolated. A verifier needs a pass/fail standard. “Look at this and tell me if it seems okay” is not a verifier. “Check these seven conditions and mark the run as accepted only if all seven pass” is a verifier.

/loop vs /goal: When to Use Which Scheduling Command

Once the loop runs reliably by hand, schedule it. In Claude Code, use /loop:

/loop 24h Run the daily project review loop for this workspace.

Follow `LOOP_INSTRUCTIONS.md` exactly.
Read `TASK.md` and `PROGRESS.md` first.
Write the report to `outputs/daily-review.md`.
Update `PROGRESS.md` before stopping.
Run the verification checklist.
If no meaningful changes → keep the report short.
If human review needed → mark clearly in `PROGRESS.md`.
Do not modify any files except `outputs/daily-review.md`
and `PROGRESS.md`.

Interval options include /loop 15m (testing cadence), /loop 1h (hourly monitoring), /loop 24h (daily review), and /loop 7d (weekly cleanup).

Understand that /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.

You also need to know about /goal:
/loop means run again because time passed.
/goal means keep running until a condition is met.

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

Use /loop for time-based work like daily reviews. Use /goal for completion-based work like running until tests pass or writing until all sections are complete.

The Permission Ladder: Don’t Let Your Loop Push Code on Day One

This is where most loops go wrong. People build a loop that works, then immediately grant it excessive permissions. The loop posts directly to Slack, pushes code without review, or closes tickets automatically. Then something breaks, and you have a mess on your hands.

Use the permission ladder instead:

• Level 1 — Read Only: Claude reads files, tickets, logs, and issues.
• Level 2 — Draft Outputs: Claude writes only to the outputs/ folder. Reports, plans, recommendations. Nothing external.
• Level 3 — Sandbox Edits: Claude modifies files inside an isolated branch or worktree.
• Level 4 — Draft External Actions: Claude prepares a PR, Slack message, or ticket update, but does not send or merge it.
• Level 5 — Human-Approved Actions: Claude applies changes only after explicit approval.
• Level 6 — Automated Low-Risk Actions: Claude completes narrowly scoped tasks automatically, with logs, limits, and rollback capabilities.

Your first loop should live at Level 1 or Level 2. That isn’t weakness. It is engineering discipline. Loops at these levels are still enormously valuable. Claude can inspect your GitHub issues, read CI failures, review PRDs, and summarize everything without touching a single important file. Prove the loop works at Level 2 first. Then decide if it has earned Level 3.

5 Ways Claude Loops Fail (And How to Dodge Them)

Look at a 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 touch.

Now look at a 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.

Loops usually fail for five reasons: scheduling before manual testing, missing state files so every run restarts from zero, lacking verification so the loop trusts itself, having no failure policy so bad outcomes trigger improvisation, and adding too many tools too early so the blast radius expands. Fix all five before you type your first /loop command.

Connecting External Tools: Lock Down Permissions Before You Integrate

Once your local loop is stable, you can extend it to GitHub, Slack, Linear, Jira, or CI logs. But every new tool expands the blast radius.

Stick to the same principle: read first, draft second, write only after repeated successful runs. Tool-specific rules belong in LOOP_INSTRUCTIONS.md:

## Tool Permissions Policy

### GitHub

Allowed:
- Read open issues
- Read pull request status
- Read CI status
- Draft summary in `outputs/github-review.md`

NOT allowed:
- Push commits
- Merge pull requests
- Close issues
- Comment publicly without approval

### Slack

Allowed:
- Draft message in `outputs/slack-update.md`

NOT allowed:
- Send messages
- Mention users
- Post to channels

### Linear/Jira

Allowed:
- Read assigned tickets
- Draft suggested updates

NOT allowed:
- Change status
- Close tickets
- Create tickets without approval

If a tool isn’t listed, Claude should stop and ask for human review. This protects you from the loop executing actions you didn’t anticipate.

The End-to-End Setup Process from Scratch

Tying it all together, the practical execution path looks like this:

First, create the directory and files:

mkdir my-loop && cd my-loop
mkdir outputs
touch TASK.md LOOP_INSTRUCTIONS.md PROGRESS.md

Second, fill the files using the templates provided above.

Third, run the execution prompt manually.

Fourth, run the verification prompt manually.

Fifth, introduce small changes and run manually three to five more times.

Sixth, add scheduling with /loop 24h.

Seventh, review the first week of scheduled outputs before fully trusting it.

The bottleneck shifts from generating work to reviewing work. That is the real leverage. You aren’t asking Claude better questions. You are designing a system that keeps working without you.

10 Practical Claude Loops You Can Build This Week

All of these start with the exact same four-file system. The only variables are the contents of TASK.md and LOOP_INSTRUCTIONS.md:

• Daily Project Review: Reads the workspace, writes a summary.
• Meeting Follow-Up Extractor: Turns meeting notes into action items.
• Folder Cleanup Planner: Organizes and proposes changes without moving anything.
• CI Failure Triage: Reads logs, classifies failures, drafts investigation steps.
• GitHub Issue Summarizer: Reads open issues and groups them by theme.
• PR Review Assistant: Reads diffs and flags potential issues.
• Newsletter Research Loop: Gathers sources and drafts summaries.
• Documentation Gap Finder: Reads docs and flags missing sections.
• Daily Standup Drafter: Reads PROGRESS.md and writes a standup update.
• Weekly Retrospective Loop: Reviews the week’s progress and identifies patterns.

Practical Summary / Action Checklist

• [ ] Create a my-loop/ directory containing TASK.md, LOOP_INSTRUCTIONS.md, PROGRESS.md, and an outputs/ folder.
• [ ] Define the goal, expected output, and explicit “do not” rules in TASK.md.
• [ ] Reserve the “Needs Human Review” and “Do Not Repeat” sections in PROGRESS.md.
• [ ] Write a hard-coded Failure Policy at the bottom of LOOP_INSTRUCTIONS.md.
• [ ] Execute the loop manually using the execution prompt.
• [ ] Run a separate, isolated verification prompt.
• [ ] Introduce minor workspace changes and run manually three to five times to confirm continuity.
• [ ] Keep permissions strictly at Level 1 (Read Only) or Level 2 (Draft Outputs).
• [ ] Schedule using /loop 24h or /goal only after manual testing passes.
• [ ] Audit the scheduled outputs for the first week before trusting the system.

One-Page Overview

A Claude Loop is a six-step, repeatable workflow structure (Trigger, Context, Action, Verification, State Update, Decision) built around the model. It extracts session memory from the chat window into a local file system using four specific files: TASK.md, LOOP_INSTRUCTIONS.md, PROGRESS.md, and outputs/. The core principles are to test manually before scheduling, treat the state file as a live control panel rather than an archive, base verification on rigid checklists rather than vibes, start permissions at read-only or draft-only levels, and explicitly define failure paths.

FAQ

What is the actual difference between a Claude Loop and just sending the same prompt every day?
Sending the same prompt starts from zero every time. A Claude Loop reads PROGRESS.md and continues directly from the previous run’s context.

Will PROGRESS.md get too large and consume my entire context window?
It can, which is why you only keep information required for the next decision in PROGRESS.md. Move pure historical records to outputs/history/. Treat it as a control panel, not a database.

Why shouldn’t I connect Slack or GitHub on the very first version?
Every external tool integration increases the blast radius if the loop fails. You need to prove the loop operates safely at a local, read-only level before granting it access to external systems.

When should I use /loop versus /goal in Claude Code?
Use /loop for time-based tasks like a daily morning review. Use /goal for completion-based tasks where the loop should run continuously until a specific condition is met, like all tests passing.

Can I combine the execution step and the verification step into one prompt?
Not during early testing. Keeping them isolated ensures your verification standard remains objective. If Claude executes and verifies its own work in one pass, it tends to pass itself regardless of actual quality.

What happens if Claude silently modifies a file it wasn’t supposed to touch?
Your LOOP_INSTRUCTIONS.md must contain a Failure Policy. If the verification step detects a modified forbidden file, the policy should dictate an immediate stop and a flag for human review.

What is the safest first loop I can build today?
A daily project review or meeting note extractor. Have it read your local workspace files and write a summary to the outputs/ folder. It shouldn’t touch source files or connect to any external APIs.