Grill Pro Relentless Design Interview

Problem

Design reviews often suffer from drifting terminology, fuzzy boundaries, and stated assumptions that disagree with the code. Engineers may use “account,” “cancellation,” or “order” differently across conversations, and those mismatches reappear later as rework. Grill Pro treats the plan as something to be tested rather than accepted, using continuous questioning to surface unclear premises.

How It Works

It walks the design tree one question at a time, resolving dependencies before moving deeper. If a question can be answered by inspecting the repository, it explores the codebase instead of asking the user. If the code contradicts a stated assumption, it calls the conflict out directly: “The code cancels the whole Order, but you said partial cancellation is possible — which behavior is intended?”

During the session it performs several checks:
- Terminology alignment: flags conflicts against the domain glossary in CONTEXT.md.
- Boundary stress-testing: invents concrete scenarios to expose edge cases around ambiguous concepts.
- Code cross-referencing: maps user claims back to actual behavior and surfaces inconsistencies.
- Inline documentation: updates CONTEXT.md as terms are resolved, keeping it to project-specific nouns rather than implementation details.
- Sparingly proposed ADRs: suggests docs/adr/ entries only when a decision is hard to reverse, surprising without context, and the result of a real trade-off.

Fit and Limits

This skill fits architecture reviews, domain modeling, API boundaries, migration plans, and other discussions that need shared understanding. It is less useful for one-off scripts, copywriting, or tasks with no code context. If no repository is available, it can still run the interview but skips CONTEXT.md and ADR updates. Teams with stricter documentation standards should align the generated file format and ADR naming with existing conventions.