Skip to content
Loop Engineering
Loop Engineering Tools

Loop Goal Generator for Claude Code, Codex, and More

Create a copyable goal for six agent environments with validation evidence, stop rules, budget limits, fallback steps, and a human approval gate built in.

How the Loop Goal Generator Works

Fill in the design hypothesis, smallest useful run, objective, and the five moves of the loop: discovery, handoff, verification, persistence, and scheduling. Every output is rebuilt instantly in your browser — no code runs and nothing connects to your repositories. Switch tabs to copy the format your tool expects.

If the task is still vague, read how to build a first reviewable loop or run the readiness score before copying an output.

Discovery: what the loop reads before it starts.
Handoff: who or what receives the work.
Verification: how the result is checked, preferably by a separate reviewer.
Persistence: what gets saved for the next pass.
Scheduling: when the loop runs again, or when a human restarts it.

Generated Loop Outputs

Changing task type replaces workflow fields after confirmation.

Require human approval before merge / deploy
Ready to copy
claude-goal.txt
/goal Fix the failing CI checks for this pull request with the smallest safe change.
 
Task type: CI Fix
Target tool: Claude Code
 
Work toward this goal until all validation checks pass or the stop rule is reached.
 
Design hypothesis:
A small, isolated CI fix loop can repair this pull request faster than a broad manual investigation, as long as validation and review stay separate.
 
Smallest useful run:
Run one pass against the latest failing CI job only. Do not expand to unrelated lint warnings, refactors, or cleanup work.
 
Loop cycle:
1. Discovery — Read the latest CI failure, related pull request comments, and recent commits before choosing the next action.
2. Handoff — Assign the work to one coding agent in an isolated branch or worktree. Keep the final merge decision with a human reviewer.
3. Verification — A separate reviewer checks the diff, confirms validation results, and rejects shortcuts such as deleting tests or weakening checks.
4. Persistence — Write a short run note with the error seen, files changed, checks run, and the next recommended action.
5. Scheduling — Run manually for each failing pull request. Move to a scheduled check only after the loop is reliable.
 
Context:
Prefer small focused changes. Reproduce the current failure and read existing project patterns before editing.
 
Validation:
Run the exact failing command first, then run the project's complete required checks.
 
Validation evidence:
Capture the failing command before the fix, the passing command after the fix, and a short note explaining what changed.
 
Independent checker:
A separate reviewer checks the diff, confirms validation results, and rejects shortcuts such as deleting tests or weakening checks.
 
Boundaries:
Do not delete tests.
Do not bypass lint or type checks.
Do not modify unrelated files.
Do not merge without human approval.
 
Stop rule:
Stop when all validation commands pass, or after 5 failed iterations.
Maximum iterations: 5
 
Budget:
Example only: stop before exceeding the agreed per-run token budget.
 
Human approval:
Required before merge, deploy, delete, purchase, or external communication.
 
Fallback:
If blocked, summarize the current errors, attempted fixes, and recommended human decision.
 
Loop Validation Log:
- Hypothesis: A small, isolated CI fix loop can repair this pull request faster than a broad manual investigation, as long as validation and review stay separate.
- Smallest useful run: Run one pass against the latest failing CI job only. Do not expand to unrelated lint warnings, refactors, or cleanup work.
- Expected evidence: Capture the failing command before the fix, the passing command after the fix, and a short note explaining what changed.
- Actual evidence: [fill in after the run]
- Passed? [yes / no / partial]
- Feedback: After the run, note whether the hypothesis held, what slowed the loop down, and what should change before the next pass.
- Next step: [stop / adjust the loop / run the next pass]
 
Do not delete tests, bypass checks, or modify unrelated files just to satisfy the validation condition. If blocked, stop and summarize the blocker, attempted fixes, and recommended next action.
This generator does not run agents, execute code, or connect to your repositories. It only creates copyable loop prompts and configuration skeletons.Send feedback
Reviewed 2026-07-14

Complete rendered examples

These PR Review and Bug Fix examples are generated from the same presets and rendering functions used by the live form. They show the actual evidence, stop, fallback, and approval language each output receives.

First-hand rendered example · Claude Code /goal

PR Review example

