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.

​
Who this is for today

Nodal is currently best suited to teams that already have a queryable analytics warehouse, an analyst or other domain expert who owns business definitions, and a supported local agent that can receive approved read-only access to the warehouse. The person running the interview should be comfortable in a local agent project; they don’t need to write Python, and the domain expert who confirms definitions doesn’t need to know dbt or use a command line. Large organizations are in scope — roll out one analytics domain at a time: establish its definitions, failure cases, and eval seeds, verify that its governed answers work, then expand. Each completed domain is a reviewable governance boundary, not a company-wide semantic migration. Nodal is not yet optimized for organizations without a warehouse or a technical data owner.

​
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.

​
Install the plugin

Nodal ships as an agent plugin for Claude Code, Codex, and skill-compatible agents like Cursor — no clone required. The Quickstart has the install and update commands for each host. Pick one installation method per host. Start your agent from the folder that holds your data lineage, so the context repo Nodal creates sits next to it and the interview can read real models while it talks to you:

​
Run it

From the project where you’ll build context — in a fresh session after installing, since plugins are discovered at the session boundary — run setup once — it probes your warehouse connection (read-query, metadata, and query-history capabilities), discovers nearby dbt and context sources, and writes only sanitized paths and capability classifications to a gitignored .nodal.local.json, never credentials:
Then either take the short path or the full one:
Both paths write a reviewable ../analytics-context/ sibling repo (git-initialized), then offer to push it to your own private remote. Unanswered material stays visibly marked as draft.
Want to see what comes out before running it on your own warehouse? Explore Shorelane Commerce — a fictional company with a public warehouse and deliberately ambiguous revenue definitions — alongside its generated analytics-context repo. Together they show the evidence Nodal starts from and the reviewable context and eval seeds the interview produces.

​
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 generated repo carries its own copy of the spec, schemas, scripts, CI, and eval harness, so a teammate who clones it (and installs the plugin) can pick up where you left off — no Nodal source checkout needed.

​
Next