Claude kept looping forever. So I built a tool to fix the prompt.

The problem with vague Claude sessions

Most people start a Claude session the same way. They describe what they want, paste in some code, and hit enter.

That works for small one-shot tasks. It falls apart the moment the task has more than one step.

The first sign of trouble is usually Claude asking a clarifying question. Then another. Then generating something that is almost right but missing a piece. Then generating a fix for the fix. Each iteration feels like progress but is actually drift — the task definition is shifting underneath you because it was never pinned down.

The second failure mode is the loop that never ends. Claude keeps generating changes, running checks, finding new issues, and looping back. It is not stuck. It just has no exit condition. There is nothing telling it when the task is done.

What a working loop spec needs

Every working agentic loop has four parts. Miss one and the session breaks.

The trigger. What starts the loop? What is the precise task, stated plainly? The trigger should be specific enough that there is only one way to read it.

The task. What should Claude actually do? Not "improve the code" or "fix the bug." Something measurable. "Add a booking calendar component that stores availability in localStorage and renders a 7-day grid."

The sensors. How will the loop know if the output is correct? These are the verification checks: run the tests, check for TypeScript errors, confirm the UI renders. Sensors are what separate a loop from a guess.

The stop condition. When is the task complete? "All sensors pass with zero errors" is a stop condition. "It looks about right" is not.

The Loop Builder walks you through each of these for the specific loop pattern your project needs. It covers eight patterns: goal clarification, scope breakdown, planning, build, test, debug, review, and memory.

A real example: the booking calendar build

Here is what a full loop spec looks like in practice. The project was a booking calendar feature for a SaaS dashboard — let users schedule 1:1 meetings with team members.

Without a spec, the session would have started with something like: "Add a booking calendar to the SaaS dashboard." That is a reasonable English sentence and a terrible task definition. It has no scope, no sensors, and no stop condition.

With the Loop Builder, the same project became this:

Goal Clarification loop

Task: Build a booking calendar so users can schedule 1:1 meetings with team members.
Audience: SaaS dashboard users — goal is to eliminate scheduling back-and-forth.
Before starting, confirm: Who manages availability? What calendar systems must we support? What does a successful booking confirmation look like?

Scope Breakdown loop

Big task: Add a full booking calendar feature to the existing SaaS dashboard.
Scope (in order):

1. Add calendar view component to the dashboard
2. Build availability slot management for each team member
3. Create booking form with email confirmation on submit
4. Add booking management page (view, reschedule, cancel)
5. Integrate with Google Calendar API for sync
6. Add conflict detection to block double-bookings

Test loop

Verification checks:
1. Unit tests: npm test -- --testPathPattern=booking
2. TypeScript check: tsc --noEmit
3. E2E booking flow: npx playwright test booking.spec.ts

Passing result: All tests pass, zero TypeScript errors, E2E booking flow completes without errors.

Debug loop

What is broken: Booking confirmation emails not sending after form submission.
Diagnostic steps:
1. Check if form submission handler fires (add console.log at handler entry)
2. Verify email service env vars are set (SMTP_HOST, SMTP_PORT, SMTP_USER)
3. Check email service logs for delivery errors
4. Test email service directly with a minimal send script
Fix rule: Fix only the broken part. Do not rebuild the form or email service.

That is a complete spec for a real build. Claude knows what to do, in what order, how to verify each step, and what the fix boundary is when something breaks.

The Loop Builder generates this as a single copy-paste system prompt you drop into Claude at the start of the session.

What the tool does not do

The Loop Builder is not a full project management tool. It does not track history, save sessions, or connect to Claude.

It does one thing: helps you write a clear spec before the session starts.

Everything runs in the browser. Nothing is stored outside your tab. When you close it, it is gone. That is intentional. The value is in the thinking, not the storage.

Most projects only need 3 to 5 of the 8 loop patterns. You fill in the ones that apply and skip the rest. The generate button is disabled until at least one pattern is complete. That is also intentional. A partial spec is not a spec.

How to use it

Open the Loop Builder in your browser. You will see eight loop pattern cards: goal clarification, scope breakdown, planning, build, test, debug, review, and memory.

Each card has a LEARN tab (read the example) and a YOUR TURN tab (fill in your project details). Start with LEARN to understand what the loop is asking for. Then switch to YOUR TURN and fill in your details.

Work through the patterns your project actually needs. A weekend build might only need scope breakdown, build, and test. A more complex feature might need all eight.

When you have at least one complete pattern, the generate button activates. Click it to see your system prompt. Copy it or download it as a Markdown file. Paste it into Claude at the start of your session.

That is the whole flow. Read, fill, generate, paste.

Why I built this

I kept running into the same pattern. A Claude session would start well, drift in the middle, and either loop or stop at the wrong point.

Every time I traced it back, the problem was the same: the initial task was not specific enough. Or there were no sensors. Or I had not thought through what "done" actually meant for this particular build.

Writing out the spec manually fixed it every time. The Loop Builder is just that process, structured into a tool so I do not have to remember all eight pattern types every session.

It also forces a useful pause before coding starts. The first build decision is not the stack. It is the cut list. Filling in the loop spec makes you think about what the session actually needs to accomplish before you ask Claude to do anything.