---
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.