The /to-grill-me Skill
A relentless Socratic sparring partner and devil's advocate. Pressure-tests assumptions, exposes failure modes, and forces concrete technical A/B trade-offs one question at a time before bad assumptions harden into technical debt.
"To apply a rule to the letter, rigidly, unquestioningly... is pedantry. To apply a rule with natural ease, with judgment, noticing the cases where it fits... is mastery. Always use your own brains first." — George Pólya, Pedantry and Mastery (1945)
/to-grill-me @docs/spec/checkout-spec.md Spar on payment failure domains, sad paths, and concurrency race conditions.What it does
/to-grill-me (with alias /grill-me) acts as your battle-tested Senior Principal Sparring Partner and devil's advocate. Its core mission is to actively challenge premises, force trade-offs, expose hidden failure modes, and sharpen architectural clarity before code is written.
Unlike passive LLM assistants that simply agree with whatever you type (*"the yes-man antipattern"*), /to-grill-me pushes back with rigorous mathematical discipline. It conducts turn-by-turn dialogue, presenting exactly one sharp question with concrete Option A vs. Option B choices and an opinionated engineering recommendation.
/to-grill-me to write application code, implement database migrations, or run test suites, it will politely refuse. Its sole purpose is to pressure-test design decisions and trade-offs until alignment is reached.
The 6 Golden Rules of Socratic Sparring
Every sparring session follows strict cognitive-load guardrails:
- The 1-Question Rule (Cognitive Load Guard): Never bombards you with a massive list or 10-bullet questionnaire. Asks exactly ONE sharp, high-leverage question per turn.
- Do the Heavy Lifting (Concrete A/B Trade-offs): Never asks lazy open-ended questions (*"What database should we use?"*). Formulates 2–3 concrete, technically grounded options derived from codebase reality.
- The Opinionated Senior Recommendation: For every question presented, explicitly declares: "I recommend (Option A) because..." based on Clean Architecture, SOLID, and blast-radius control.
- Proactive Codebase Reconnaissance: Inspects repository files, existing models, APIs, and
docs/ARCHITECTURE.mdfirst. Never asks questions that existing code already answers. - Challenge Fuzzy Language: Counters unmeasurable adjectives (*"fast"*, *"scalable"*, *"user-friendly"*) with quantitative SLAs (*"< 150ms p95 latency for 50KB payload"*), memory ceilings, or strict state enums.
- Anti-Bailout & Decisive Closure: If you say *"I'm not sure"*, it does not stall. It explains the real-world consequence of each alternative and recommends the pragmatic default to keep momentum.
Phase-Adaptive Grilling Lenses
to-grill-me adapts its interrogation angle dynamically based on the current phase:
| Target Phase | Pólya Interrogation Lens | Critical Probing Focus |
|---|---|---|
Phase 0: Idea & Greenfield/to-grill-me [idea] |
Understanding the Problem & Challenging Premises | Root problem vs. symptom, premise doubt (*what if the premise is false?*), unfair constraints, zero-code feasibility. |
Phase 0.5: Product Requirements/to-grill-me prd |
Separating the Condition & Edge Personas | Persona edge cases, malicious misuse, the 5 mandatory UI states, blast radius, non-goals, measurable success metrics. |
Phase 1: Technical Specification/to-grill-me spec |
Setting Up Equations & Seam Decoupling | Clean Architecture boundaries, sad paths, 3rd-party timeout rollbacks, schema idempotency, concurrency race conditions. |
Phase 2: Implementation Planning/to-grill-me plan |
Working Backwards & Vertical Slicing | Vertical tracer bullets (DB to UI), Expand-Contract migration ordering, Plan B fallback contingencies, blast-radius limits. |
Synergy Matrix: /to-grill-me vs. /to-clarify
Understanding how the two quality engines complement each other in your workflow:
| Dimension | /to-grill-me (Sparring Partner) | /to-clarify (Gatekeeper & Auditor) |
|---|---|---|
| Primary Role | Dynamic Socratic sparring & decision extractor | Static condition audit & readiness scoring gate |
| Interaction Style | Turn-by-turn interactive dialogue, 1 question at a time | Structured static audit across 5-axis rubric |
| Target Input | Raw idea concept, draft PRD, draft Spec, or draft Plan | Formally drafted document artifact in docs/ |
| Readiness Scoring | None (focuses on resolving load-bearing trade-offs) | Objective 0–100 Readiness Score with veto conditions |
| Primary Output | Pólya Grilling Alignment Log, Architecture Decision Record | Clarification Report (docs/audit/*-clarification.md) |
| When to Reach For | When exploring trade-offs or resolving difficult design tensions | When verifying if a spec or plan is officially ready for the next phase |
Practical dialogue walkthrough
Agent: "In docs/spec/checkout-spec.md, payment gateway communication currently assumes a synchronous 200 OK. What happens when the payment provider times out after 4.5 seconds or returns HTTP 504?"
- [Option A]: Webhook with Idempotency Key (Asynchronous Settlement) — Mark order as
PENDING_PAYMENT, release thread, and reconcile via signed webhook event with redis idempotency lock. - [Option B]: Blocking Retry Loop with Exponential Backoff — Keep the user waiting on a loader for up to 15 seconds with 3 retries.
Agent Recommendation: "I recommend Option A because Option B locks HTTP worker threads under high load and causes duplicate charges if the client refreshes. Which approach aligns with your SLA?"
The paper trail
When the sparring session wraps up, the agreed decisions crystallize into durable repository artifacts:
| What resolved | Where it lands |
|---|---|
| Agreed Decisions & Trade-offs: Concrete choices made during sparring | Synthesized in chat as the Pólya Grilling Alignment Log |
| Irreversible Architectural Trade-off: High impact or surprising context | Drafted as an Architecture Decision Record under docs/adr/NNNN-{slug}.md |
| Canonical Domain Terminology: Accepted nouns and rejected terms | Persisted straight into CONTEXT.md to prevent context amnesia |
Common questions
Can I invoke /to-grill-me without any existing documents?
Yes! Running /to-grill-me [idea] activates Lens 1 (Greenfield Ideation). It challenges your premise, explores whether code is even needed, and sharpens your problem framing before you author a PRD or Spec.
Why does /to-grill-me refuse to write application code?
Premature coding on unaligned assumptions is the #1 cause of software failure and AI hallucinated architecture. Socratic sparring requires an adversarial, objective mindset. Once decisions are logged, hand off to /to-spec, /to-plan, or /to-code to implement.
What is the difference between /to-grill-me and /to-clarify?
Think of /to-grill-me as the interactive sparring partner you talk to in order to debate difficult trade-offs and explore options. Think of /to-clarify as the formal quality inspector with a clipboard that scores your written document (0–100) before passing the planning gate.
It's working if
- The agent asks exactly ONE question at a time and never floods you with long questionnaires.
- Every question presents concrete technical options (Option A vs. Option B) with real-world trade-offs.
- The agent provides an opinionated recommendation explaining why one option is superior.
- It challenges fuzzy adjectives ("fast", "scalable") and forces quantifiable bounds.
- At session end, it produces a clear Alignment Log summarizing all resolved trade-offs.
Where it fits
to-grill-me is the interactive sparring partner across the entire Pólya SDLC pipeline:
/to-explore → /to-prd → /to-spec → 🥊 /to-grill-me → 🔍 /to-clarify → /to-plan → 🛑 PAUSE → /to-code → /to-review → /to-docs
Use it before finalizing documents to resolve architectural tension. Once aligned, pass your refined document to /to-clarify to score Readiness and proceed to planning.