Objective
Monitor one pull request and produce an evidence-backed readiness report until it is ready for human approval or a blocker must be escalated.
Validation
Confirm required checks, unresolved review threads, requested changes, merge conflicts, and branch-protection requirements from current pull request state.
Stop rule
Stop for human approval when all required conditions are satisfied. Stop and escalate when the same unchanged blocker remains after 4 checks.
Fallback
If current state cannot be fetched or interpreted, report the missing permission or ambiguous requirement and ask a human to decide.
Rendered output
/goal Monitor one pull request and produce an evidence-backed readiness report until it is ready for human approval or a blocker must be escalated.

Task type: PR Review
Target tool: Claude Code

Work toward this goal until all validation checks pass or the stop rule is reached.

Design hypothesis:
A bounded review-monitoring loop can surface the next real blocker faster than repeated manual checks, while keeping approval and merge decisions with a human.

Smallest useful run:
Inspect one pull request once: current required checks, unresolved review threads, requested changes, and merge state.

Loop cycle:
1. Discovery — Read the current pull request state, required checks, review decisions, unresolved threads, and commits added since the last run.
2. Handoff — Give each concrete code issue to a coding agent in an isolated branch or worktree; keep review decisions and merge authority separate.
3. Verification — A read-only reviewer confirms that every readiness claim maps to current pull request evidence and that no blocker was dismissed without proof.
4. Persistence — Save a compact run note containing the observed state, changes since the prior run, open blockers, and the next safe action.
5. Scheduling — Run manually or after a pull request event. Avoid fixed polling until the event-driven flow is proven reliable.

Context:
Treat the hosting platform as the source of truth. Re-read live state each pass and distinguish a code blocker from permissions, policy, or infrastructure.

Validation:
Confirm required checks, unresolved review threads, requested changes, merge conflicts, and branch-protection requirements from current pull request state.

Validation evidence:
Record check names and results, unresolved thread links, current review decision, mergeability, and the time of observation.

Independent checker:
A read-only reviewer confirms that every readiness claim maps to current pull request evidence and that no blocker was dismissed without proof.

Boundaries:
Do not merge or approve the pull request.
Do not dismiss reviews or change branch protection.
Do not treat stale status as current.
Do not hide unresolved blockers.

Stop rule:
Stop for human approval when all required conditions are satisfied. Stop and escalate when the same unchanged blocker remains after 4 checks.
Maximum iterations: 4

Budget:
Example only: stop after four state checks or the agreed per-run token cap, whichever comes first.

Human approval:
Required before merge, deploy, delete, purchase, or external communication.

Fallback:
If current state cannot be fetched or interpreted, report the missing permission or ambiguous requirement and ask a human to decide.

Loop Validation Log:
- Hypothesis: A bounded review-monitoring loop can surface the next real blocker faster than repeated manual checks, while keeping approval and merge decisions with a human.
- Smallest useful run: Inspect one pull request once: current required checks, unresolved review threads, requested changes, and merge state.
- Expected evidence: Record check names and results, unresolved thread links, current review decision, mergeability, and the time of observation.
- Actual evidence: [fill in after the run]
- Passed? [yes / no / partial]
- Feedback: Note whether the run found new information, repeated an unchanged state, or exposed a rule that should be encoded for later runs.
- Next step: [stop / adjust the loop / run the next pass]

Do not delete tests, bypass checks, or modify unrelated files just to satisfy the validation condition. If blocked, stop and summarize the blocker, attempted fixes, and recommended next action.
First-hand rendered example · Codex goal

Bug Fix example

Objective
Reproduce one reported bug, fix its root cause with the smallest relevant change, and prove the behavior before and after.
Validation
Run the reproduction before and after the change, then run all project checks affected by the modified area.
Stop rule
Stop when the reproduction and required checks pass, or after 5 iterations. Stop earlier after 3 identical failures without new evidence.
Fallback
If the bug cannot be reproduced, report the missing environment or evidence and request a human decision instead of guessing.
Rendered output
/goal Complete the following objective with a clear validation loop:

Task type: Bug Fix
Target tool: Codex

Objective:
Reproduce one reported bug, fix its root cause with the smallest relevant change, and prove the behavior before and after.

