Loop Prompt Generator

Loop engineering is the practice of designing an AI agent workflow that repeats work, checks evidence, and stops under a defined condition. A useful loop names the task, limits its scope, states how to verify progress, and sets a hard cap on attempts or turns. For coding work, evidence might include a test command returning exit code 0, a clean lint run, a successful build, or a specific file change. The term describes workflow design, not a guarantee that an agent will solve every task. PromptMake helps you write the command and control rules; Claude Code or Codex performs the work after you paste the output there.

Use /goal for a finish line that an evaluator can check after each turn. The agent works through consecutive turns until the success condition passes, the turn cap is reached, or you cancel. Use /loop for a prompt that should run again on a time interval, such as checking CI every five minutes or polling a deployment. A scheduled /loop does not mean “keep fixing until done”; it means “repeat this instruction on a schedule.” If the task has a measurable end state, choose /goal. If time triggers the next run, choose /loop. PromptMake can also produce turn-based guidance when you want to review each cycle yourself.

A turn-based loop divides work into explicit cycles while keeping you in control of the next cycle. The agent inspects the current state, makes one bounded change, runs the listed checks, reports the result, and waits for your direction. This pattern fits migrations, risky refactors, production debugging, and work where success requires human judgment. It also helps when your agent tool does not support a native /goal or /loop command. PromptMake writes a repeatable per-turn instruction block with verification and stop rules. You paste it into Claude Code or Codex, review each result, and decide whether to continue, revise the prompt, or stop.

Write criteria that a command or direct inspection can prove. “All tests pass with exit code 0,” “npm run build completes,” and “the API returns HTTP 200 with the required fields” give an evaluator evidence. “Improve the code,” “make it robust,” and “fix everything” do not. Use a verification ladder: start with the narrowest relevant check, then run broader tests, lint or type checks, a build, and a final diff review. Include negative checks when they matter, such as no changed database schema or no new lint warnings. The strongest criterion describes the exact command, expected result, and any files or behavior that must remain unchanged.

A turn cap limits cost and prevents an agent from repeating an unproductive strategy. Even a clear goal can become unreachable because of missing credentials, a broken dependency, flaky tests, an unavailable service, or an incorrect assumption in the task. Set the cap according to scope: a small test fix may need five turns, while a contained refactor may need fifteen. A higher number does not make the workflow better. Ask the agent to stop early when the evaluator identifies an external blocker or repeated failure. When the cap is reached, inspect the transcript and diff before starting a revised goal with better constraints.

The evaluator reviews the evidence produced during the agent turn and decides whether the stated goal has been met. It needs observable proof in the conversation, such as test output, a build result, or a concise report of a file check. It cannot reliably judge facts that the worker never exposes. A separate evaluator can reduce self-grading bias, but it still depends on the condition you wrote and the evidence it receives. Require the worker to run the verification commands and include their results. Do not use “the agent says it is done” as the stop condition. For high-risk changes, review the final diff and run checks yourself.

Skip autonomous loops when the task has no objective finish line, requires taste or product judgment, can trigger irreversible production changes, or depends on permissions the agent lacks. Do not loop destructive database operations, security-sensitive account changes, payments, legal decisions, or open-ended rewrites without human checkpoints. A loop also adds little value to a one-step edit you can verify at once. Use a turn-based workflow for ambiguous requirements and stop after each bounded change. Before a longer run, test the prompt on a read-only inspection or a small branch. Keep backups and version control in place, and require approval before deploys or data changes.

Token use depends on the model, repository size, tool output, number of turns, and how much context each cycle reads again. A poorly scoped loop can consume far more tokens than a single coding request because every cycle may inspect files, run commands, process logs, and evaluate the result. Reduce burn with a narrow directory scope, targeted tests, short command output, explicit exclusions, and a conservative turn cap. Stop when two or three turns repeat the same failure without new evidence. PromptMake does not pay for or control Claude Code or Codex usage. Check the pricing and usage limits of the agent platform where you run the generated command.

It belongs to the same family of iterative agent workflows. The Ralph pattern commonly feeds a task back to a coding agent across repeated runs, often with fresh context, repository state, tests, and a completion signal guiding the next attempt. PromptMake does not install or run a Ralph script. It generates a smaller, portable control document: the command, measurable success criteria, turn cap, verification steps, and stop guidance. You can use that output as a starting brief for a Ralph-style setup, but you still need to configure the runner, model, permissions, context handling, and safety controls in your own environment.

Yes, but command syntax and available controls differ. Claude Code users can select output aimed at native /goal, scheduled /loop, or a manual turn-based cycle. For Codex, PromptMake keeps the same verify-first structure and produces instructions you can adapt to the Codex CLI or agent workflow you use. Do not paste a Claude-specific slash command into another tool and assume it has the same behavior. Check that tool’s current command reference, permissions, sandbox, and approval settings. Across both platforms, keep the finish line mechanical, expose verification output, cap the work, and review the final diff before you merge or deploy.

You can try it without paying. Guests receive 3 generations per day without an account. Registered free users receive 5 generations per day. PromptMake Pro costs $9 and removes the small free-tier allowance for regular use. These limits apply to generating the loop command and verification plan on PromptMake. They do not include model calls, tokens, or subscription costs charged by Claude Code, Codex, or another agent platform. PromptMake does not bundle execution credits for those services. Review the generated output before use, especially when a command could modify many files, access external systems, or run for several turns.

No. PromptMake generates text only. It returns a recommended primitive, a paste-ready command or instruction block, success criteria, a turn cap, verification steps, and stop or abort guidance. It does not open your repository, execute shell commands, schedule recurring jobs, call Claude Code, call Codex, or watch the loop after you leave the page. Copy the output into your chosen agent tool and run it in an environment you control. You remain responsible for repository access, model charges, command approvals, monitoring, cancellation, and review. Treat generated commands as drafts and check every path, test command, interval, and destructive operation before execution.