Windsurf rules

1---
2name: grill-me
3model: sonnet
4description: "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."
5---
6 
7# Grill Me
8 
9> **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.
10 
11Two 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.
12 
13> **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.
14 
15## Design mode (default)
16 
17Interview 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.
18 
19If a question can be answered by exploring the codebase, explore it instead.
20 
21### Facts vs. Decisions Boundary
22 
23Distinguish between **facts** and **decisions**:
24- **Facts** — things discoverable by exploring the codebase, reading docs, or checking APIs. Do not ask the user to confirm facts; find them yourself.
25- **Decisions** — choices that require user input (trade-offs, preferences, priorities). Always present options and ask the user to choose.
26 
27Never "grill yourself" — if the answer is in the code, go find it. Only ask questions where the user's judgment is needed.
28 
29## Docs mode
30 
31Ground every challenge in real documentation — no assumption about a library's behavior goes unchecked. See [REFERENCE.md](REFERENCE.md) for the full process.
32 
33Short form:
341. List every external library, third-party API, and framework behavior relied upon.
352. Fetch the actual docs for each (`WebFetch` the official API reference).
363. Challenge each plan assumption against the real docs: correct method signature? right version? deprecated?
374. Report confirmed ✓, corrected ✗ (with the real behavior), and uncertain → `spike-prototype`.
385. Update the plan for each confirmed discrepancy.
39 
40## Confirmation Gate
41 
42> **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.
43 
44---
45 
46# Docs Mode — Full Process
47 
48Triggered by "grill me with docs" or when a plan depends on a specific library or external API.
49 
50**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.
51 
52## Step 1 — Identify the dependencies
53 
54From the plan or conversation, list:
55- Every external library being used
56- Every third-party API being called
57- Every framework behavior being relied upon
58 
59Ask: "Which of these are you most confident about? Which are you less sure of?"
60 
61## Step 2 — Fetch the relevant docs
62 
63For each dependency, fetch the actual documentation:
64 
65```
66WebFetch the official docs for [library/API]
67```
68 
69Prioritize:
70- The API reference for the specific method being used
71- The changelog for the version in use (breaking changes)
72- Migration guides if upgrading from a previous version
73- Known gotchas / FAQ sections
74 
75## Step 3 — Challenge each assumption
76 
77For every assumption in the plan, find the corresponding doc section and ask:
78 
79- "Does the real API actually work this way? Show me the doc."
80- "Is this method available in the version you're using?"
81- "Does this argument order match the actual signature?"
82- "Are there rate limits, quotas, or timeout behaviors that affect this design?"
83- "Is this marked as deprecated in the current version?"
84 
85Ask one question at a time. For each challenge, cite the specific URL and section.
86 
87## Step 4 — Surface hallucinations
88 
89When an assumption doesn't match the docs:
90 
91> "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."
92 
93Document each discrepancy clearly.
94 
95## Step 5 — Update the plan
96 
97For each confirmed discrepancy, recommend a concrete fix:
98- Correct method signature
99- Correct argument order
100- Alternative approach that matches what the library actually supports
101- Whether a spike (`spike-prototype`) is needed to validate a remaining uncertainty
102 
103## Step 6 — Sign off
104 
105When all major assumptions have been validated against docs, report:
106- Which assumptions were confirmed ✓
107- Which were corrected ✗ + what the correct approach is
108- Which remain uncertain → recommend `spike-prototype`
109