Skip to main content
The context-interview skill builds your context layer with you, one domain at a time — the model drafts in real time, you confirm — and writes it to a reviewable git repo on your machine.

​
What you need

Five ingredients — the context layer sits on top of what you already run:
  1. An AI agent. Claude Code, Codex, Cursor, Gemini — whatever you already drive.
  2. A warehouse connected over MCP, read-only. The interview only ever SELECTs.
  3. (Recommended) Lineage. Your dbt repo cloned locally, so the interview reads real models/ and schema.yml as a draft to confirm instead of asking you from scratch.
  4. (Recommended) Query history. The interview mines what your company actually runs in the warehouse into draft context — see query-history mining below.
  5. Your dashboards. The source of truth for the metrics that matter most — the interview discovers domains from them and verifies its answers against them.

​
Run it

​
One skill, six steps

The interview runs in order — but you can jump around. Each domain ends by proving itself. It’s slower than auto-generation for the initial build — deliberately. You see the value of each incremental piece of context with real questions, in real time, as you build.

​
Query-history mining: the highest-leverage input

Step 0 can mine your warehouse’s query history into draft context (scripts/query_history_extract.py). BI tools push their dashboard tiles down into the warehouse, so query history is a census of what your company actually computes — no BI admin required. It surfaces:
  • Recurring dashboard patterns. A daily-refreshed tile shows up as one query shape run 365 times — institutionalized logic, separated from ad-hoc exploration.
  • Conflicting metric definitions — the headline win. Three different revenue calculations over the same table become the exact disambiguation questions the interview asks you, and your resolution lands as both a confirmed definition and a labeled eval seed.
  • The standard hygiene filters. When every query on a table applies the same predicate, the interview asks why — and captures it as a mandatory filter.
Everything mined stays a draft for you to confirm — the miner surfaces candidates and conflicts, it never writes definitions. And it only ever reads query metadata, never table data.

​
Analysts need one extra grant to mine query history

On most warehouses, an ordinary read-only user can’t see the full query history by default — mining works, but from a shorter, privilege-limited sample. The warehouse-specific admin instructions (Snowflake, BigQuery, Redshift) — including the removal for when you’re done, and a self-test for the analyst — live on the Connect your database page.
This grants nothing to Nodal, and nothing to any outside party. The grant is held by your own employee, used from their own warehouse session. Nodal never authenticates to your warehouse — it has no credential, no user, and no role. The mining script reads query metadata (SQL text and run counts) and never table data.

​
See it end to end

A full domain built from a live conversation — including the verify step catching a definition that made an answer worse, and fixing it on the spot:

​
What you get

A ../analytics-context/ repo — your deliverable — with human-readable files, every line drafted by AI and confirmed by you:
It lives on your machine, checks into git — diffable, reviewable, versioned like code. The cloned tool repo stays read-only; keep it to add more domains later.

​
Next