grill-me-with-feedback-loop

name	grill-me-with-feedback-loop
description	Interrogate the user about a plan or design, then iterate against user-supplied acceptance checks in a self-scoring loop until every check passes. Use when the user wants their plan stress-tested AND wants the model to keep refining until a concrete set of pass/fail criteria are satisfied. Triggers on "grill me with checks", "grill me and verify", "grill me in a loop", or when the user provides a list of criteria the final answer must meet.
license	MIT
metadata	{"author":"ayoub","version":"1.0.0"}

Grill Me With Feedback Loop

A three-phase skill: collect the checks, interrogate to surface hidden assumptions, then iterate against the user's own criteria until everything passes.

This is the classic "grill me" interrogation pattern, but bolted onto a verification loop so the conversation has a concrete exit condition instead of vibes.

Phase 1 — Collect inputs (do this FIRST, in one message)

Before any grilling, ask the user for all three of these:

1. The plan, design, or thing to stress-test. Code, architecture, product spec, migration strategy — anything.
2. The feedback-loop checks. A numbered list of pass/fail criteria the final answer must satisfy. Examples:
   • Concrete: "must handle empty input", "must not add a new dependency", "must run in under 100ms"
   • Subjective: "must read clearly to a junior dev", "must not introduce new abstractions"
   • Codebase-grounded: "must match the error-handling pattern already used in lib/auth.ts"
3. Stop conditions. Max iterations (e.g. 5), wall-clock cap, or "loop until I tell you to stop".

If any of the three is missing, ask for it before proceeding. Do not start grilling without checks — the checks shape which questions matter.

Phase 2 — Grill

Interview the user one question at a time. Walk the decision tree branch by branch, resolving dependencies between decisions before moving on. For every question:

• State your own recommended answer with the reasoning behind it. Don't ask open-ended questions without a default.
• Wait for the user's response before asking the next one.
• If a question can be answered by reading the codebase, read the codebase instead of asking.
• Bias the questions toward things that affect whether a Phase 1 check will pass or fail.
• Stop grilling once you have enough to produce a candidate plan you can score against every check.

Phase 3 — Feedback loop

Once Phase 2 produces a candidate, run this loop:

1. Score. Walk every check from Phase 1 in order. Mark each PASS, FAIL, or UNKNOWN with a one-line justification you would defend in code review.
2. Report the scorecard to the user before changing anything. No silent rewrites.
3. Refine. For every FAIL or UNKNOWN, revise the plan to address it. Be explicit about what changed and which check it targets.
4. Re-score the revised plan.
5. Repeat until one of:
   • every check is PASS,
   • the iteration cap from Phase 1 is reached,
   • the user says stop.

If a check can't be evaluated without more info, mark it UNKNOWN and ask the user one targeted question to resolve it — don't guess.

Output format for each iteration

=== Iteration N ===
[1] PASS    — <check text> — <one-line reason>
[2] FAIL    — <check text> — <what's broken>
[3] UNKNOWN — <check text> — <what's missing to evaluate>

Changes this iteration:
- <change> (addresses check #2)
- <change> (addresses check #3)

Next: refine / ask user / stop

Anti-patterns

• Starting Phase 2 without Phase 1's checks in hand. The checks are the whole point.
• Marking a check PASS without a justification you'd stand behind in review.
• Looping forever. If two consecutive iterations make no progress on the same check, surface that you're stuck and ask the user how to proceed.
• Rewriting the plan silently between iterations. Always show the scorecard first, then the diff.
• Asking multi-part questions in Phase 2. One question at a time, with your recommended answer attached.