Feedback Improvement Loop

/goal Review recent feedback, choose one small loop improvement, validate it against representative cases, and decide whether to keep it.
 
Task type: Custom
Target tool: Generic Agent
 
Work toward this goal until all validation checks pass or the stop rule is reached.
 
Design hypothesis:
This feedback improvement 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:
Feedback can come from users, failed validation logs, reviewer notes, or repeated support questions. Keep the improvement narrow.
 
Validation:
Feedback is grouped by repeated issue
One improvement is chosen
Old and new outputs are compared on representative cases
The change is kept only if it improves clarity or safety
 
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 rewrite unrelated templates
Do not expose private user feedback
Do not treat one vague complaint as a broad product direction
Do not skip validation after changing a template
 
Stop rule:
Stop when one improvement is validated or when feedback is too unclear to act on.
Maximum iterations: 4
 
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 feedback is ambiguous, ask a clarifying question or collect more examples before changing the loop.
 
Loop Validation Log:
- Hypothesis: This feedback improvement 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.