Codex Project Context Loop
A planning loop that turns a broad request into a precise long-running Codex objective that is easier to audit.
Use loop copies the kickoff prompt. Copy Markdown and Download loop include the complete Markdown page with context, source attribution, anchors, and guardrails. Cursor / Claude Code buttons prepare the shorter kickoff prompt only.
Supported agents
Goal
Create an audit-friendly agent objective before implementation.
Feedback gate
find . -maxdepth 2 -type f | sort | head -100Stop condition
The goal is concrete enough for an agent to execute and for a reviewer to audit.
Give the agent these inputs before it starts the loop. This keeps discovery bounded and prevents vague retries.
The loop assumes these commands or integrations are available. Missing tools should be reported as blockers, not ignored.
Two separate pieces: the kickoff prompt starts the loop, while the downloaded Markdown carries the complete reference page.
1. Copy or download
Use the kickoff for a fast agent run. Download the full Markdown when you need source, context, and attribution in one file.
2. Paste into the agent
Start a fresh agent session in the target repo and provide the requested project context if the loop asks for it.
3. Let it self-pace
The agent should act, check evidence, retry only when the gate fails, and stop at the stated exit condition.
The diagram shows the order. This checklist keeps only the action, command, and failure handling needed during a real pass.
1. Read project signals
Inspect scripts, docs, and architecture before writing the objective.
2. Define scope
State what to change and what not to change.
3. Define done criteria
List tests, build, SEO, SSR, and packaging requirements.
4. Define stop-if rules
State when the agent must stop instead of guessing.
This is the text copied by Use loop. It is intentionally shorter than the Markdown export.
Inspect the project context and write a strict, audit-friendly implementation objective with scope, constraints, done criteria, verification, and stop-if rules.
Goal: Create an audit-friendly agent objective before implementation.
Check command: find . -maxdepth 2 -type f | sort | head -100
Exit condition: The goal is concrete enough for an agent to execute and for a reviewer to audit.
Max iterations: 2
Guardrails:
- Do not weaken, skip, delete, or rewrite the validation command to force success.
- Do not claim completion until the stated exit condition is actually satisfied.
- If blocked, report the blocker, evidence, and next safest action instead of gaming the metric.
- Do not write a goal that allows vague completion or unverified claims.Quality
86/100
Safety
92/100
Expected output
A structured objective with scope, constraints, done criteria, verification, and stop-if rules.
Related loops
Browse allAGENTS.md Improvement Loop
Audit and improve repository agent instructions so future AI sessions follow project conventions and verification rules.
Kickoff preview
Audit repository agent instructions against actual project files, then improve them with accurate commands, architecture rules, and verification expectations. Goal: Make repository instructions accurate, actionable, and verification-oriented. Check command: ls -la && rg -n "build|test|lint|deploy" README.md package.json AGENTS.md CLAUDE.md Exit condition: Agent instructions state stack, commands, architecture rules, and verification expectations accurately. Max iterations: 3 Guardrails: - Do not weaken, skip, delete, or rewrite the validation command to force success. - Do not claim completion until the stated exit condition is actually satisfied. - If blocked, report the blocker, evidence, and next safest action instead of gaming the metric. - Do not invent commands, tools, or architecture claims that are not present in the repository.
Independent Verifier Pass
Review an agent-produced change as a skeptical verifier before it is marked done.
Kickoff preview
Act as an independent verifier. Restate the requirements, inspect the diff, run relevant checks, and return a pass/fail/blocker verdict with evidence. Goal: Prove the implementation satisfies the request without relying on the implementer’s claim. Check command: git diff --stat && git diff --check Exit condition: The verifier can map each requirement to code and verification evidence. Max iterations: 3 Guardrails: - Do not weaken, skip, delete, or rewrite the validation command to force success. - Do not claim completion until the stated exit condition is actually satisfied. - If blocked, report the blocker, evidence, and next safest action instead of gaming the metric. - Do not rubber-stamp. Find at least one plausible failure mode and check it.
Build Until Passing
Run the production build, fix compile/runtime bundling failures, and stop only when the build succeeds.
Kickoff preview
Run the production build, fix root causes while preserving project architecture, and repeat until the build passes. Goal: Make the production build succeed for the target runtime. Check command: pnpm build Exit condition: The production build command exits successfully. Max iterations: 6 Guardrails: - Do not weaken, skip, delete, or rewrite the validation command to force success. - Do not claim completion until the stated exit condition is actually satisfied. - If blocked, report the blocker, evidence, and next safest action instead of gaming the metric. - Do not hide build failures with dynamic imports or environment checks unless that is the correct runtime boundary.
Ship PR Until Green
Implement a scoped change, open or update a pull request, inspect CI, and continue until all required PR checks pass.
Kickoff preview
Take this branch to a green pull request. Implement the requested change, run local verification, open or update the PR, run `gh pr checks`, inspect failures, fix root causes, and repeat until every required check passes or you hit the iteration cap. Goal: Open or update a pull request and stop only when all required PR checks are green. Check command: gh pr checks Exit condition: All required pull request checks are successful and the PR is ready for review or merge. Max iterations: 10 Guardrails: - Do not weaken, skip, delete, or rewrite the validation command to force success. - Do not claim completion until the stated exit condition is actually satisfied. - If blocked, report the blocker, evidence, and next safest action instead of gaming the metric. - Do not disable required checks, edit loops to skip jobs, or remove tests to make CI green. - Do not merge the PR unless the user explicitly asked for merge authority.