Excel Model Skill
A model is only useful if it's live — change an assumption and everything recalculates. A markdown
table can't do that; a real .xlsx with cell formulas can. This skill builds an actual Excel workbook by
writing and running an openpyxl script: a clean inputs sheet, calculation sheets that reference
those inputs with real = formulas, and sensible formatting — so the user gets a file they can drive,
not a snapshot.
Environment: this produces a binary file, so it needs a place to run code — Claude Code, the
Anthropic API code-execution tool, or Claude.ai (with the analysis/code tool). In the
browser playground (no code execution), use the markdown output as the spec instead.
Required Inputs
Ask for these only if they aren't already provided:
- What the model is — financial model, budget, forecast, pricing model, scenario planner, etc.
- The inputs/assumptions — the driver variables (and rough values) the user will change.
- The outputs — what it should compute (revenue, burn, margins, totals, a P&L, etc.).
- Structure — periods (months/years), tiers/segments, and any required layout.
Process
- Design before coding — lay out the sheets (Inputs · Calculations · Output/Summary), and which cells are inputs vs. formulas. Confirm the calculation logic with the user if non-trivial.
- Write an
openpyxl script that:
- Puts all driver assumptions on an Inputs sheet (one source of truth), labelled and formatted.
- Builds calculation cells as real formulas referencing the input cells (e.g.
=Inputs!B2*Inputs!B3), never hard-coded results — so the model is live.
- Adds formatting: headers, number/currency/percent formats, column widths, and light cell styling for readability.
- Saves to a clearly named
.xlsx.
- Run it, then state the formulas used and tell the user which cells to change to flex the model.
Output Format
- The generated
.xlsx file (the deliverable).
- A short README of the model: the sheets, the input cells to change, the key formulas in plain English, and any assumptions.
Quality Checks
Anti-Patterns
Based On
Financial-modelling best practice (separate inputs from calculations, formula-driven, no hard-codes) implemented with openpyxl.
1---2name: excel-model3description: Build a real, formula-driven Excel (.xlsx) model — not a static table. Use when asked to build an Excel model, a financial model, a budget/forecast spreadsheet, or any .xlsx with live formulas a user can edit. Produces an actual .xlsx file via a generated openpyxl script: an inputs/assumptions sheet, calculation sheets with real cell formulas, and formatting — so changing an input recalculates the model. Requires a code-execution environment (Claude Code, the API code tool, or Claude.ai).4---5
6# Excel Model Skill
7
8A model is only useful if it's *live* — change an assumption and everything recalculates. A markdown
9table can't do that; a real `.xlsx` with cell formulas can. This skill builds an actual Excel workbook by
10**writing and running an `openpyxl` script**: a clean inputs sheet, calculation sheets that reference
11those inputs with real `=` formulas, and sensible formatting — so the user gets a file they can drive,
12not a snapshot.
13
14> **Environment:** this produces a binary file, so it needs a place to run code — **Claude Code**, the
15> **Anthropic API code-execution tool**, or **Claude.ai** (with the analysis/code tool). In the
16> browser playground (no code execution), use the markdown output as the spec instead.
17
18## Required Inputs
19
20Ask for these only if they aren't already provided:
21
22- **What the model is** — financial model, budget, forecast, pricing model, scenario planner, etc.
23- **The inputs/assumptions** — the driver variables (and rough values) the user will change.
24- **The outputs** — what it should compute (revenue, burn, margins, totals, a P&L, etc.).
25- **Structure** — periods (months/years), tiers/segments, and any required layout.
26
27## Process
28
291. **Design before coding** — lay out the sheets (Inputs · Calculations · Output/Summary), and which cells are inputs vs. formulas. Confirm the calculation logic with the user if non-trivial.
302. **Write an `openpyxl` script** that:
31 - Puts all driver assumptions on an **Inputs** sheet (one source of truth), labelled and formatted.
32 - Builds calculation cells as **real formulas referencing the input cells** (e.g. `=Inputs!B2*Inputs!B3`), never hard-coded results — so the model is live.
33 - Adds formatting: headers, number/currency/percent formats, column widths, and light cell styling for readability.
34 - Saves to a clearly named `.xlsx`.
353. **Run it**, then **state the formulas used** and tell the user which cells to change to flex the model.
36
37## Output Format
38
39- The **generated `.xlsx` file** (the deliverable).
40- A short **README of the model**: the sheets, the input cells to change, the key formulas in plain English, and any assumptions.
41
42## Quality Checks
43
44- [ ] Calculations are **live cell formulas**, not pasted static values
45- [ ] All driver assumptions live on one Inputs sheet and are referenced, not duplicated
46- [ ] Numbers are formatted (currency/percent/thousands) and sheets are readable
47- [ ] The script runs cleanly and the file opens in Excel/Sheets/Numbers
48- [ ] The user is told exactly which cells to change to drive the model
49
50## Anti-Patterns
51
52- [ ] Do not write computed results as static numbers — the whole point is that inputs recalculate
53- [ ] Do not hard-code an assumption inside a formula — put it on the Inputs sheet and reference it
54- [ ] Do not scatter inputs across sheets — one assumptions sheet, single source of truth
55- [ ] Do not skip formatting — an unformatted grid of numbers is hard to trust or use
56- [ ] Do not claim a file was produced if there was no code execution — fall back to a clear spec instead
57
58## Based On
59
60Financial-modelling best practice (separate inputs from calculations, formula-driven, no hard-codes) implemented with openpyxl.
majiayu000