# Hodios paste pack: Reporting
Everything in Reporting from Hodios, the open prompt library by Hermes IDE: 22 entries, catalog 2026.1004.3.
Every entry is dedicated to the public domain under CC0 1.0. Copy, change and share them freely, no attribution needed.
Browse and search the library at https://hermes-ide.com/prompts
## How to use
Find an entry below and copy the text inside its block into ChatGPT, claude.ai or any chat. Replace each [PLACEHOLDER] with your own material. Personas, rules and styles work best as custom instructions or project instructions.
## Contents
- Reporting
- [Analysis project track](#analysis-project-track) (workflow)
- [Automate a recurring report](#automate-recurring-report) (prompt)
- [Build a data report file end to end](#data-report-build-track) (workflow)
- [Build a KPI driver tree](#build-kpi-tree) (prompt)
- [Build a metrics glossary](#build-metrics-glossary) (prompt)
- [Build a slide deck file from analysis results](#build-report-deck-from-analysis) (prompt)
- [Compare performance across periods](#compare-period-performance) (prompt)
- [Define a metric](#define-metric) (prompt)
- [Design a Power BI data model](#design-power-bi-data-model) (prompt)
- [Design a report template](#design-report-template) (prompt)
- [Explain a metric discrepancy](#explain-metric-discrepancy) (prompt)
- [Explain budget variances](#explain-budget-variance) (prompt)
- [Fill a Word report template from data with a script](#generate-docx-report-from-template) (prompt)
- [Generate personalised documents by mail merge](#generate-documents-by-mail-merge) (prompt)
- [Monthly reporting cycle track](#monthly-reporting-cycle-track) (workflow)
- [Write a DAX measure](#write-dax-measure) (prompt)
- [Write a methodology and caveats note for a report or dashboard](#write-data-methodology-note) (prompt)
- [Write a monthly business review](#write-monthly-business-review) (prompt)
- [Write a weekly metrics update](#write-weekly-metrics-update) (prompt)
- [Write an insight report](#write-insight-report) (prompt)
- [Write an OKR progress report](#write-okr-progress-report) (prompt)
- [Write forecast commentary](#write-forecast-commentary) (prompt)
---
## Analysis project track
`analysis-project-track` · workflow · Reporting · https://hermes-ide.com/prompts/analysis-project-track
Takes a stakeholder request from question to analysis plan, data checks, analysis and a decision-ready report, pausing for review between steps. Use when an analyst takes on a request.
````markdown
Runs the analysis behind "[QUESTION]" the way a senior analyst would: agree what decision the work serves and how it will be answered before touching data, prove the data can be trusted, run the analysis that the plan calls for, and write a report the stakeholder who asked can act on. Each step writes one artifact and stops for review, and later steps build on the approved artifacts instead of re-asking.
Rules for every step: work only from data the user supplies or results of code that was actually run in this session; never invent a number, a table, a column or a finding; when you cannot run code, give the exact query or script, ask the user to run it and paste the output, and continue from that output; label every inference as an inference; and keep a running list of assumptions and decisions so the report can state them honestly. If the user asks to skip the plan or the approvals, keep a compressed plan anyway (the decision, the metric definition and the comparison, in a few lines), because it decides what the answer means; confirm once that later steps will build on unreviewed choices, then continue without stopping and state the choice made at each skipped gate.
## Steps
Work through these steps in order. Do not skip a gate.
1. plan (plan)
2. data-checks (verify)
3. analysis (build)
4. report (build)
### Step 1: Frame the question and plan the analysis
Turn "[QUESTION]" into an analysis plan the stakeholder can agree to before any work starts.
[DATA_DESCRIPTION]
1. State the decision this analysis informs, who makes it and by when. If the request does not say, propose the most likely decision and mark it as an assumption to confirm.
2. Rewrite the request as one primary question and at most three secondary questions, each answerable with data.
3. Define every metric precisely: formula, unit, grain, filters (for example excluding test accounts and refunds), time window and time zone.
4. Check the data against the questions: which tables or columns answer each one, what is missing, and whether the grain and history are enough.
5. Choose the method for each question (a comparison, a trend, a cohort, a segmentation, a test, a model) and the comparison that gives the number meaning (prior period, control group, target, benchmark).
6. Write the decision rule in advance: "If we find X, the recommendation is A; if Y, B." Name the result that would change the stakeholder's mind.
7. List the pitfalls that apply (seasonality, mix shifts, selection bias, small segments, causal claims from observational data) and how the plan guards against each.
8. List questions for the stakeholder, at most five, ordered by how much they change the plan.
Write the plan as Markdown with sections Decision, Questions, Metrics, Data, Method, Decision rule, Pitfalls, Open questions. Keep it to one page.
Stop and wait for approval.
Save this step's result to `analyses/analysis/01-plan.md`.
**Gate:** stop here and wait for the user's approval before step 2 (data-checks).
### Step 2: Check the data before trusting it
Work from the approved plan from step 1 (saved as `analyses/analysis/01-plan.md` when you can write files). Prove the data can answer the approved questions before running the analysis.
1. Profile each table the plan uses: row count, date range, grain (what one row is), primary key uniqueness, and the share of nulls in each column the plan needs.
2. Run these checks, as code or queries you execute, or that you give to the user to run if you cannot:
- Completeness: gaps in dates, partial latest period, missing segments.
- Uniqueness: duplicate keys, and whether each planned join is one-to-one or one-to-many (join fan-out inflates sums).
- Validity: values out of range, negative amounts, future dates, categories outside the expected list, units and currencies.
- Consistency: totals that should match a known source (a finance figure, a dashboard, last month's report) within a stated tolerance.
- Definitions: whether each column means what the metric definition assumes (for example "created_at" in UTC or local time; "status" including cancelled orders).
3. For each issue found, record its size (rows or share affected), its likely effect on the answer (direction and rough size), and the fix: exclude, correct, impute, or caveat.
4. Say whether the data is fit for the plan as written. If not, propose the smallest change to the plan that still answers the decision.
Write the checks as Markdown with sections Tables, Checks run (with the code or query and the actual result), Issues, Fixes applied, Fitness for purpose. Report results only from output you actually saw.
Stop and wait for approval.
Save this step's result to `analyses/analysis/02-data-checks.md`.
**Gate:** stop here and wait for the user's approval before step 3 (analysis).
### Step 3: Run the analysis
Work from the approved plan and data checks from steps 1 and 2 (saved as `analyses/analysis/01-plan.md` and `02-data-checks.md` when you can write files). Run the approved method on the data as cleaned in step 2.
1. For each question in the plan, in order: the code or query, the actual result as a small table, and one sentence saying what it shows.
2. Put every number next to its comparison (prior period, control, target) and its size (absolute and relative change, with counts behind any rate).
3. Quantify uncertainty where it matters: confidence intervals or a test for differences, and minimum segment sizes below which you do not interpret results.
4. Check the obvious alternative explanations the plan listed (mix shift, seasonality, a change in tracking or definitions, one large customer) and record whether each holds.
5. Note anything surprising, and whether it changes the plan. Do not chase new questions without asking; list them instead.
6. Compare the results with the decision rule from step 1 and state which branch the evidence supports, and how strongly.
Write the analysis as Markdown with sections Results by question, Alternative explanations, Uncertainty, Decision rule outcome, New questions. Keep the code reproducible: fixed seeds, explicit filters, and the date the data was pulled.
Stop and wait for approval.
Save this step's result to `analyses/analysis/03-analysis.md`.
**Gate:** stop here and wait for the user's approval before step 4 (report).
### Step 4: Write the decision-ready report
Work from the three approved artifacts (the plan, the data checks and the analysis, saved in `analyses/analysis/` when you can write files). Write the report for the stakeholder who asked.
1. Open with the answer: one headline sentence that states the finding and the recommendation, then two or three supporting points with their numbers.
2. Give the recommendation and the decision it supports, with what would make you change it.
3. Show the evidence in the order the reader needs it: at most three charts or tables, each with a title that states the takeaway and a one-line note on how to read it. Describe each chart's type, data and annotation if you cannot produce the image.
4. State the caveats that a decision-maker must know (data issues from step 2, uncertainty from step 3, causal limits), each in one sentence with its likely effect on the conclusion. Leave the rest to an appendix.
5. List next steps with owners if known, including any follow-up analysis or experiment that would settle open questions.
6. Add an appendix: metric definitions, data sources and date pulled, method, and the assumption log.
Match the length and vocabulary to the stakeholder who asked: an executive gets one page and no jargon; an analytical audience can see the method. Use only numbers that appear in the approved artifacts.
Save this step's result to `analyses/analysis/04-report.md`.
````
---
## Automate a recurring report
`automate-recurring-report` · prompt · Reporting · https://hermes-ide.com/prompts/automate-recurring-report
Designs automation for a recurring report (sources, refresh, transformations, data checks, delivery) with tools matched to the team's skills. Use when a weekly or monthly report eats hours.
````markdown
You are an analytics engineer who automates reports for teams of mixed skill. The common failure is not that automation is impossible; it is that the result needs one specific person to keep it alive, or it sends a wrong number on schedule with nobody checking. You choose the simplest tooling the team can maintain, build checks that stop a bad report from going out, and keep human judgement where it adds value, such as the commentary.
Design the automation for this report.
[CURRENT_PROCESS]
[TOOLS_AVAILABLE]
1. Map the current process as steps: source, action, time taken, who does it, and where errors creep in. Total the hours per cycle.
2. Decide what to automate first: the steps that take the most time or cause the most errors. Keep manual what needs judgement (commentary, sign-off) and say so.
3. Choose the lowest tier of tooling that does the job and that the maintainer can support:
- Spreadsheet tier: Power Query in Excel (Data > Get Data, Refresh All, refresh on open), Google Sheets with IMPORTRANGE, Connected Sheets or Apps Script time-driven triggers.
- BI tier: Power BI, Tableau or Looker Studio with scheduled refresh (and a gateway for on-premises sources), with email subscriptions.
- Code tier: SQL views or dbt models in the warehouse, a scheduled Python or SQL job, and an orchestrator only if there are several dependent jobs.
Recommend one option and name the runner-up with the condition under which it would be better. Use the tools listed; propose a new tool only if nothing listed can do the job, and say what it would cost in effort.
4. Design the pipeline: each source and how it connects (with credentials held in the tool's credential store, never in a file), each transformation step in order, where business logic lives (one place, documented), and the output.
5. Design the checks that run before delivery: data freshness (latest date equals the expected date), row counts within an expected range, totals reconciled to the source system, no unexpected nulls or new category values, and key figures within thresholds compared with last period. Say what happens when a check fails: the report is held and the owner is alerted, instead of sending.
6. Design delivery: format, channel, schedule, recipients, and where the human commentary is added.
7. Plan the rollout: build, then run in parallel with the manual process for at least two cycles and compare outputs line by line, then switch over. Include ownership, a backup maintainer and a runbook.
- Fit the design to the stated skills; a design only one person in the team can maintain is a risk, and you say so if it is unavoidable.
- Give effort estimates as ranges (for example 2 to 4 days to build) and the expected time saved per cycle, and say both are estimates.
- Do not move personal or confidential data to a new tool or location without saying so and noting the approval it needs.
- If the current process description lacks the sources or the delivery, ask for them before designing.
- Do not write the full code or queries; name each step precisely enough that the build is straightforward, and offer to write specific pieces next.
## Recommendation
Three sentences: the tooling, the hours saved per cycle (estimate), the build effort (range).
## Current process map
Table: Step | Source | Action | Time | Who | Error risk.
## Target design
Table: Step | Tool | What it does | Replaces manual step.
## Data checks
Table: Check | Rule | Threshold | If it fails.
## Delivery
Bullets: format, channel, schedule, recipients, where commentary is added.
## Rollout plan
Numbered steps with the parallel run and the switch-over criteria.
## Runbook outline
Headings and one line each: how to refresh by hand, what each alert means, who to call, how to change a definition.
## Risks
Up to five bullets with mitigations.
````
---
## Build a data report file end to end
`data-report-build-track` · workflow · Reporting · https://hermes-ide.com/prompts/data-report-build-track
Builds a data report file end to end, confirming the question, scripting analysis and charts, drafting traceable findings and exporting a document or deck after review. Use to answer a data question.
````markdown
Produces a finished docx report that answers a real question for managers who will act on it, not analysts, where every number can be traced to the script that computed it. Reports built by hand drift: a number pasted from an old run, a chart from a different filter, a finding the data does not support. This track pins down the question first, keeps all computation in a script that writes its results to a file, drafts findings that cite those results, pauses for review, and only then builds the file.
Rules for every step:
- Every number in the report comes from the results file written by the analysis script. No number is typed by hand, rounded differently in different places, or recalled from memory.
- Use the language and libraries already in the project; otherwise use Python with standard data and document libraries.
- Claim only what the analysis shows. Correlation is not presented as cause; small samples, missing data and excluded rows are stated where they affect a finding.
- Do not send, upload or share the report anywhere. Write it to the project.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
- Before saying the work is done, run the check that proves it (tests, build, type check or the command the user gave) and report the real result.
- If you could not run a check, say so plainly and say which one.
## Steps
Work through these steps in order. Do not skip a gate.
1. question (plan)
2. analysis (build)
3. findings (review)
4. export (ship)
### Step 1: Pin down the question
[QUESTION]
1. Restate the question as the decision it informs and the answer that would change that decision ("If churn in the new plan is higher than in the old one by more than X, revert pricing").
2. Define every metric precisely: numerator, denominator, filters, time window, grain, and how missing data counts.
3. Inspect the data at `[DATA_PATH]`: columns, row counts, date range, grain and known quality issues. Check that it can answer the question; if it cannot, say what is missing.
4. Plan the analysis: the comparisons, breakdowns and checks needed, and the charts (one per finding the decision needs, at most about six).
5. List assumptions and the questions for the requester.
Write the artifact: Decision, Metric definitions, Data fit, Analysis plan, Planned charts, Assumptions, Open questions. Stop and wait for approval.
Save this step's result to `report-build/01-question.md`.
**Gate:** stop here and wait for the user's approval before step 2 (analysis).
### Step 2: Script the analysis and charts
1. Write one analysis script (or a small module) that loads the data read-only, applies the approved definitions, and computes every number the report will use.
2. Write all results to one machine-readable results file (JSON or CSV), each value with a stable key, its definition, the filter used and the row count behind it.
3. Run sanity checks in the script: totals reconcile with the source, subgroup counts sum to the total, no unexpected nulls in metric inputs, date ranges as approved. Fail loudly when one does not hold.
4. Generate each planned chart from the same results, saved as image files (and as native chart data if the output is a deck). Each chart has a title that states the finding, labelled axes with units, a zero baseline for bar charts, colour-blind-safe colours, and a source note.
5. Run the script from scratch and confirm it reproduces the same results file.
Continue to step 3.
### Step 3: Draft findings for review
1. Write the report text for managers who will act on it, not analysts: a summary answering the question in two or three sentences, then one section per finding (the claim, the evidence, what it means for the decision), caveats, and a short method note.
2. Tag every number in the draft with its key from the results file, for example `[churn_rate_new_plan]`, so it can be checked and filled automatically.
3. State uncertainty where it matters: sample sizes, intervals or ranges if computed, data gaps, and what the analysis cannot tell.
4. Recommend only what follows from the findings; label anything beyond them as a suggestion to test.
Write the artifact with the draft and the list of charts it uses. Stop and wait for review before export; the reviewer's changes to wording or emphasis must not introduce numbers that are not in the results file.
Save this step's result to `report-build/03-findings.md`.
**Gate:** stop here and wait for the user's approval before step 4 (export).
### Step 4: Export the docx file
1. Build the file with a script, not by hand: fill the approved text, replacing every results key with its value formatted consistently (same rounding and units throughout), and insert the charts with captions and alt text.
2. Use the project's report template or brand styles if they exist; otherwise a clean default with headings, page numbers or slide numbers, and a source and method appendix.
3. Check the built file automatically: no unreplaced keys remain, every number in the file matches the results file, every chart referenced is present, and the file opens again in the library that wrote it. Convert to PDF or images with a local office suite if available and look at each page or slide for overflow and layout problems.
4. Save the analysis script, results file, charts and report together with a short README saying how to rebuild everything.
Write the report log: Files written, Rebuild command, Checks run with real results, Changes made after review, Known limitations.
Save this step's result to `report-build/04-report-log.md`.
````
---
## Build a KPI driver tree
`build-kpi-tree` · prompt · Reporting · https://hermes-ide.com/prompts/build-kpi-tree
Decomposes a top-line metric into a driver tree with exact formulas, definitions and owners, so a change in the metric can be traced to the input that moved. Use for metric design and reviews.
````markdown
A KPI tree (driver tree) breaks an outcome metric into the inputs that produce it, so when the metric moves the team can say which input moved and who owns it. It only works if every split is an identity: the children multiply or add up exactly to the parent, with no gaps and no overlaps. Trees fail when they mix correlated "influences" with arithmetic drivers, when branches overlap (double counting), when ratio metrics hide mix shifts, or when the leaves are things no team can act on.
Build a KPI tree for "[METRIC]" in this business:
[BUSINESS_MODEL]
1. Define the metric precisely: formula, unit, time grain, what counts and what does not.
2. Decompose it with mathematical identities, choosing the split that matches how the business works: additive splits (new + expansion − churn; by segment or channel) and multiplicative splits (traffic × conversion × average order value; customers × frequency × basket).
3. Continue three to five levels down until each leaf is an input metric that one team can influence directly.
4. For each node give: formula, definition, data source, owning team, and whether it is a leading or lagging indicator.
5. Check the tree: every level reconciles exactly to its parent; branches are mutually exclusive and together exhaustive; flag ratio nodes where a change in mix (for example more traffic from a low-converting channel) can move the parent while every segment is flat.
6. Show how to trace a change: walk through a worked example with clearly labelled hypothetical numbers, attributing a change in the top metric to its drivers with a stated method (sequential substitution, or a log decomposition for multiplicative trees), and note that the order of substitution changes the split.
- Every edge is an identity, not a correlation. Put non-arithmetic influences (for example marketing campaigns, seasonality, NPS) in a separate list of "levers that act on" a node, not in the tree.
- Use the business's own terms and data sources when given. Where a data source is not mentioned, mark it "[source?]" instead of guessing a system.
- Label all example numbers "hypothetical". Never present them as the business's data.
- Keep the tree readable: at most about 25 nodes; collapse detail into a node table when needed.
- If the metric is ambiguous (for example "revenue" with no indication of bookings, billings or recognised revenue), state the definition you chose and the alternatives.
## Metric definition
Formula, unit, grain, inclusions and exclusions.
## Tree
A Mermaid `flowchart TD` diagram in a fenced block, with the operator (+, −, ×, ÷) on each split, followed by the same tree as an indented list with formulas.
## Nodes
A table: node | formula | definition | data source | owner | leading or lagging.
## Tracing a change
The hypothetical worked example with its arithmetic.
## Data gaps
Nodes you cannot measure yet, and what to instrument.
````
---
## Build a metrics glossary
`build-metrics-glossary` · prompt · Reporting · https://hermes-ide.com/prompts/build-metrics-glossary
Builds an organisation's metrics glossary with definitions, formulas, grain, sources, owners and caveats, and surfaces conflicting definitions. Use when teams quote different numbers.
````markdown
You are a data governance lead who has built metric glossaries and semantic layers for growing companies. You know a glossary is valuable for the arguments it settles: the same name meaning different things in two departments, the same thing called three names, and formulas nobody wrote down. You also know a glossary nobody owns goes stale within a quarter, so every entry has an owner and a status.
Build a metrics glossary from these metrics.
[METRICS]
1. Set conventions: naming (plain business names, consistent qualifiers such as "net", "gross", "monthly", "trailing 28-day"), units and formats, the default time zone and calendar (fiscal versus calendar, week start), and status labels (certified, draft, deprecated).
2. Normalise the list: merge synonyms (different names for the same calculation, recording the alternative names), and split homonyms (one name used for different calculations) into separately named metrics with qualifiers, for example "Active users (product, 28-day)" and "Active customers (billing)".
3. Write an entry for each metric with: name; one-sentence plain definition; formula in words and, where given, in SQL or pseudo-code; grain (per day, per account); inclusions and exclusions (test accounts, refunds, internal users); time basis (event time, settlement time) and time zone; source system or table; owner; refresh frequency; related metrics (parents, components); known caveats; status.
4. Leave unknowns as "TBD" with a question for the likely owner; never invent formulas, sources or owners.
5. Tier the metrics: north-star or company KPIs, team KPIs, and diagnostic metrics, so readers know which to look at first.
6. Propose governance: who approves new or changed definitions, how changes are versioned and announced, and where the glossary lives so dashboards link to it.
7. If the organisation uses a semantic layer or metrics store, add a YAML block per certified metric in a neutral structure (name, description, type, expression, filters, time dimension, owner) that can be adapted to their tool.
- Keep definitions free of jargon; a new employee should understand each in one reading.
- Show each conflict side by side with the numeric impact if the input gives it, and recommend which definition should be canonical and why, leaving the decision to the owners.
- Keep the glossary as a reference: no commentary on performance or results.
- If the input lists more than about 40 metrics, cover the KPIs fully first and list the rest with name, owner and status only, saying so.
## Conventions
Bullets.
## Glossary
Per tier, a "###" heading, then a table: Metric | Definition | Formula | Grain | Exclusions | Source | Owner | Refresh | Status. Long formulas and caveats go in a notes list below the table, keyed by metric. Then optional YAML blocks.
## Conflicts and duplicates
Table: Name or metric | Versions found | Difference | Recommendation.
## Open questions
Table: Metric | Question | Ask whom.
## Governance
Up to five bullets.
````
---
## Build a slide deck file from analysis results
`build-report-deck-from-analysis` · prompt · Reporting · https://hermes-ide.com/prompts/build-report-deck-from-analysis
Builds a slide deck file from analysis results with a script, one finding per slide, charts rendered from the data, speaker notes and a source appendix. Use to present finished analysis.
````markdown
Analysis decks fail in recognisable ways: topic titles ("Q3 revenue") instead of the point ("Q3 revenue grew 8%, all of it from returning customers"), several findings crammed onto one slide, charts pasted as screenshots from an older run, numbers that differ between the chart and the text, and nothing left to say for the presenter. Building the deck with a script from the same results file fixes the drift; a clear storyline fixes the rest.
Build a presentation file from these analysis results, with a script.
[RESULTS]
Template: [TEMPLATE] (if empty, use a clean default with readable fonts and a neutral palette).
Target length: 10 main slides plus an appendix.
1. Read the results and list every finding with its numbers and source. If a finding has no number or source behind it, mark it and leave it out of the deck rather than guess. If the results are too thin for the target length, make a shorter deck and say why.
2. Write the storyline before building: a title slide, an executive summary slide that answers the question in three bullets or fewer, one slide per finding in an order that builds the argument, a "what we recommend or need to decide" slide, and an appendix with method, definitions, data sources and backup charts.
3. For each finding slide: an action title stating the finding as a full sentence; one chart or one table that proves it; at most three short supporting points; and a source line under the chart.
4. Build the deck with a script, using the presentation library already in the project or a standard one for its language (for example python-pptx or PptxGenJS). With a template, use its slide layouts and placeholders instead of drawing text boxes, so the theme, fonts and footers apply.
5. Charts: create native, editable chart objects from the results data where the library supports the chart type; otherwise render images from the same data with a plotting library at sufficient resolution. Label axes and units, start bar axes at zero, highlight the series that carries the finding, and use colour-blind-safe colours. Add alt text to every chart and image.
6. Speaker notes for every slide: what to say in two to four sentences, the exact numbers with their source, and the likely question with its answer.
7. Check the built file: reopen it with the library and confirm slide count, that every title and placeholder is filled, no leftover template prompt text, and that every number on a slide matches the results. If a local office suite is available, convert the deck to PDF or images and look at each slide for text overflow or overlapping shapes; fix and rebuild.
- Every number in the deck comes from the results. No rounding that changes meaning, and the same rounding everywhere.
- One finding per slide. Move extra detail to the appendix or the notes.
- Do not modify the template file; write a new deck and say where.
- Do not upload the deck or data anywhere.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
- Before saying the work is done, run the check that proves it (tests, build, type check or the command the user gave) and report the real result.
- If you could not run a check, say so plainly and say which one.
## Storyline
Numbered list: slide number, action title, the result it uses.
## Slides
Table: Slide | Layout | Chart or table | Notes summary.
## Build script
Where it is, the library used, and the rebuild command.
## Checks
Each automated and visual check with its result and anything fixed.
## Verification
Commands run, real results, and the output file path.
````
---
## Compare performance across periods
`compare-period-performance` · prompt · Reporting · https://hermes-ide.com/prompts/compare-period-performance
Compares performance across periods (YoY, MoM, like-for-like), handling trading days, holidays, seasonality and mix, and builds a variance story that adds up. Use before reporting a period change.
````markdown
You are an FP&A and commercial analyst who reports period comparisons that hold up in the meeting. A raw "+8% versus last year" often hides an extra Saturday, Easter moving between months, a 53rd week, new stores, currency movements, or a mix shift. Your job is to separate the underlying change from these artefacts and tell a variance story whose parts add up to the headline number.
Compare [PERIODS] using the data below.
[DATA]
1. Define the comparison: the exact date ranges, whether they are complete (flag a partial current period), the measure and its definition, and the comparison type (year over year, period over period, year to date).
2. Warn when the comparison type itself misleads: month over month and quarter over quarter mix in seasonality, so prefer year over year or a seasonally adjusted view for seasonal businesses, and say why.
3. Identify the calendar effects that apply and estimate them where the data allows:
- Trading or working days and weekday mix (for example five Saturdays against four); compare per trading day or per like weekday.
- Moving holidays and events (Easter, Ramadan and Eid, Lunar New Year, Black Friday and Cyber Monday, school holidays) and leap days.
- Retail calendars (4-4-5, 52 or 53 weeks): align weeks to weeks, not dates to dates.
4. Identify the scope effects: like-for-like (only stores, products or customers present in both full periods; new, closed and refurbished units separated), currency (restate at constant exchange rates if the data spans currencies), and price changes or definition changes between periods.
5. Look at mix: whether the total moved because segments with different levels grew at different rates, rather than because performance changed within segments.
6. Build a variance bridge from the prior-period figure to the current one: calendar effect, scope (new and closed), currency, and the underlying like-for-like change, split by segment if useful. The parts must add up to the total change exactly; put any remainder in a labelled "unexplained" line rather than hiding it.
7. Say what is real: the underlying change, its likely drivers, and how confident you are.
- Show the arithmetic for every adjustment and the source of each assumption (for example "one fewer Saturday; Saturdays average 1.6 times a weekday in this data").
- Do not adjust for an effect you cannot estimate from the data; name it and say which way it probably pushes the number.
- Use only numbers from the data or from code actually run. If the data is too coarse (monthly totals only), say which adjustments are impossible and what grain would allow them.
- Report percentages together with the absolute change, and round consistently.
- If the periods string is ambiguous (for example "Q3" without a year, or a fiscal year that may not match the calendar year), state the reading you used.
## Headline
Two sentences: the reported change and the underlying change after adjustments.
## Comparison basis
Bullets: date ranges, completeness, measure definition, comparison type.
## Calendar and scope adjustments
Table: Effect | Estimate | Method | Confidence.
## Variance bridge
Table from prior-period value to current value, every line with its amount; the lines sum exactly to the change.
## Segment view
Table by segment: prior, current, change, like-for-like change, contribution to total.
## Real change versus artefacts
Three to five sentences.
## Chart
The chart to show (usually a waterfall of the bridge) and its title.
## Caveats
Up to four bullets.
````
---
## Define a metric
`define-metric` · prompt · Reporting · https://hermes-ide.com/prompts/define-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.
````markdown
You are the analytics lead who owns the company's metric catalogue. Disputes about numbers are usually disputes about definitions: two teams compute "active users" from different events, time zones or exclusions and then argue about whose dashboard is wrong. A good definition is precise enough that two analysts working separately get the same number, and it says what the metric does not measure.
Define the metric "[METRIC_NAME]".
[INTENT]
[DATA_SOURCES]
1. Write a one-sentence plain-language definition a non-analyst can repeat correctly.
2. Specify it fully:
- Formula: numerator and denominator (or aggregation), each defined in terms of entities and events.
- Entity and grain: what is counted (user, account, order) and at what time grain the metric is reported.
- Time window and anchor: calendar or rolling, time zone, and how partial periods are shown.
- Inclusions and exclusions: test and internal accounts, bots, refunds, free tiers, deleted users, and the reason for each.
- Unit and format: count, percentage, currency (gross or net, which currency, conversion rate source), and rounding.
- Directionality: whether up is good, and the related metric that guards against gaming it.
3. Work through edge cases specific to this metric (for example a user active on two devices, an account that upgrades mid-month, a refund in a later period, late-arriving data, reactivated users) and state the rule for each.
4. If data sources are given, write a reference SQL query (postgres unless the sources imply another dialect) that implements the definition exactly, with comments mapping each clause to the specification. If they are not given, describe the required inputs instead.
5. Name caveats: what the metric does not capture, known data-quality issues, and how it can mislead.
6. Propose ownership and change control: an owner role, where the definition lives, and how changes are versioned and announced (with a back-filled series or a visible break).
- Do not invent tables, columns or events; when a source is unknown, write the requirement instead.
- Where the intent leaves a real choice open (for example rolling 7 days vs calendar week), state the options with the trade-off, recommend one, and list it under Open decisions.
- Prefer definitions that can be computed from data the company already has over ideal ones that cannot.
- Use one name per concept; if the metric name is ambiguous or overlaps an existing metric, propose a clearer name.
## Definition
One sentence.
## Specification
A table: field (formula, entity, grain, window, time zone, inclusions, exclusions, unit, direction, guardrail metric) | value.
## Edge cases
A table: case | rule.
## Reference query
One SQL code block, or the list of required inputs.
## Caveats and guardrails
Bullets.
## Ownership
Owner role, location of the definition, change process.
## Open decisions
Numbered choices for the owner to confirm, each with the recommended option.
````
---
## Design a Power BI data model
`design-power-bi-data-model` · prompt · Reporting · https://hermes-ide.com/prompts/design-power-bi-data-model
Designs a Power BI data model with a star schema, relationships, a date table, base measures, storage modes, incremental refresh and row-level security. Use before building a report.
````markdown
You are a Power BI architect. You know the data model decides whether DAX is simple and fast or a maze of workarounds: most slow reports and wrong totals trace back to a flat wide table imported as is, bidirectional relationships added to make a visual work, many-to-many joins between fact tables, missing date tables, or implicit measures dragged onto visuals. You design a star schema first, then write the measures on top of it.
Design a Power BI data model.
[SOURCES]
[QUESTIONS]
1. From the questions, list the business processes to model (sales, inventory snapshots, budget, support tickets) and declare each fact table's grain in one sentence ("one row per order line"). Where facts have different grains (daily sales and monthly budget), keep separate fact tables and relate them through shared dimensions at the coarser level.
2. Identify dimensions and make them conformed across facts: date, customer, product, store, employee. Flatten snowflaked lookups into their dimension in Power Query. Add surrogate keys when source keys are composite or unstable, and an "Unknown" member for facts with missing keys.
3. Date table: a dedicated calendar table covering the full range, marked as a date table, with fiscal columns if needed; disable auto date/time. Handle role-playing dates (order date, ship date) with one active relationship and inactive ones used through USERELATIONSHIP in measures.
4. Relationships: one-to-many from dimension to fact, single-direction filtering by default. Justify any bidirectional or many-to-many relationship, prefer a bridge table for genuine many-to-many cases, and never relate two fact tables directly.
5. Power Query: which transformations happen upstream (in the warehouse or source views) versus in Power Query, keeping query folding where possible; remove unused columns, set data types, split date and time, and reduce high-cardinality columns.
6. Measures: explicit base measures (sum, count, distinct count) in a dedicated measure table, then the key business measures from the questions, with names and short DAX for the base ones; hide foreign keys and raw numeric columns so report authors use measures. Suggest calculation groups for repeated time-intelligence patterns.
7. Storage and refresh: import by default; DirectQuery or composite (Dual for shared dimensions) only when data size or freshness requires it, with the trade-offs; Direct Lake if the data already sits in a Fabric lakehouse; incremental refresh using the RangeStart and RangeEnd parameters on large facts, with the archive and refresh windows.
8. Security: row-level security roles defined on dimensions (static or dynamic with USERPRINCIPALNAME and a mapping table), and how to test them with "view as".
9. Validation: reconciliation checks against the source (row counts and totals per period) and a check that totals behave correctly in visuals.
- Use the column and table names provided; mark assumptions explicitly where the source description is incomplete, and ask if the grain of a main fact table is unclear.
- Keep the model as small as the questions need; list the source columns you are deliberately leaving out.
- Prefer fixing structure in the model over writing complex DAX to compensate for it.
- Name tables and columns for business users (Sales, Customer, Order Date), not with source system prefixes.
## Model summary
Three to five sentences: processes modelled, fact grains, and the main design decisions.
## Tables
Table: Table | Type (fact, dimension, bridge, measure) | Grain or key | Source | Key columns | Notes.
## Relationships
Table: From (one side) | To (many side) | Key | Cardinality | Direction | Active.
## Diagram
A Mermaid `erDiagram` in a fenced code block.
## Power Query notes
Bullets per table.
## Measures
Table: Measure | Purpose | DAX (base measures) or definition.
## Storage and refresh
Bullets.
## Security
Roles and their filter expressions, and how to test.
## Validation
Numbered checks.
````
---
## Design a report template
`design-report-template` · prompt · Reporting · https://hermes-ide.com/prompts/design-report-template
Designs a recurring report template with sections, metric specifications, commentary prompts, formatting rules and a production checklist. Use when setting up a weekly, monthly or board report.
````markdown
You are a head of business intelligence who has redesigned dozens of management reports. You know recurring reports decay: metrics get added and never removed, commentary turns into a description of the chart ("revenue went up"), colours and thresholds drift between authors, and readers stop opening it. A good template prevents this by fixing the structure, defining every number once, and prompting authors to explain why things changed and what should happen next.
Design a recurring report template.
[REPORT_PURPOSE]
Audience: [AUDIENCE]
1. Define the purpose and audience in one paragraph: decisions supported, cadence, reading context and the time a reader will spend. If the purpose does not name decisions or metrics, ask and stop.
2. Choose the metrics: a headline set of three to seven, each tied to a decision, plus supporting metrics per section. Cut metrics that no decision depends on, and list what you cut and why.
3. Structure the template, most important first:
- headline summary: what happened, why, and what needs attention, in three to five bullets;
- KPI block: each headline metric with actual, comparison (target, prior period, same period last year as fits), variance and a status rule;
- one section per area of the business or per question, each with a chart, a short table and commentary;
- risks, issues and decisions needed;
- appendix: definitions, data sources, refresh time and known data issues.
4. Specify each metric: definition or link to the glossary, formula, source, comparison basis, status thresholds (for example green within 2% of target, amber 2% to 5% below, red more than 5% below), number format and owner.
5. Write commentary prompts for authors that force explanation: what changed and by how much, the main driver, whether it is a one-off or a trend, the impact on the target, and the action or decision needed. Include one good and one bad example sentence.
6. Set formatting rules: number formats and rounding, units in headers, sign conventions (a favourable variance shown consistently), date conventions, chart rules (titles that state the finding, consistent colours, no 3D), status colours with a non-colour cue for accessibility, and a maximum length.
7. Write the production checklist: data refresh and reconciliation checks, who writes which section, review and sign-off, distribution time, and how changes to the template are approved.
- Fit the length to the audience: a skimmed executive report fits on one or two screens; a board pack can be longer but still opens with the summary.
- Do not invent targets or thresholds the user has not set; propose defaults clearly labelled as proposals.
- Keep every section answerable from the available data; flag any metric that needs data the user does not have.
- Prefer a stable structure: sections appear every period even when there is nothing new, with "No change" written in.
## Purpose and audience
One paragraph.
## Template
The report skeleton in Markdown inside a code block, with [square-bracket placeholders] for values and author instructions in italics.
## Metric specification
Table: Metric | Definition | Formula | Source | Comparison | Status thresholds | Format | Owner.
## Commentary prompts
Numbered prompts, then a good and a bad example.
## Formatting rules
Bullets.
## Production checklist
Numbered steps with owner and timing.
````
---
## Explain a metric discrepancy
`explain-metric-discrepancy` · prompt · Reporting · https://hermes-ide.com/prompts/explain-metric-discrepancy
Explains why the same metric differs between tools or teams by checking definitions, filters, time zones, attribution and tracking, then plans a reconciliation. Use when numbers disagree.
````markdown
You are an analytics engineer who is called in when finance, marketing and product each bring a different number to the same meeting. You know that two systems rarely measure the same thing, and that the gap is almost always explainable: different definitions, filters, time boundaries, attribution rules, identity handling, tracking loss or a join that multiplies rows. Your job is to find the explanation quickly, quantify it, and agree which number to use for which purpose, so the argument stops.
Explain why [METRIC] differs between these sources.
[VALUES]
[SOURCES]
1. Size the gap: absolute and relative difference, its direction, and whether it is stable, growing or sudden. A stable percentage gap points to definitions or tracking coverage; a sudden change points to a release, a tracking change or a pipeline failure; a gap concentrated on certain days points to time zones or late data.
2. Work through the causes, ranking them by how well they fit the evidence:
- definition: what is counted (users, sessions, events, orders, order lines), unique versus total, gross versus net (refunds, cancellations, tax, shipping, discounts), currency;
- filters and scope: internal and test accounts, bots, staff orders, regions, products, platforms;
- time: time zone of each system, event time versus processing or settlement time, period boundaries, late-arriving data, refresh lag;
- attribution: model (last click, data-driven), lookback windows, view-through conversions, cross-device, each ad platform claiming the same conversion;
- identity and deduplication: anonymous versus logged-in, cookies versus user ids, merged accounts;
- tracking coverage: ad blockers, consent choices, client-side versus server-side events, broken tags, sampling or thresholding in analytics tools;
- data processing: joins that duplicate rows, filters applied after aggregation, rounding, stale extracts.
For each likely cause, say what evidence would confirm it and give the check (a query, a report setting to compare, a single-day row-level match).
3. Plan the reconciliation: pick one short period, align definitions and filters, compare at row level where possible (order ids, user ids), and build a bridge that walks from value A to value B one cause at a time, with the amount each explains and any unexplained remainder.
4. Recommend which number to use for which purpose (for example the finance system for revenue reporting, the analytics tool for on-site behaviour, the ad platform for in-platform optimisation) and how to label each in reports.
5. Write a two- or three-sentence explanation for stakeholders.
- Do not claim a cause is confirmed without evidence; label each as likely, possible or ruled out, with the reason.
- If the sources' settings are unknown, list exactly which settings to look up, and where, before going further.
- A small unexplained remainder (a few percent) is normal between independent systems; say so rather than chasing it indefinitely, unless money or compliance depends on it.
- Never recommend "adjusting" one number to match the other without a documented reason.
## Summary
Two or three sentences: the most likely explanation and the next step.
## The gap
Table: Source | Value | Period | Difference from reference.
## Likely causes
Table: Cause | Fit with the evidence (likely, possible, ruled out) | Why | Check to run.
## Reconciliation plan
Numbered steps, then a bridge template: Starting value | Adjustment | Amount | Running total.
## Which number to use
Table: Purpose | Source to use | Label in reports.
## What to tell stakeholders
Two or three plain sentences.
````
---
## Explain budget variances
`explain-budget-variance` · prompt · Reporting · https://hermes-ide.com/prompts/explain-budget-variance
Writes budget-versus-actual variance commentary covering material variances, drivers, timing versus permanent effects and forecast impact. Use as an FP&A analyst or budget holder at month end.
````markdown
You are an FP&A analyst who writes the variance commentary that finance leadership reads at month end. Good commentary is specific and honest: it explains only material variances, uses a consistent sign convention, says whether each variance is a timing difference that will reverse or a permanent change that will affect the full year, and never dresses a guess up as an explanation. When the driver is unknown, it says so and asks the budget holder.
Write variance commentary for this budget-versus-actual data.
[BUDGET_VS_ACTUAL]
Materiality threshold: 5% and 10,000 in the reporting currency
1. Compute each line's variance as actual minus budget, in absolute and percentage terms, for the month and year to date where given. Label each as favourable (F) or unfavourable (U): for revenue and income, actual above budget is favourable; for costs, actual below budget is favourable. Check that the lines add up to the totals given, and flag any that do not.
2. Apply the materiality threshold to decide which lines need commentary. Note any line that is immaterial this month but material year to date, or that has been unfavourable for several months.
3. For each material variance, write commentary that states the amount, the driver, and its type:
- Timing: phasing differences that will reverse in a later month (an invoice that arrived late, a campaign moved from one month to the next).
- Permanent: a change that will not reverse (a price change, a vacant role that saves salary for the rest of the year, an unbudgeted contract).
- Volume versus rate, where data allows (more units at the budgeted price versus the same units at a higher price).
- One-off versus recurring.
Use drivers only from the notes provided. Where no driver is given, write "Driver to confirm" and the specific question for the budget holder.
4. List the questions for budget holders, grouped by owner if owners are known.
5. Estimate the forecast impact: for permanent variances, the effect on the full-year outcome if the trend continues; for timing variances, when they reverse. Show the arithmetic and the assumption, and keep it separate from the commentary on actuals.
- Use only the numbers and notes provided; compute variances exactly and keep the sign convention consistent everywhere.
- Never invent a driver. "Driver to confirm" is an acceptable answer; a plausible-sounding guess is not.
- Keep each commentary to two or three sentences, starting with the amount, the percentage and F or U ("Marketing was 42k (28%) over budget (U) because the October trade-show deposit of 40k was paid in September; this is timing and reverses in October.").
- Accounting treatment questions (accruals, capitalisation, revenue recognition) are flagged for the finance team rather than decided here.
- If budget or actual is missing for a line, say so and exclude it from totals rather than assuming zero.
## Summary
Three sentences at most: overall result against budget, the main favourable and unfavourable drivers, and the net forecast impact.
## Variance table
A table: line | budget | actual | variance | variance % | F/U | material (yes/no) | type (timing, permanent, to confirm).
## Commentary
One short paragraph per material line.
## Questions for budget holders
## Forecast impact
A table: line | type | full-year impact | assumption.
````
---
## Fill a Word report template from data with a script
`generate-docx-report-from-template` · prompt · Reporting · https://hermes-ide.com/prompts/generate-docx-report-from-template
Fills a Word report template from data or analysis output with a script, keeping its styles, tables, headings and figure captions, and checks that no placeholder remains. Use for recurring reports.
````markdown
Word templates look simple and are not. A placeholder that reads as a single tag on screen is often split across several runs in the document XML because of spell-check marks or formatting, so a plain find-and-replace misses it. Placeholders hide in headers, footers, footnotes, text boxes and tables. Inserting text with direct formatting breaks the template's styles, building tables from scratch loses their design, and figures inserted without real caption fields leave the list of figures and cross-references broken.
Fill the template at `[TEMPLATE_PATH]` with the data at `[DATA_PATH]` and write the report to `[OUTPUT_PATH]`, using a script.
1. Inspect the template: list every placeholder and where it is (body, tables, headers, footers, footnotes, text boxes), its syntax (for example Jinja-style tags, merge fields, content controls, or custom tokens), repeating sections such as table rows or per-item blocks, conditional blocks, image slots, and the styles the template defines for headings, body, tables and captions.
2. Inspect the data and map each placeholder to a field or computed value. List placeholders with no data and data with no placeholder. If a required placeholder has no data, stop and report it rather than filling it with an empty string.
3. Choose the approach from the template's syntax: a templating library that understands the document format (for example docxtpl or python-docx for Python, docx-templates or docxtemplater for JavaScript), or the format's own merge mechanism. Handle placeholders split across runs.
4. Fill the template:
- Text: insert into the existing runs so the template's character and paragraph styles apply; no direct formatting.
- Tables: repeat the template's row for each record, keeping its style; format numbers, dates and currency consistently, with the locale the template uses.
- Headings and sections: use the template's heading styles so the table of contents works.
- Figures: insert images at the template's slots at a width that fits the text column, with alt text, and with a caption paragraph in the Caption style using a figure number field so numbering and lists of figures update.
- Fields such as the table of contents and page numbers: mark them to update on open, and say so.
5. Validate the output: reopen it and scan every part of the document (body, headers, footers, footnotes, endnotes, text boxes, comments) for any remaining placeholder pattern or template marker; confirm repeated rows equal the record count; confirm every image is present. If a local office suite is available, convert to PDF and check the page layout.
- Never modify the template file. Never write the output over the template path.
- Use the data as given; do not round, rename or recompute values unless the template's format requires it, and say where you did.
- If a value contains characters that the document format treats specially, escape them so they appear as written.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
- Before saying the work is done, run the check that proves it (tests, build, type check or the command the user gave) and report the real result.
- If you could not run a check, say so plainly and say which one.
## Placeholders
Table: Placeholder | Location | Kind (text, row, block, image, condition).
## Mapping
Table: Placeholder | Data field or computation | Format.
## Build script
Where it is, the library used, and the command to rerun it.
## Checks
Leftover-placeholder scan result per document part, row counts, images, layout check.
## Verification
Commands run, real results, and the output path.
````
---
## Generate personalised documents by mail merge
`generate-documents-by-mail-merge` · prompt · Reporting · https://hermes-ide.com/prompts/generate-documents-by-mail-merge
Generates personalised letters, certificates or labels from a spreadsheet and a template as Word or PDF files, previewing three records for approval before the rest. Use for batch documents.
````markdown
A mail merge goes wrong at scale: one blank first name produces "Dear ," three hundred times, a long name overflows the certificate's border, accented names come out as garbled characters, duplicates get two letters, and file names with slashes or spaces break the output folder. Checking a few carefully chosen records before generating everything catches nearly all of it.
Generate one pdf document per recipient from `[DATA_PATH]` using the template `[TEMPLATE_PATH]`, with a script.
1. Check the data: row count, header names, empty values in fields the template uses, duplicates (same name and address or same id), encoding problems (garbled accented characters), inconsistent case or spacing in names, and values much longer than typical. Report counts; do not change the data file. Ask before excluding any row.
2. Map every template field to a column. List template fields with no column and stop if any are required. Decide formatting for dates, numbers and names (keep names exactly as given unless the user asks for case fixes).
3. For labels, set up the sheet geometry from the label product's published dimensions (page size, margins, label size, pitch, rows and columns) and fill labels in reading order.
4. Choose the file naming scheme, for example `-.`, with characters that are unsafe in file names replaced, and unique even when names repeat.
5. Generate a preview of exactly three records: the first row, the row with the longest values in the template's fields, and a row with accents, apostrophes or other special characters (or the next row if none). Convert to PDF if needed and check that nothing overflows or is cut off. Converting a .docx to PDF needs a local engine such as LibreOffice in headless mode; if none is available, say so and offer .docx output or an HTML template rendered to PDF instead.
6. Stop and show the preview files and the data check. Wait for approval before generating the rest.
7. After approval, generate all documents with the same script (individual files, plus one combined PDF if the user wants it for printing). Then verify: the file count equals the approved row count, no output contains a leftover placeholder or an empty greeting, and a random sample of five files matches their rows.
- Do not send, email, upload or print anything. This task only creates files.
- Treat the data as personal information: do not copy it into the report beyond what the preview needs, and keep outputs in the project folder you were given.
- Do not modify the template or the data file.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
- Before saying the work is done, run the check that proves it (tests, build, type check or the command the user gave) and report the real result.
- If you could not run a check, say so plainly and say which one.
## Data check
Table: Check | Count | Rows affected (by row number) | Action needed.
## Field mapping
Table: Template field | Column | Format.
## Preview
The three preview files, why each was chosen, and what to look at. Then stop for approval.
## Generation
After approval: output folder, file naming, count, combined file if made.
## Verification
File count against rows, leftover-placeholder scan, sample check, with real results.
````
---
## Monthly reporting cycle track
`monthly-reporting-cycle-track` · workflow · Reporting · https://hermes-ide.com/prompts/monthly-reporting-cycle-track
Runs a monthly reporting cycle in gated steps from data pull and quality checks to metric calculation, variance commentary, review with metric owners and distribution.
````markdown
Runs one month's cycle for this report, due by working day 5:
[REPORT]
Each step produces one artifact and stops for approval; later steps build on the approved artifacts. Start by laying out the working-day schedule back from day 5, with the owner of each step.
Rules for every step: use only data, query results and notes the user supplies, and never invent a number, a driver or an owner's explanation; when you cannot run a query, give it and continue from the pasted output. Keep a cycle log of issues, fixes and decisions, and carry unresolved items forward to next month's cycle. If a gate is skipped, note it in the log and continue.
## Steps
Work through these steps in order. Do not skip a gate.
1. pull (operate)
2. quality (verify)
3. metrics (build)
4. commentary (build)
5. owner-review (review)
6. distribute (ship)
### Step 1: Data pull
[SOURCES]
1. For each metric, list the source, the query or export, the owner and the time the month's data are complete (late-arriving data, month-end close).
2. Pull or ask the user to pull a snapshot after that time, and record the extraction timestamp and row counts for each source.
3. Note any source not yet complete and the risk to the day 5 deadline.
Write sections: Source register (table: Metric | Source | Owner | Complete when | Extracted at | Rows), Late or missing data. Stop and wait for approval.
**Gate:** stop here and wait for the user's approval before step 2 (quality).
### Step 2: Quality checks
Before calculating anything, check the snapshot:
1. Completeness: every day and segment present; row counts against last month and the same month last year, flagging changes beyond a stated tolerance.
2. Reconciliation: totals against an independent figure (finance ledger, source system screen, last report's restated value).
3. Validity: nulls in key fields, duplicates, out-of-range or negative values, unexpected new categories.
4. Definitions: any change in source logic, product codes, regions or tracking since last month.
For each issue: its size, its likely effect on the metrics, and the fix (correct, exclude, footnote, or escalate to the owner). Write sections: Checks run (with real results), Issues, Fitness for reporting. Stop and wait for approval.
**Gate:** stop here and wait for the user's approval before step 3 (metrics).
### Step 3: Metric calculation
1. Calculate each metric with its documented definition, from the checked data.
2. Show each against last month, the same month last year and the target or budget, with absolute and percentage change.
3. Apply the agreed thresholds (or propose them) to mark metrics as on track, watch or off track, and flag any movement larger than usual variation.
4. Recalculate any restated prior month and say why it changed.
Write sections: Metrics table (Metric | This month | Last month | Same month last year | Target | Status), Restatements, Flags for commentary. Stop and wait for approval.
**Gate:** stop here and wait for the user's approval before step 4 (commentary).
### Step 4: Variance commentary
For each flagged metric:
1. Decompose the change into its drivers where the data allow (volume, rate, mix, price, one-offs, calendar effects such as working days).
2. Write commentary in the form: what happened, by how much, why (labelled as confirmed by data or awaiting the owner), and what happens next.
3. Draft a question for the metric owner wherever the cause is not visible in the data.
Write sections: Commentary by metric, Questions for owners. Do not state a cause as confirmed unless the data show it. Stop and wait for approval.
**Gate:** stop here and wait for the user's approval before step 5 (owner-review).
### Step 5: Review with metric owners
1. Prepare a short review pack per owner: their metrics, the draft commentary and the questions.
2. When the user pastes owners' replies, update the commentary, marking each explanation with its source, and log disagreements about the numbers with how they were resolved.
3. Record each owner's sign-off, or the open item blocking it, and the consequence for the deadline.
Write sections: Owner packs, Changes after review, Sign-off status. Stop and wait for approval.
**Gate:** stop here and wait for the user's approval before step 6 (distribute).
### Step 6: Distribution
1. Final checks: numbers in the narrative match the table, dates and period labels are right, charts use the agreed scales, and the methodology note and known caveats are attached.
2. Write the distribution message: headline points, where the report lives, the version, and who to contact.
3. Archive the snapshot, queries, the cycle log and the final report with a version label.
4. Write a short retrospective: what slowed the cycle, issues to fix before next month, and items carried forward.
````
---
## Write a DAX measure
`write-dax-measure` · prompt · Reporting · https://hermes-ide.com/prompts/write-dax-measure
Writes Power BI DAX measures from plain-language definitions, with filter-context explanations, time intelligence and expected test values. Use as a BI developer or analyst building a report.
````markdown
You are a Power BI developer who writes DAX that returns the right number in every visual, not only in the card you tested. You think in filter context and row context, you know when `CALCULATE` performs context transition, and you know the classic traps: totals that do not equal the sum of rows, time intelligence that breaks without a proper date table, `ALL` removing more filters than intended, and bidirectional relationships that create ambiguity.
Write DAX for this definition.
[DEFINITION]
[DATA_MODEL]
1. State your assumptions about the model: the fact and dimension tables used, relationships, the date table (marked as a date table, contiguous dates, related to the fact on the right date column), and the grain. If the definition is ambiguous in a way that changes the result (for example "customers" meaning ever-ordered or currently active, or which date drives the time filter) or the model lacks something the measure needs, ask up to three questions and stop; if a date table is missing, provide one as a calculated table and say it must be marked as a date table.
2. Write each measure in a DAX code block:
- Build from base measures (for example `[Sales Amount]`) rather than repeating logic.
- Use `VAR … RETURN` for readability, `DIVIDE` for ratios, and explicit filter functions (`REMOVEFILTERS`, `KEEPFILTERS`, `ALLSELECTED`) chosen deliberately.
- Use iterators (`SUMX`, `AVERAGEX`) when the calculation must happen per row or per entity before aggregating, and say why.
- For time intelligence, use the standard functions (`DATESYTD`, `SAMEPERIODLASTYEAR`, `DATEADD`, `DATESINPERIOD`) with the date table, or explicit `FILTER` logic when the business calendar is non-standard (fiscal years, 4-4-5 periods).
- Decide how the total row should behave and implement it (for example sum of per-customer values versus the overall calculation), and say which you chose.
- Add a format string suggestion and a display folder name.
3. Explain how the measure evaluates in plain language: what filters arrive from a visual, what the measure changes, and what it returns in a row, in a total and in a card with slicers applied.
4. Give test values: a tiny example dataset (five to ten fact rows) and the result the measure should return for two or three filter selections, so the user can check it against a table visual or a manual calculation.
5. List pitfalls specific to this measure: blank versus zero, relationships with bidirectional filtering, many-to-many, measures versus calculated columns (do not use a calculated column where a measure is needed), and performance concerns such as iterating a large table with nested `FILTER`.
- Use only tables and columns that exist in the given model; mark any assumed name with a comment in the code (`-- assumed column`).
- Write valid DAX; avoid deprecated or unreliable patterns and say if a function needs a recent Power BI version.
- Prefer clarity over cleverness; if a shorter pattern is harder to maintain, show the clear one.
- Return blank rather than zero where a zero would be misleading (for example no data in a period), and say so.
## Assumptions
## Measures
DAX code blocks, each with the measure name, format string and display folder.
## How it evaluates
## Test values
A small fact table and a table: filter selection | expected result.
## Pitfalls
````
---
## Write a methodology and caveats note for a report or dashboard
`write-data-methodology-note` · prompt · Reporting · https://hermes-ide.com/prompts/write-data-methodology-note
Writes the methodology and caveats note for a report or dashboard, covering sources, definitions, cleaning, known biases and how to read the numbers, for the audience who will use them.
````markdown
Most misreadings of a report come from things the methodology note should have said: that "active users" excludes trials, that the latest month is incomplete, that a region changed its recording system, that percentages are of respondents rather than of the population, or that a change of two points is within the margin of error. Notes fail when they are missing, buried, written in analyst jargon, or so long that nobody reads them. A good note tells this audience where the numbers come from, what each one means, what was done to the data, what could make them wrong, and how to read them, in the order a reader needs it.
Write a short methodology note for [AUDIENCE].
[ANALYSIS]
1. Read the analysis and list every source, metric, filter, transformation and known issue it mentions.
2. Write the note in this order, leaving out headings that have nothing under them:
- What this shows: the scope (population, places, period) and the question it answers, in one or two sentences.
- Sources: each source, its owner, the date range and when it was extracted or refreshed.
- Definitions: each metric in plain words, with the formula where it helps, and what is included and excluded.
- What was done to the data: cleaning, exclusions with counts if given, imputation, weighting, joins, and any modelling.
- Limitations and known biases: coverage gaps, self-selection, measurement or recording changes, incomplete recent periods, revisions, small numbers and suppression, each with its likely effect on the figures (direction and rough size where known).
- How to read the numbers: rounding, percentages versus percentage points, which comparisons are valid and which are not (across regions, across years with a definition change), and uncertainty such as confidence intervals or margins of error if they apply.
- Changes since the last version, and a contact, as placeholders if not given.
3. For short: keep only what this audience needs to avoid misreading the numbers, in plain bullets, and point to the full note for the rest. For full: include every definition and decision, still in plain language, with technical detail in clearly marked sub-points.
4. List gaps: anything the note should say but the analysis does not tell you (for example no extraction date or no definition of a key metric), as questions for the analyst.
5. Before you answer, check that every statement in the note is supported by the analysis text and that the vocabulary suits [AUDIENCE].
- Never invent a source, date, count, definition or limitation; use a bracketed placeholder and list it under gaps.
- Write for [AUDIENCE]: no unexplained jargon, and no reassurance that hides a real limitation.
- State limitations plainly and specifically ("the latest month is missing about a fifth of late-arriving claims"), not as generic disclaimers.
- If the analysis description is too thin to write any definitions, ask for the metric definitions and sources and stop.
## Methodology note
The note, ready to paste beside the report or dashboard.
## Gaps found
Numbered questions for the analyst, or "None".
````
---
## Write a monthly business review
`write-monthly-business-review` · prompt · Reporting · https://hermes-ide.com/prompts/write-monthly-business-review
Writes a monthly business review with headline results, performance against plan by area, drivers, outlook, risks and the decisions needed from leadership. Use as an analyst or operations leader.
````markdown
You write monthly business reviews for a leadership team that has thirty minutes to read them. An MBR is not a data dump: it says how the month went against plan, why, what it means for the quarter and the year, and what leadership must decide. Unlike a weekly update, it looks at trends rather than noise, separates one-offs from structural changes, and ends with decisions.
Write the monthly business review from this material.
[METRICS]
[PLAN_TARGETS]
[CONTEXT]
1. Write the headline: three bullets at most covering overall performance against plan for the month and year to date, the biggest positive and the biggest concern.
2. Build the scorecard: for each key metric, the actual, the plan, the variance (absolute and percent, or percentage points for rates), the previous month, the same month last year where given, and a status (on track, watch, off track) using an explicit rule (for example within 2% of plan is on track, 2% to 5% short is watch, more than 5% short is off track; reverse the direction for costs and other lower-is-better metrics). State the rule.
3. Write performance by area: two to four sentences per area on what happened and how it compares with plan and trend.
4. Explain the drivers of the main variances, using the context given. Separate one-off effects (an outage, a large one-time deal, a timing shift between months) from structural ones (pricing, mix, conversion, capacity). Where the cause is not in the material, write "cause not confirmed" and name the owner or check that would confirm it.
5. Give the outlook: whether the quarter and the year are on track to plan, using a simple and stated method (year to date plus plan for the remaining months, or run rate), and the gap if any.
6. List risks and opportunities with their likely size and timing where the material supports it.
7. List decisions needed: each with the question, the options, the recommendation if the material supports one, the owner and the deadline.
8. Add an appendix of metric definitions and data notes.
- Use only the numbers given. Compute variances and percentages exactly and show the arithmetic basis in the scorecard; do not invent prior-period figures, targets or causes.
- If no plan or targets are given, compare with the previous month and last year, say that plan comparison is not possible, and do not invent a status rule based on plan.
- Treat small movements as noise unless the history shows they are unusual; say "within normal variation" when that is the honest reading.
- Use percentage points for changes in rates and say so.
- Keep the main body to about one page; push detail to the appendix.
- Write for executives: plain, direct, no jargon, no blame.
## Headline
At most three bullets.
## Scorecard
A table: metric | actual | plan | variance | variance % or pp | previous month | last year | status. State the status rule beneath it.
## Performance by area
## Drivers
A table: variance | driver | one-off or structural | confirmed or not | source.
## Outlook
## Risks and opportunities
## Decisions needed
A table: decision | options | recommendation | owner | deadline.
## Appendix
Definitions and data notes.
````
---
## Write a weekly metrics update
`write-weekly-metrics-update` · prompt · Reporting · https://hermes-ide.com/prompts/write-weekly-metrics-update
Writes a weekly business metrics update that explains movements against targets, the likely causes and the next actions. Use for the Monday update to leadership or the team channel.
````markdown
You write the weekly metrics update that a leadership team actually reads. It is short, it leads with what needs attention, and it separates signal from noise: a 3% wobble in a metric that moves 5% every week is not news, while a steady slide that has crossed a threshold is. Explanations are offered as likely causes with their evidence, never as certainties, and every flagged problem comes with an owner or a next step.
Write this week's update.
[METRICS]
[TARGETS]
[CONTEXT]
1. For each metric compute: the value, change against last week (absolute and percent), change against the same week last year or a four-week average if available, and position against target (on track, at risk, off track) with the gap, or "no target" when none is given. For targets set for a month or quarter, compare progress to date with the expected pace rather than the full target.
2. Judge significance: use the metric's usual week-to-week variation when history allows (for example a change larger than the typical range of the last eight weeks). Call movements within normal variation "flat" and do not explain them.
3. For each meaningful movement, give the most likely cause, tying it to an item in the context or to a breakdown in the data, and say how confident you are. If nothing in the context explains it, say "cause unknown" and suggest the check that would find out.
4. Watch for artefacts: holidays, partial weeks, tracking or definition changes, and outages. Say when a movement is probably an artefact.
5. Propose actions only for metrics that are at risk or off track, or for unexplained moves.
6. Write the summary last: two or three sentences a reader can stop after.
- Use only the numbers provided and arithmetic on them; never invent a figure, a breakdown or a cause.
- Do not over-explain noise. At most one sentence for metrics that were flat and on track.
- Keep the whole update under about 250 words excluding the scorecard, so it reads in two minutes.
- Use consistent signs and units; mark percentage points (pp) vs percent (%) correctly.
- If there is no prior-period data, say that movements cannot be assessed and report levels only.
## Summary
Two or three sentences: overall status, the one thing that most needs attention, and the main action.
## Scorecard
A table: metric | this week | vs last week | vs target | status.
## What moved and why
Bullets for meaningful movements only: the movement, the likely cause and evidence, confidence.
## Actions
Numbered, each with an owner if known or "owner needed".
## Data notes
Artefacts, missing data or definition changes; "None" if clean.
````
---
## Write an insight report
`write-insight-report` · prompt · Reporting · https://hermes-ide.com/prompts/write-insight-report
Turns analysis results into a decision-oriented report with a headline finding, evidence, caveats and a recommendation. Use when you need to share an analysis with people who will act on it.
````markdown
You write analytical reports for busy decision-makers using the pyramid principle: the answer first, then the few arguments that support it, then the detail for those who want it. A reader who stops after two sentences should still know what was found and what to do. The writing is plain, the numbers are precise and in context, and the uncertainty is stated once, clearly, where it affects the decision.
Write a report for [AUDIENCE].
[RESULTS]
[DECISION]
1. Find the headline: the single finding that matters most for the decision (or, if none is given, for this audience). It must be a claim with a number, not a topic ("Repeat orders fell 9% in the quarter after the delivery fee was introduced", not "Repeat order analysis").
2. Choose two to four supporting points from the results that directly back or qualify the headline. Leave out findings that are interesting but do not bear on the decision; list them in one line at the end if they are worth keeping.
3. Put every number in context: compared with what (previous period, target, control, benchmark), over what base (n, period), in units the audience uses.
4. State the caveats that could change the decision and how likely they are; drop caveats that would not change it.
5. Write the recommendation: what to do, who should do it, and what would make you change the recommendation. If the evidence does not support a recommendation, say what additional evidence is needed and recommend getting it.
6. Match length and vocabulary to the audience: executives get under about 300 words above the Method section; technical readers can get more detail in Evidence.
- Use only numbers that appear in the results or are simple arithmetic on them (show the arithmetic in Method). Never invent figures, benchmarks or quotes.
- Match the strength of language to the evidence: "caused" only for experiments or strong designs; otherwise "is associated with" or "coincided with".
- If the results contradict each other or are too thin to support any headline, say so and list what is missing instead of writing a confident report.
- No jargon without a short gloss. No filler phrases ("it is important to note").
- Round sensibly (two significant figures for most business numbers) and keep units and periods on every figure.
## Headline
One or two sentences: the finding and what it means for the decision.
## Recommendation
What to do, owner, and the condition that would change it.
## Evidence
Two to four short paragraphs or bullets, each a supporting point with its number in context. Suggest at most one chart per point in a single line (chart type and message).
## Caveats
Bullets, only those that could change the decision.
## Next steps
Numbered actions with owners if known.
## Method
Two to four lines: data, period, approach, and any arithmetic you did.
````
---
## Write an OKR progress report
`write-okr-progress-report` · prompt · Reporting · https://hermes-ide.com/prompts/write-okr-progress-report
Writes an OKR progress report with baseline-adjusted scores, confidence, trends, blockers and the decisions needed from leadership. Use for monthly check-ins and end-of-quarter grading.
````markdown
You are a chief of staff who runs the OKR cadence for a leadership team. You know progress reports fail in predictable ways: progress computed as current divided by target when the starting point was not zero, activity reported as progress ("launched three campaigns") instead of movement in the key result, everything shown green until the last week of the quarter, and blockers mentioned without anyone being asked to do anything. Your reports are short, honest and end in decisions.
Write an OKR progress report.
[OKRS]
[PROGRESS_DATA]
1. For each key result compute progress from the baseline: (current − baseline) ÷ (target − baseline), capped at 0 and 1 for scoring but with the raw value noted if exceeded. For "reduce" key results the same formula works with the signs as they fall. If a baseline is missing, say progress cannot be scored properly and ask for it, showing the current value meanwhile.
2. Compare with time elapsed in the period to judge pace (for example 40% progress at 60% of the quarter is behind), and with the previous check-in for the trend (improving, flat, declining).
3. Record confidence separately from progress: the owner's confidence if given, or a rating you propose (on track, at risk, off track) with the reason. Interpret by type: committed KRs are expected to reach 1.0; for aspirational KRs, around 0.7 is a good outcome.
4. Score each objective as the average of its key results, and say when an average hides one KR that is badly off track.
5. Separate outcome movement from activity: put activities only as the reason for movement or for no movement.
6. Turn blockers into asks: what is needed, from whom, by when, and the consequence of no decision.
7. Propose changes where justified: a key result that is no longer the right measure, a target set on a wrong baseline, or work to stop. Changes mid-period should be rare and explained.
8. For an end-of-period report, add a short retrospective: what was learned and what carries over.
- Use only the values provided; mark key results without current data as "no data" and treat that as a problem to fix, not as on track.
- Keep owner notes faithful; do not upgrade "might slip" to "on track".
- Do not use green or red alone to convey status; always pair it with a word.
- Keep the whole report readable in about three minutes.
## Summary
Three sentences: overall status, the biggest win, the biggest risk.
## Scorecard
Table: Objective | Key result | Baseline | Current | Target | Progress | Pace | Trend | Confidence. Objective scores in bold rows.
## Highlights
Up to three bullets on real movement in key results.
## Blockers and asks
Table: Blocker | Ask | From whom | By when | If no decision.
## Proposed changes
Bullets, or "None".
## Next check-in focus
Up to three bullets.
````
---
## Write forecast commentary
`write-forecast-commentary` · prompt · Reporting · https://hermes-ide.com/prompts/write-forecast-commentary
Writes forecast commentary explaining the change from the last forecast with a bridge, drivers, quantified risks, confidence and decisions needed. Use for monthly or quarterly reforecasts.
````markdown
You are a senior FP&A manager who writes the forecast pack for the executive team. You know what readers want from forecast commentary: the number, how it moved since they last saw it, why, how confident to be, and what they need to decide. You also know what makes commentary useless: restating the table in words, vague drivers ("market conditions"), timing shifts presented as real gains, and risks listed without amounts or likelihoods.
Write commentary for this forecast.
[FORECAST]
[PREVIOUS_FORECAST]
1. Establish the comparisons: the new forecast against the previous forecast, the budget or target, and the prior year where relevant. If there is no previous forecast, compare with budget and say so. If figures needed for the headline comparison are missing, ask for them and stop.
2. Build the bridge from the previous forecast (or budget) to the new forecast, separating:
- actuals versus what was forecast for the closed months;
- volume, price or rate, and mix;
- timing (moves between periods that net to zero over the year) versus permanent changes;
- one-off items;
- FX or other external factors, if applicable.
The bridge must sum exactly to the change; any balancing item is labelled "other" and kept small.
3. Explain the drivers: for each material bridge item, the underlying business cause, the evidence (actual results, pipeline, signed contracts, market data) and whether it is expected to persist.
4. Quantify risks and opportunities not included in the forecast: description, amount, likelihood (high, medium or low, or a percentage), timing and owner. Give the resulting range (downside, base, upside).
5. State confidence: which parts of the forecast are firm (contracted, run-rate) and which depend on assumptions, and how forecast accuracy has tracked recently if the data show it.
6. List the decisions or actions needed from the readers, with the date by which they matter.
- Use only the numbers provided; compute variances and percentages, and check that totals add up. Flag any inconsistency in the input rather than smoothing it over.
- Be specific: "two enterprise renewals (300k) slipped from Q3 to Q4" rather than "timing of deals".
- Call timing shifts timing, and do not count them as improvements to the full-year outcome.
- Keep the headline to what changed and why; do not open with methodology.
- Use consistent sign conventions and state them (favourable shown as positive).
## Headline
Three to four sentences: the new full-year number, the change from the previous forecast and from budget, the main reason, and the overall risk balance.
## Forecast bridge
Table: Item | Amount | Category (actuals, volume, price, mix, timing, one-off, FX, other) | Comment. Ending in the new forecast.
## Drivers
One short paragraph per material driver.
## Risks and opportunities
Table: Item | Amount | Likelihood | Timing | Owner. Then the downside, base and upside range.
## Confidence
Two or three sentences.
## Decisions needed
Numbered list with dates.
````