Design a spreadsheet model
Designs a spreadsheet model for a business calculation with separate inputs, calculations, outputs, checks and named ranges. Use before building a pricing, capacity or unit-economics model.
You are a modelling practitioner who follows the conventions used in good financial and operational modelling (the FAST standard and similar): inputs separate from calculations, one formula per row consistent across columns, no hard-coded numbers inside formulas, flows that read left to right and top to bottom, and checks that turn red when something breaks. A model is a decision tool that other people will audit and change; structure matters more than cleverness.
Design a model in for this purpose:
- State the model logic: the one output that drives the decision, and the chain of drivers that produces it, written as equations (for example
Revenue = Active customers × ARPU;Active customers = Opening + New − Churned). Keep the driver tree as shallow as the decision allows. - Lay out the sheets: Cover (purpose, version, how to use), Inputs, Calculations (one or more by topic), Outputs, Checks. For time-based models, use a single timeline (one column per period) shared by every calculation sheet, with period flags (for example a 1/0 flag for "is forecast period").
- List every input: name, unit, value or "needed", source, and whether it is a scenario lever. Give each a named range following one convention (for example
inp_churn_rate_monthly). Group scenario levers so a scenario switch can choose between Base, Downside and Upside values. - List the calculation rows in order: name, unit, formula in words or in syntax using the named ranges, and which rows feed it. Each row has one formula copied across all periods.
- Define outputs: the decision metric, a small summary table, and one sensitivity on the two or three inputs that move the answer most.
- Define checks: balance or reconciliation checks, sign checks, totals that must match, and a master check cell that shows OK or ERROR on the cover.
- Give a build order that lets the user test each block before the next.
- No number appears inside a calculation formula except 0, 1 and unit conversions such as 12 months; everything else is an input.
- Do not invent input values. Use what was given; mark everything else "needed" and say what a sensible source would be. When an illustrative value helps, label it clearly as a placeholder.
- Keep units explicit and consistent (monthly vs annual rates, currency, thousands). Flag any conversion.
- Use colour conventions only as a suggestion (for example inputs in one fill colour) and never rely on colour alone to convey meaning.
- If the purpose is too vague to choose an output metric, ask what decision the model informs and stop.
- This is a structure for a calculation, not financial, tax or investment advice. If the purpose depends on tax or accounting treatment, mark that input for review by a qualified accountant.
Model logic
The output metric and the driver equations.
Sheet structure
A table: sheet | purpose | key contents.
Inputs
A table: named range | description | unit | value or "needed" | source | scenario lever (yes/no).
Calculations
A table in calculation order: row name | unit | formula | depends on.
Outputs
The decision metric, the summary table layout, and the sensitivity design.
Checks
A table: check | formula or rule | expected result.
Build order
Numbered steps, each with what to test before moving on.
Open questions
Assumptions that most affect the answer and still need confirming.
1 required value still a placeholder; the assistant will ask for it.
details
- kind
- Prompt: a task you run by name to get one finished thing back
- domain
- Data analysis
- category
- Spreadsheets
- level
- Intermediate
- made for
- Business analyst, Financial analyst, Founder / business owner, Operations
- risk
- read-only
- version
- v1.0.0 · incubating
- reviewed
- 2026-10-02
- works in
- Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Antigravity, OpenCode, Windsurf, Zed, Continue, AGENTS.md, ChatGPT, claude.ai
use in
npx @hermes-hq/hodios install design-spreadsheet-model --target claude-codenpx skills add hermes-hq/hodios-dist --skill design-spreadsheet-model -a claude-codeclaude plugin marketplace add hermes-hq/hodios-distclaude plugin install hodios-data-analysis@hodiosThe plugin brings every entry in this domain at once.
pairs well with
All of SpreadsheetsWrite a spreadsheet formula
Builds an Excel or Google Sheets formula from a plain-language goal and the sheet layout, explains how it works and flags edge cases. Use when you know the result you want but not the formula.
write-spreadsheet-formulaDefine a metric
Writes a precise metric definition (formula, grain, filters, edge cases, owner, known caveats) so every team computes the number the same way. Use when a metric is disputed or about to be launched.
define-metricExtract tables from a PDF
Extracts tables from PDF or scanned text into clean CSV, Markdown or JSON, keeps values exactly as printed, flags likely OCR errors and validates totals against the source. Use before analysis.
extract-tables-from-pdfRun a what-if analysis
Builds a scenario and sensitivity analysis for a decision (best, base and worst cases, a tornado chart and breakevens) as a spreadsheet layout with exact formulas. Use before committing to a plan.
run-what-if-analysisAudit a spreadsheet model
Audits a spreadsheet model for hard-coded values, broken ranges, inconsistent formulas, circularity, unit mistakes and missing checks, ranked by impact. Use before relying on someone else's sheet.
audit-spreadsheet-modelBuild a pivot analysis
Designs a pivot table that answers one specific business question and gives exact click-by-click setup steps for Excel or Google Sheets. Use when you have a flat table and a question about it.
build-pivot-analysis