Quality Checker Loop

/goal Evaluate an agent output against an explicit quality checklist and return pass, fail, or partial with reasons.
 
Task type: Custom
Target tool: Claude Code
 
Work toward this goal until all validation checks pass or the stop rule is reached.
 
Design hypothesis:
This quality checker loop can produce a safer result if the scope stays narrow, validation is explicit, and a checker can reject shortcut work.
 
Smallest useful run:
Run one bounded pass on the newest relevant signal before expanding scope or adding a schedule.
 
Loop cycle:
1. Discovery — Read the latest signal for this template before acting: CI output, issue detail, review comment, dataset report, or content brief.
2. Handoff — Hand the work to one agent in an isolated branch, worktree, or clearly scoped session. Keep final approval with a human.
3. Verification — Use an independent review pass to confirm the result, inspect the diff or artifact, and reject shortcut work.
4. Persistence — Save a short run note with the signal reviewed, actions taken, validation result, and next recommended step.
5. Scheduling — Run manually until the loop is reliable; only then consider a scheduled or event-triggered run.
 
Context:
Treat the original goal, validation evidence, boundaries, and method checklist as the source of truth. The checker should be allowed to reject the result.
 
Validation:
Checker has access to the goal and expected evidence
Every checklist item is answered
Shortcuts and missing evidence are called out
Result is marked pass, fail, or partial
 
Validation evidence:
Record the original signal, checks run, final result, changed files or artifacts, and any checker rejection.
 
Independent checker:
Use an independent review pass to confirm the result, inspect the diff or artifact, and reject shortcut work.
 
Boundaries:
Do not approve work only because it sounds plausible
Do not ignore missing validation evidence
Do not let the maker agent decide the final quality result
Do not turn partial into pass without a reason
 
Stop rule:
Stop after one complete review and return the decision with reasons.
Maximum iterations: 2
 
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 evidence is missing, mark the result partial or fail and ask for the missing evidence.
 
Loop Validation Log:
- Hypothesis: This quality checker loop can produce a safer result if the scope stays narrow, validation is explicit, and a checker can reject shortcut work.
- Smallest useful run: Run one bounded pass on the newest relevant signal before expanding scope or adding a schedule.
- Expected evidence: Record the original signal, checks run, final result, changed files or artifacts, and any checker rejection.
- Actual evidence: [fill in after the run]
- Passed? [yes / no / partial]
- Feedback: After the run, note what the loop learned, what failed, 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.