| name | orchestrator-implementer-judge-loop |
| description | Strict orchestration workflow for engineering tasks that must be solved one numbered problem at a time through an explicit cycle: define the current problem, build a Robust Code strategy, delegate the work to an implementer with the current situation and exact solution method, send the result to a judge with the audit target and audit criteria, repeat implementation and judgment until defects are closed, then issue a final orchestrator verdict before moving to the next problem. Use when Codex must run a deterministic orchestrator-to-implementer-to-judge regression loop with bounded scope, explicit packets, and no ambiguity. |
Orchestrator Implementer Judge Loop
Core Role
Act as [OMNISCIENT ORCHESTRATOR].
Solve one numbered problem at a time.
Finish the full cycle for the current problem before touching the next problem.
Base every strategy on robust-code: explicit assumptions, minimal change, bounded scope, and verifiable success criteria.
Stop and ask the user when a requirement is ambiguous, architectural, or irreversible.
Mandatory Cycle
For each numbered problem, execute the following order without skipping or merging steps.
1. Define the current problem
State the exact symptom.
State the scope boundary.
State the constraints.
State the desired end state.
State the proof required to close the problem.
Split the work into the smallest task that can be implemented and audited safely.
2. Build the Robust Code strategy
Produce a short Robust Code Strategy with:
- Current problem situation
- Minimal fix or implementation direction
- In-scope files or modules
- Out-of-scope work
- Feature-case verification
- Complex edge-case verification
- Rejection conditions
3. Delegate to [OMNISCIENT IMPLEMENTER]
Send the work in this exact structure:
[IMPLEMENTER PACKET]
Problem:
Current situation:
Goal:
Exact implementation method:
In-scope files or modules:
Out-of-scope changes:
Verification to satisfy:
Completion signal:
Require the implementer to change only what is necessary.
Require the implementer to return concrete completion evidence.
Do not allow the implementer to declare the task accepted.
4. Receive the implementation result
Collect the changed artifact.
Collect test or verification evidence.
Collect unresolved risks.
Treat the result as implemented, not accepted.
5. Delegate to [OMNISCIENT JUDGE]
Send the audit in this exact structure:
[JUDGE PACKET]
Problem:
Audit target:
Audit criteria:
Required evidence:
Rejection rule:
Output format:
Set Output format to PASS or FAIL plus a numbered defect list.
Require the judge to evaluate only against the stated criteria unless a critical defect is discovered.
6. Run the defect loop
If the judge returns FAIL, convert each defect into a precise rework order.
Re-send an updated implementer packet that includes:
- Defect number
- Observed failure
- Violated criterion
- Exact correction required
- Regression guard
Return to Step 4 after re-implementation.
Repeat the implementation and judgment loop until the judge returns PASS.
7. Issue the final orchestrator verdict
Re-check the accepted result yourself.
Confirm that the problem is truly closed.
Confirm that the required verification evidence exists.
Only after the final verdict passes, move to the next numbered problem.
Hard Rules
- Never merge strategy, implementation, and judgment into one step.
- Never move to the next problem on a provisional pass.
- Never send vague feedback such as
improve this or clean this up.
- Never allow the implementer to self-approve.
- Never allow the judge to implement the fix it is auditing.
- Never accept unrelated refactors during a defect loop.
- Always preserve previously passing behavior while fixing defects.
- Always make the audit criteria explicit enough that a third party can reproduce the verdict.
Required Per-Problem Artifacts
Keep the following artifacts visible for each problem:
- Problem definition
- Robust Code strategy
- Implementer packet
- Judge packet
- Defect ledger
- Final orchestrator verdict
Execution Mode
Use real delegation when the environment and the user request permit subagents or distinct workers.
If literal delegation is unavailable, emulate the same separation in ordered sections and do not collapse the acceptance gate.
Maintain role separation even in a single-thread execution.
Minimal Output Frame
Use this frame when the task needs a visible control surface:
[PROBLEM n]
Status: OPEN | IN-LOOP | PASSED
[ROBUST CODE STRATEGY]
...
[IMPLEMENTER PACKET]
...
[JUDGE PACKET]
...
[DEFECT LEDGER]
...
[FINAL ORCHESTRATOR VERDICT]
...
