grill-with-docslisted

# Grill with docs A distinct, earlier stage than `brainstorming`: brainstorming compares *design approaches* once the problem is understood; this skill establishes *what the problem actually is* and *what's actually true about the libraries involved* before any approach gets proposed. Skipping this step is how a plan gets built on a hallucinated API that changed two major versions ago. ## Process 1. **Ask the clarifying questions a spec would answer** — scope boundary, non-goals, acceptance criteria, who/what this needs to work for. Two or three sharp questions beat ten shallow ones. 2. **Name every library/API the request touches.** For each one you're not certain is current, ground it instead of assuming: call `web_docs` (package metadata + README) or `web_fetch` (a specific docs page) from the `web` module. This is the actual anti-hallucination lever — check before you plan, not after something breaks. 3. **Write `CONTEXT.md`** (or update it if one exists): the restated problem, the answered questions, and one line per grounded fact ("`fetchPage` in package X takes `{url, headers}`, confirmed via registry README as of today," not "I recall it takes..."). 4. **Hand off.** `CONTEXT.md` is what `brainstorming` reads to propose approaches — don't re-ask the same questions there. ## When to skip A request with no external library/API surface and no real ambiguity doesn't need this — go straight to `brainstorming` or straight to work for a genuinely tri