Cursor rule

1---
2description: "Interactive assumption-surfacing Q&A that stress-tests a plan through relentless questioning until every decision is resolved. Use when user wants to challenge a plan, validate decisions from conversation/context, or mentions \"grill me\". For doc-grounded variant, use grill-with-docs."
3alwaysApply: false
4---
5 
6# Grill Me
7 
8> **Use this vs grill-with-docs:** `grill-me` surfaces assumptions from the conversation and context alone — no documentation fetching. Use `grill-with-docs` (the doc-grounded variant) when the plan relies on a specific library or external API and every challenge must cite a real doc URL.
9 
10Two modes. Default is **Design**. Switch to **Docs** by saying "grill me with docs" or when the plan relies on a specific library or external API.
11 
12> **HARD GATE** — Do NOT accept a design until every hard decision has been stress-tested. "Seems right" is not a decision. Grilling must identify and resolve tensions before build begins.
13 
14## Design mode (default)
15 
16Interview relentlessly about every aspect of this plan until reaching shared understanding. Walk each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer. Ask one question at a time.
17 
18If a question can be answered by exploring the codebase, explore it instead.
19 
20### Facts vs. Decisions Boundary
21 
22Distinguish between **facts** and **decisions**:
23- **Facts** — things discoverable by exploring the codebase, reading docs, or checking APIs. Do not ask the user to confirm facts; find them yourself.
24- **Decisions** — choices that require user input (trade-offs, preferences, priorities). Always present options and ask the user to choose.
25 
26Never "grill yourself" — if the answer is in the code, go find it. Only ask questions where the user's judgment is needed.
27 
28## Docs mode
29 
30Ground every challenge in real documentation — no assumption about a library's behavior goes unchecked. See [REFERENCE.md](REFERENCE.md) for the full process.
31 
32Short form:
331. List every external library, third-party API, and framework behavior relied upon.
342. Fetch the actual docs for each (`WebFetch` the official API reference).
353. Challenge each plan assumption against the real docs: correct method signature? right version? deprecated?
364. Report confirmed ✓, corrected ✗ (with the real behavior), and uncertain → `spike-prototype`.
375. Update the plan for each confirmed discrepancy.
38 
39## Confirmation Gate
40 
41> **HARD GATE** — Do NOT enact the plan or generate specifications until the user explicitly confirms shared understanding. Wait for explicit approval (e.g., "looks good", "confirmed", "proceed") before transitioning to any implementation, spec-writing, or task-slicing step.
42 
43---
44 
45# Docs Mode — Full Process
46 
47Triggered by "grill me with docs" or when a plan depends on a specific library or external API.
48 
49**Why this matters:** AI agents hallucinate API methods, argument orders, and behaviors. Every assumption about an external dependency must be validated against the actual docs before code is written.
50 
51## Step 1 — Identify the dependencies
52 
53From the plan or conversation, list:
54- Every external library being used
55- Every third-party API being called
56- Every framework behavior being relied upon
57 
58Ask: "Which of these are you most confident about? Which are you less sure of?"
59 
60## Step 2 — Fetch the relevant docs
61 
62For each dependency, fetch the actual documentation:
63 
64```
65WebFetch the official docs for [library/API]
66```
67 
68Prioritize:
69- The API reference for the specific method being used
70- The changelog for the version in use (breaking changes)
71- Migration guides if upgrading from a previous version
72- Known gotchas / FAQ sections
73 
74## Step 3 — Challenge each assumption
75 
76For every assumption in the plan, find the corresponding doc section and ask:
77 
78- "Does the real API actually work this way? Show me the doc."
79- "Is this method available in the version you're using?"
80- "Does this argument order match the actual signature?"
81- "Are there rate limits, quotas, or timeout behaviors that affect this design?"
82- "Is this marked as deprecated in the current version?"
83 
84Ask one question at a time. For each challenge, cite the specific URL and section.
85 
86## Step 4 — Surface hallucinations
87 
88When an assumption doesn't match the docs:
89 
90> "Your plan uses `library.doThing(a, b)` but the [docs](https://example.com/api-reference) show the signature is `doThing(config: {a, b})` with a config object. This will fail at runtime."
91 
92Document each discrepancy clearly.
93 
94## Step 5 — Update the plan
95 
96For each confirmed discrepancy, recommend a concrete fix:
97- Correct method signature
98- Correct argument order
99- Alternative approach that matches what the library actually supports
100- Whether a spike (`spike-prototype`) is needed to validate a remaining uncertainty
101 
102## Step 6 — Sign off
103 
104When all major assumptions have been validated against docs, report:
105- Which assumptions were confirmed ✓
106- Which were corrected ✗ + what the correct approach is
107- Which remain uncertain → recommend `spike-prototype`
108