Data Analysis in Plain Language: A Persistent Skill Built on DuckDB

datum;kategorie;castka
2026-01-05;Nájem;-12500,00
2026-01-07;Potraviny;-842,50
2026-01-09;Potraviny;-1230,00
2026-02-01;Mzda;48000,00

Install the DuckDB CLI for me (only if I don't already have it;
it's free, instructions at duckdb.org) and create a persistent,
reusable skill that I'll use to analyze any data file by telling
you in plain language what I want.

Have the skill follow these rules:
- Calculations run through the DuckDB CLI (the duckdb command),
  which reads CSV, Excel, Parquet, JSON, and gzip directly from
  the file, with no database to set up. Take SQL syntax from the
  documentation: duckdb.org/docs/current/sql/introduction.
- Before writing a query, look at the file first: schema and
  statistics via SUMMARIZE FROM 'soubor', the first few rows via
  FROM 'soubor' LIMIT 5. Don't guess column names or types, and
  when anything is unclear, ask the user.
- With every answer, show the SQL query that produced the result,
  and the number of rows that went into it.
- Don't modify or overwrite the data. When something needs to be
  excluded or fixed, do it in the query and state what you
  excluded and why.
- Save the skill so it loads on its own whenever I talk about
  analyzing a data file — I shouldn't have to invoke it by hand.

Once it's done, show me where you saved the skill and what's in it.

We'll be analyzing the file [file name].

Don't calculate anything yet. Look it over and tell me:
1. How many rows and columns it has.
2. For each column: its name, what type it loaded as, how many
   empty values it has, and how many distinct values it contains.
3. Which columns you think loaded with the wrong type (typically
   a number or date read as text) and how to fix that.
4. What one observation is in this data — what a single row means.
5. What you need to ask me before we start calculating. Don't
   hold back: better to ask five things than guess one.

We'll be analyzing the file [file name].

Give me a breakdown by [month] across recurring categories.
Anything that doesn't recur regularly goes into an Other bucket.
Treat a category as recurring if it appears in at least [three
periods] and makes up at least [1%] of the total.

Output: a table of period by category, with [sum of amount] in
each cell and the record count in parentheses, plus totals per
category and per period.

Below the table, list every anomaly that breaks the typical
pattern:
- a category that appeared for the first time, or disappeared,
- a value that deviates from that category's usual level by more
  than [double],
- a period missing a category that otherwise always shows up.

For each anomaly, name the specific row it involves. Don't
explain causes, just show what's unusual.

In the file [name], compare period [A] against period [B].

I want a table: [category], value in period A, value in period B,
absolute difference, percentage change, and CONTRIBUTION to the
overall change in percentage points. Sort by contribution, largest
first.

Then separately break the overall change into two components:
change in record count and change in the average value per record.

Finally, list categories that appear in only one of the two
periods.

Define the periods using the [date] column, and tell me how many
days each one covers — flag it if they differ.

In the file [name] I want to find the mess. Don't fix anything,
just list it.

1. Exact duplicates: rows identical across every column, with
   three examples.
2. Duplicates by key [column or combination of columns]: records
   with the same key but differing in the other columns.
3. Text values that are probably the same thing written
   differently: differing only in case, trailing spaces,
   accented characters, or a typo. Show them in pairs, with the
   frequency of each variant.
4. Values outside the expected range: negative numbers where they
   don't make sense, future dates, zero amounts.
5. Columns missing more than [5%] of their values.

For each point, state the number of affected rows and their share
of the total.

In the file [name] I'm interested in the breakdown by [column,
e.g. customer / product / branch].

1. Rank segments by [sum of value] and show the top 20: segment,
   value, share of total, cumulative share.
2. Tell me how many segments make up 50% and how many make up 80%
   of the total.
3. For each segment in the top 20, add the record count and the
   MEDIAN record value, not the average.
4. Separately show segments with a single record — how many there
   are and what share of the total they make up combined.

Add a “remainder” row summing the other segments, so the table
adds up to the total.

I have two files: [file A] and [file B]. I want to join them on
[shared column].

First, without calculating anything, tell me:
- how many unique key values each file has,
- how many values from A have no match in B, and vice versa —
  show five examples for each,
- whether the relationship is 1:1, or whether some key repeats
  within one of the files (and how many times at most).

Only then join them so that not a single row from file A gets
lost, adding the columns [list] from B.
After joining, tell me how many rows the result has and compare
that to the row count in A. If the numbers differ, explain why.

In the file [name] I want to check whether the data is complete.

1. The oldest and newest [date] in the file.
2. A time series of record counts by [day / week / month] — print
   the whole thing so I can see the gaps.
3. Periods with zero records even though neighboring periods have
   them. List these as specific ranges.
4. Periods where the record count is significantly lower or higher
   than usual (deviation from the median of more than [50%]).
5. Whether the composition of the data changes over time:
   categories appearing only in part of the period, or a column
   that's empty from a certain date onward. State exactly when
   the change happened, too.

Show me the query that produced the number [specific value], and
walk me through it piece by piece in plain language — for each
piece, say what decision about my data it hides inside it.

Then separately list:
- which rows the query excluded, and how many there were,
- what happens to rows where [column] is empty,
- where the query could return a wrong number without failing.

Finally, give me one alternative: how the same thing could be
calculated differently, and why the result might come out
different.

For the last analysis, give me a row-count reconciliation:
- how many rows the source file had,
- how many were dropped at each step, and why,
- how many made it into the final result,
- check: does the sum of excluded and included rows match the
  total?

For every step that dropped more than [2%] of rows, show me five
specific excluded rows so I can see what I lost.

If any rows dropped out unintentionally, say so bluntly instead
of explaining it away.