Data Explore
An LLM reading numbers off a table gets them subtly wrong. An LLM writing SQL against those numbers does not. Always move the data into a table first.
Procedure
- Look before you load. Read the first few rows. Identify the columns, their types, and which one is the key. Say out loud what you think each column means and let the user correct you — a misread column poisons every later answer.
- Create the table with
create_table(table_name, columns). Use explicit types. Store money as a number, not a string with a currency symbol; store dates as ISOYYYY-MM-DD. - Insert with
insert_data(table_name, data). Load everything, not a sample — the outliers are usually the point. - Verify the load.
list_tables()to confirm the schema landed as you intended, thenquery_data("SELECT COUNT(*) FROM scratch_<table>")and compare to the source row count. If they differ, find out why before answering anything. - Answer with
query_data(sql). One query per question. Show the SQL you ran alongside the result so the user can check your reasoning. - Say what the data cannot tell you. Missing rows, nulls, and a single month of history are all limits worth naming.
The prefix rule
Every table name in a query carries the scratch_ prefix. A table created
as create_table("sales", ...) is queried as SELECT ... FROM scratch_sales.
Getting this wrong is the single most common failure here — the query errors
instead of returning data, and no amount of rephrasing the question fixes it.
Cleaning rules
- Trim whitespace and normalize case before comparing text keys.
- Nulls and zeros are different. Never coerce one to the other silently.
- If a column mixes formats (dates as both
01/02/24and2024-02-01), normalize on load and tell the user you did.
Fork this
Pin step 2 to your recurring export's exact schema and step 5 to the five questions you always ask of it — the skill becomes a one-command monthly report.
