Loop Engineering Goal Generator

How the Loop Goal Generator Works

Fill in the objective plus 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.

Generated Loop Outputs

/goal Fix the failing CI checks for this pull request with the smallest safe change.
 
Work toward this goal until all validation checks pass or the stop rule is reached.
 
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:
This is a TypeScript project. Prefer small focused changes. Read existing patterns before editing.
 
Validation:
pnpm lint
pnpm test
pnpm build
 
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:
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.
 
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.

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.

Loop Engineering Best Practices

• 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.