| name | grill-for-unknowns |
| description | Stress-test a plan or design by surfacing unknown unknowns — classify gaps into four quadrants, run seven blindspot lenses against real code, and grill one material decision at a time. Use when asked to "grill this plan", find "unknown unknowns", "stress test the plan", or hunt "blind spots". |
| disable-model-invocation | true |
Grill for Unknowns
Adversarially review a plan/design to surface what nobody has considered yet.
Inspired by nicobailon/grill-for-unknowns.
Worked example in this repo:
docs/issues/391/runtime-refactor/REVIEW-2026-07-11-unknowns.md.
Frame — four quadrants
Classify every gap before probing:
- Known-knowns — proven by code/docs. Cite, don't question.
- Known-unknowns — acknowledged open decisions. Track, don't rediscover.
- Unknown-knowns — you'd recognize the right answer but can't state it upfront (team memory not written into the plan). Surface and write down.
- Unknown-unknowns — nobody's considered it. The real target of this skill.
Seven blindspot lenses
Run each lens against the plan; example question shape for this repo's runtime/plan work:
- Scale — what happens under 10x workspace/session concurrency?
- Security — does the new boundary change what paths/tools an adapter can reach?
- Failure modes — if it crashes mid-operation, what state is inconsistent and who detects it?
- Edge cases — what happens to sessions/workspaces created under the old runtime still open at swap time?
- Concurrency — can two mode transitions race and leave a pair mismatched?
- Migration — what must exist in both old and new shapes simultaneously, and for how long?
- Rollback — if we revert, what is now irreversible (schema, on-disk format, deleted code path)?
Process
- Restate the plan and its stated assumptions.
- Read the actual code/tests — never trust the plan's self-description.
- Build an unknowns ledger sorted into the four quadrants.
- Run the seven lenses; rank suspects by implementation risk.
- Grill one material decision at a time.
- For low-risk gaps, propose a default instead of blocking.
- Stop when every unknown that could materially change the plan is resolved or explicitly accepted as an assumption.
Question filter
Only ask a question if ALL three hold:
- Material — changes architecture, scope, data model, security, or acceptance criteria.
- Grounded — tied to actual code/doc evidence, not speculation.
- Answerable — the user can pick an option or approve a default.
Output format per blocking question
**Blocking question:** <the question>
**Why it matters:** <A vs B consequences>
**Evidence:** <file citation>
**Recommended answer:** <default + rationale>
Hard-to-reverse, non-obvious, real-trade-off decisions get flagged as ADR /
docs/DECISIONS.md candidates instead of being buried in chat.
