About this skill

Problem

Letting an LLM read raw Excel or CSV files directly is fragile. Headers can be misaligned, merged cells can break row semantics, and sheets may contain multiple table regions, hidden rows, formulas, titles, notes, or inconsistent encodings. Loading raw spreadsheets into context also wastes tokens and can make the model treat a spreadsheet-like layout as a reliable table, causing joins and aggregations to run on the wrong grain. This skill turns spreadsheet analysis into a workflow: inspect the structure, standardize it, analyze it with deterministic tools, validate the result, and let the LLM handle intent, field semantics, query planning, and explanation.

How It Works

Structure inspection: uses openpyxl, xlrd, or CSV sniffing to identify sheets, dimensions, merged cells, candidate headers, hidden regions, and file encodings.
Structure classification: separates standard tables, lightly non-standard tables, normalizable complex tables, and unrecoverable tables; ambiguous or unrecoverable structures get a structure report instead of forced analysis.
Standardization: fills vertical merged values downward, expands horizontal merged headers, flattens multi-row headers into one unique field row, and preserves source file, sheet, row, and column lineage.
Analysis execution: prefers duckdb for SQL joins and aggregations, uses pandas or polars for cleaning and medium-scale transformations, and may use sqlglot for SQL validation or dialect-safe rewriting.
Script-first output: formal analyses default to an executable script that is parameterized, rerunnable, and writes profiles, field maps, cleaning logs, SQL, validation results, and outputs.
Validation guardrails: checks row-count changes, field types, unexpected join cardinality, many-to-many double counting, empty-result explanations, and whether the answer is based on executed results.

It fits multi-sheet workbooks, multiple table regions, merged headers, and messy CSV/Excel inputs. It does not cover mutating source files, writing databases, network access, or DDL because the analysis is meant to run in a read-only sandbox. For ambiguous metrics, missing table roles, or non-unique join keys, it should ask for business clarification rather than guessing.

Screenshots

Use Cases

Analysts normalize sales workbooks with merged headers and title rows before aggregating by region.
Operations join orders and channels, check key uniqueness, and confirm joins do not double-count.
BI engineers turn repeat inventory analysis into rerunnable scripts with paths and validation logs.
Data governance staff diagnose CSV encoding, candidate headers, and table regions before cleaning.

Best For

Operations or analysts who reconcile multiple business Excel files and explain metric definitions each week
BI or data engineers who turn repeated SQL analyses into schedulable scripts
Data governance or consulting staff who diagnose merged headers and multi-region tables before cleaning
Reporting engineers who rerun reports and need join-key and row-count validation