Design hypothesis:
A narrow reproduction and the smallest relevant change can fix the reported behavior without changing unrelated product behavior.

Smallest useful run:
Reproduce one reported symptom with one deterministic test or documented sequence before changing code.

Loop cycle:
- Discovery: Read the report, affected code, recent related changes, and existing tests; identify the earliest point where actual behavior diverges from expected behavior.
- Handoff: Give the reproduced case and bounded file scope to one coding agent in an isolated branch or worktree.
- Verification: A separate reviewer confirms the fix addresses the reproduced root cause, covers the edge case, and does not weaken the test.
- Persistence: Record the reproduction, root cause, files changed, checks run, and any residual risk.
- Scheduling: Run once for the reported bug. Re-run only when new evidence or a changed reproduction is available.

Context:
Preserve current public behavior outside the reproduced case. Prefer a regression test that fails before the fix and passes after it.

Done when:
Run the reproduction before and after the change, then run all project checks affected by the modified area.

Validation evidence:
Save the failing reproduction, root-cause note, passing reproduction, relevant project checks, and reviewed diff.

Independent checker:
A separate reviewer confirms the fix addresses the reproduced root cause, covers the edge case, and does not weaken the test.

Constraints:
Do not change unrelated behavior.
Do not weaken or delete the reproducer.
Do not expand into a refactor without approval.
Do not merge without human review.

Stop conditions:
- Stop when all validation checks pass.
- Stop when the reproduction and required checks pass, or after 5 iterations. Stop earlier after 3 identical failures without new evidence.
- Stop after 5 failed iterations.
- Stop before exceeding this budget: Example only: stop at five implementation attempts or the agreed per-run token cap.

Human approval:
Required before merge, deploy, delete, purchase, or external communication.

Fallback:
If the bug cannot be reproduced, report the missing environment or evidence and request a human decision instead of guessing.

Loop Validation Log:
- Hypothesis: A narrow reproduction and the smallest relevant change can fix the reported behavior without changing unrelated product behavior.
- Smallest useful run: Reproduce one reported symptom with one deterministic test or documented sequence before changing code.
- Expected evidence: Save the failing reproduction, root-cause note, passing reproduction, relevant project checks, and reviewed diff.
- Actual evidence: [fill in after the run]
- Passed? [yes / no / partial]
- Feedback: State whether the reproduction was sufficient and what future signal would catch this class of bug earlier.
- Next step: [stop / adjust the loop / run the next pass]

How Claude Code /goal Actually Works

Per the official Claude Code docs, /goal sets a completion condition and Claude keeps working across turns until it is met. These facts shape how to write the generated prompt above:

  • After each turn a small fast model (Haiku by default) checks whether the condition holds.
  • The evaluator does not run commands or read files — it only judges what Claude surfaces in the conversation, so make validation results land in the transcript.
  • Bound a goal by adding a turn or time clause to the condition, e.g. “or stop after 20 turns”.
  • A condition can be up to 4,000 characters; /goal requires Claude Code v2.1.139+.
  • Codex guidance: name one objective and one stopping condition — “Codex should know what ‘done’ means before it starts.”
  • Recommended /goal use cases include migrating a module until call sites compile and tests pass, and large refactors.
Sourced from the official docs: Claude Code /goal and Codex follow a goal.

Loop Engineering Best Practices

  • Write the hypothesis before the first run so the loop can teach you something.
  • Keep the first run small enough to inspect manually.
  • Write the goal as an outcome, not a list of steps.
  • Name where the loop discovers work: CI, issues, commits, an inbox, or a saved report.
  • Make the handoff explicit: which agent works, where it works, and who owns the final decision.
  • Make validation machine-checkable: a command, test, score, or artifact.
  • Use a separate checker. The agent that wrote the change should not be the only judge of success.
  • List forbidden actions before the loop runs, not after.
  • Set a hard stop rule and a budget cap up front.
  • Leave a short run note so the next pass does not start from zero.
  • Require human approval before merge, deploy, delete, purchase, or external communication.
  • Define a fallback: what to summarize and escalate when blocked.
This generator does not run agents, execute code, or connect to your repositories. It only creates copyable loop prompts and configuration skeletons.