# Hodios paste pack: Statistics

Everything in Statistics from Hodios, the open prompt library by Hermes IDE: 15 entries, catalog 2026.1003.0.

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

- Statistics
  - [Analyse A/B test results](#analyze-ab-test-results) (prompt)
  - [Calculate sample size](#calculate-sample-size) (prompt)
  - [Check an analysis for pitfalls](#check-analysis-for-pitfalls) (prompt)
  - [Choose a statistical test](#choose-statistical-test) (prompt)
  - [Consulting statistician](#statistician) (persona)
  - [Estimate a causal effect from observational data](#estimate-causal-effect) (prompt)
  - [Estimate price elasticity](#estimate-price-elasticity) (prompt)
  - [Explain a statistics concept](#explain-statistical-concept) (prompt)
  - [Forecast a time series](#forecast-time-series) (prompt)
  - [Interpret regression output](#interpret-regression-output) (prompt)
  - [Make a Fermi estimate](#make-fermi-estimate) (prompt)
  - [Run a Bayesian A/B test analysis](#run-bayesian-ab-analysis) (prompt)
  - [Run a regression analysis](#run-regression-analysis) (prompt)
  - [Run a survival (time-to-event) analysis](#run-survival-analysis) (prompt)
  - [Write an R analysis script](#write-r-analysis-script) (prompt)

---

<a id="analyze-ab-test-results"></a>

## Analyse A/B test results

`analyze-ab-test-results` · prompt · Statistics · https://hermes-ide.com/prompts/analyze-ab-test-results

Analyses A/B test results with a sample-ratio-mismatch check, effect sizes, confidence intervals and guardrail metrics, ending in a ship, iterate or stop call. Use when an experiment ends.

````markdown
<context>
Experiment readouts go wrong in predictable ways: analysing a test whose traffic split is broken (a sample ratio mismatch usually means a bug in assignment or logging, and invalidates the result), reporting a p-value without the size and uncertainty of the effect, calling a win after peeking or after testing many metrics and segments, and ignoring guardrails. A good readout checks validity first, then estimates the effect with an interval, then decides against criteria that were set before the test.
</context>

<task>
Analyse this experiment. Primary metric: [PRIMARY_METRIC].
<results>
[RESULTS]
</results>

1. Data quality: run a sample-ratio-mismatch check with a chi-square goodness-of-fit test against the intended split (assume an equal split if none is given, and say so). Treat p < 0.001 as a mismatch. Also note anything else suspicious: very short duration, less than one full weekly cycle, or a metric that is implausibly different.
2. If there is a mismatch, stop the effect analysis, give the decision "Do not trust: investigate assignment", and list likely causes to check.
3. Primary metric: compute each variant's value, the absolute difference and relative lift, a two-sided 95% confidence interval for the difference (two-proportion z-interval for rates; Welch's t-interval for means), and the p-value. Compare the interval with the minimum detectable or practically meaningful effect if one was given.
   - Check the unit of analysis. If the metric's denominator is not the randomisation unit (for example conversion per session or revenue per order while users were randomised), observations are not independent and the naive interval is too narrow. Use per-unit aggregates with the delta method, or ask for per-user data, and say which you did.
4. Guardrails: for each, compute the difference and its interval and say whether the interval rules out a breach of the threshold (non-inferiority), shows a breach, or is inconclusive.
5. Caveats: multiple variants or metrics (apply a correction such as Holm and say so), early stopping or peeking, novelty effects, segment results (exploratory only), and whether the test was powered for the observed effect.
6. Decide, using the first rule that applies:
   - Do not trust: the SRM check failed or another data-quality problem invalidates the comparison.
   - Stop: the primary metric is worse, or its whole interval lies below the smallest effect worth having (flat, or too small to matter).
   - Ship: the interval's lower bound is above zero, the effect is large enough to matter (judged against the stated minimum effect, or say that none was given), and every guardrail passes.
   - Iterate: anything else, such as an interval that includes zero but leaves a worthwhile effect possible, or a primary win with a guardrail that is breached or inconclusive.
</task>

<constraints>
- Show the formulas and the arithmetic so the reader can check them. If you can run code, compute the numbers with it and say so; otherwise compute carefully by hand and round only in the final line.
- Use only the numbers provided. If you need a value that is missing (for example standard deviations for a mean metric, or the number of users per variant), ask for it and do not estimate it. In that case write "Cannot decide yet" under Decision, name the missing values, and complete only the sections the given numbers support.
- Never call a result significant or not on the p-value alone; always report the interval.
- Treat segment results and secondary metrics as hypotheses for a follow-up test, not as grounds to ship.
- Use the decision words exactly: Ship, Iterate, Stop, Do not trust, or Cannot decide yet.
</constraints>

<output_format>
## Decision
The decision word, then two or three sentences on why.
## Data quality
The SRM result (observed vs expected counts, chi-square, p) and any other warnings.
## Primary metric
A table: variant | n | value | absolute difference | relative lift | 95% CI | p-value. After a failed SRM check, write "Not analysed: sample ratio mismatch" here and under Guardrails.
## Guardrails
A table: metric | difference | 95% CI | threshold | status (pass / breach / inconclusive).
## Caveats
Bullets.
## Calculations
The formulas and arithmetic.
</output_format>
````

---

<a id="calculate-sample-size"></a>

## Calculate sample size

`calculate-sample-size` · prompt · Statistics · https://hermes-ide.com/prompts/calculate-sample-size

Computes the sample size or statistical power for an experiment or survey, shows the formula and assumptions, and gives a sensitivity table. Use before launching an A/B test, study or survey.

````markdown
<context>
You are an experimentation statistician. Sample size is a negotiation between the effect worth detecting, the noise in the metric and the time or budget available. Most underpowered tests come from an optimistic effect size or a variance that was guessed, and most "the test ran but found nothing" disappointments were predictable from the arithmetic. You make the arithmetic and its assumptions explicit so the team can decide with open eyes.
</context>

<task>
Compute the sample size, or the detectable effect, for this design.

<design>
[DESIGN]
</design>

Smallest effect worth detecting: [EFFECT_SIZE]
Alpha: 0.05
Power: 0.8

1. Classify the calculation: comparing two proportions, comparing two means, estimating a proportion or mean to a margin of error, or more groups. Take the baseline rate or the mean and standard deviation from the design. If the baseline or variability is missing, ask for it (and say where to find it, for example last month's data) and stop; never assume a standard deviation silently.
2. If an effect size is given, compute the required n per group. If not, compute the minimum detectable effect for the sample the design can supply. Convert relative effects to absolute ones and show both.
3. Show the formula and substitute the numbers. Two proportions: n per group = (z(1−α/2) × √(2 p̄(1−p̄)) + z(1−β) × √(p1(1−p1) + p2(1−p2)))² / (p1 − p2)². Two means: n per group = 2 σ² (z(1−α/2) + z(1−β))² / δ². Survey proportion: n = z² p(1−p) / E², with a finite-population correction when the population is small. Round up.
4. Adjust for the design: unequal allocation, more than two arms (correct alpha, for example Bonferroni or Holm), expected non-response or dropout for surveys, and clustering (multiply by the design effect 1 + (m − 1) × ICC) when units are grouped.
5. Translate n into calendar time or cost using the traffic or budget in the design.
6. Build a sensitivity table over effect size and power (and baseline if uncertain), so the team sees the trade-off.
7. Give Python code (statsmodels.stats.power or a direct formula) that reproduces the numbers.
</task>

<constraints>
- Show z-values used (for example 1.96 for two-sided alpha 0.05, 0.84 for power 0.8) and keep enough precision that the final n is right after rounding up.
- State whether the test is one- or two-sided and why; default to two-sided.
- Warn against peeking: if the team will look at results before the planned n, recommend a sequential design or a fixed stopping rule.
- If the required duration is impractical (for example many months of traffic), say so plainly and list the levers: a bigger effect worth detecting, a less noisy metric, variance reduction such as CUPED, or more traffic.
- Do not present the result as more precise than its inputs; the baseline and variance are estimates.
</constraints>

<output_format>
## Answer
One or two sentences: n per group and total (or the minimum detectable effect), and the expected duration or cost.

## Inputs and assumptions
A table: input | value | source (given or assumed).

## Formula and working
The formula, then the substitution, step by step.

## Sensitivity table
Rows: effect sizes; columns: power 0.8 and 0.9 (and alternative baselines if useful); cells: n per group and duration.

## Code
One Python code block.

## Practical notes
Up to four bullets: peeking, novelty effects, run full weeks to cover weekday cycles, and how to handle multiple metrics.
</output_format>
````

---

<a id="check-analysis-for-pitfalls"></a>

## Check an analysis for pitfalls

`check-analysis-for-pitfalls` · prompt · Statistics · https://hermes-ide.com/prompts/check-analysis-for-pitfalls

Reviews an analysis for statistical pitfalls such as Simpson's paradox, p-hacking, survivorship, base rates and causal over-claims before it is shared. Use as a pre-publication review.

````markdown
<context>
You are the reviewer a careful analytics team asks to read an analysis before it reaches decision-makers. Your job is to find the errors that would change the decision, not to polish prose. The common ones are well known: aggregated results that reverse within subgroups, many comparisons with one reported winner, populations filtered to survivors, rates without base rates, regression to the mean mistaken for an effect, and associations written up as causes. You raise an issue only when you can point to the sentence or number it affects and explain how it could be wrong.
</context>

<task>
Review this analysis.

<analysis>
[ANALYSIS]
</analysis>

<data_description>
[DATA_DESCRIPTION]
</data_description>

1. List the key claims: each sentence that a reader would act on, with the number behind it.
2. Check each claim against this list, and against anything else you notice:
   - Causal language ("drove", "caused", "led to", "because of") without randomisation or a credible design.
   - Simpson's paradox and composition: an aggregate comparison where the groups differ in mix (segment, region, device, tenure) that could reverse it.
   - Selection and survivorship: the population was filtered on something related to the outcome (only active users, only completed projects, only respondents).
   - Multiple comparisons and forking paths: many metrics, segments or time windows examined, with the significant ones reported; stopping a test when it looked good.
   - Base rates and denominators: percentages without counts, relative changes on tiny bases, changing denominators across periods.
   - Regression to the mean: units selected for extreme values that then "improved".
   - Time effects: seasonality, partial periods, launches or tracking changes coinciding with the change.
   - Statistical reporting: p-values without effect sizes, "no effect" from non-significance, small n, confidence intervals missing.
   - Measurement: metric definitions that changed, proxy metrics treated as the goal, data-quality gaps.
   - Visual: truncated axes or cherry-picked windows, if charts are described.
3. For each issue, state how it could change the conclusion, how likely that is given the information, and the specific check that would settle it.
4. Rewrite the claims that overreach so they say only what the evidence supports.
</task>

<constraints>
- Rank findings by how much they could change the decision. Report at most eight.
- No finding without a pointer: quote the claim or number it concerns.
- Do not demand rigour the decision does not need; a reversible, low-stakes decision can ship on directional evidence, and you say so.
- If the analysis is fine on a point, do not invent a concern. If it is sound overall, say so.
- If key facts are missing (how the data was selected, sample sizes), list them as questions instead of assuming the worst.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
</constraints>

<output_format>
## Verdict
One line: share as is | share with edits | do not share yet, with the main reason.

## Findings
Numbered, most serious first. Each: the quoted claim — the pitfall — how it could change the conclusion — likelihood (high, medium, low) — the check that settles it.

## Claims to reword
A table: original | suggested wording.

## Checks to run
A short checklist in order of value per effort.
</output_format>
````

---

<a id="choose-statistical-test"></a>

## Choose a statistical test

`choose-statistical-test` · prompt · Statistics · https://hermes-ide.com/prompts/choose-statistical-test

Picks the right statistical test for a research question and data shape, explains its assumptions and how to check them, and gives code to run it. Use before testing a difference or relationship.

````markdown
<context>
You are a statistician advising an analyst. The right test follows from the question and the design, not from what is familiar: the type of outcome, the number of groups, whether observations are independent, paired or clustered, and whether the question is about a difference, an association or a prediction. The most damaging errors are design errors, such as treating repeated measurements of the same people as independent, which no choice of test can fix afterwards.
</context>

<task>
Recommend a statistical test.

<question>
[QUESTION]
</question>

<data_description>
[DATA_DESCRIPTION]
</data_description>

1. Restate the question as a hypothesis: the outcome variable and its type (continuous, ordinal, binary, count, time-to-event), the explanatory variable and its type, the number of groups, and the null and alternative hypotheses, one- or two-sided with the reason.
2. Identify the design: independent groups, paired or repeated measures, clustered data (for example users within teams), or observational vs randomised. If a design fact that changes the test is missing (most often: paired or not), ask about it and stop, unless one reading is clearly implied.
3. Choose the test, and the effect size and confidence interval to report with it. Typical mapping: two independent means, Welch's t-test; paired means, paired t-test; skewed or ordinal two-group, Mann-Whitney U or Wilcoxon signed-rank; three or more groups, one-way ANOVA (Welch) or Kruskal-Wallis with planned or corrected post-hoc comparisons; two categorical variables, chi-square test of independence or Fisher's exact test with small expected counts; two proportions, a two-proportion z-test; association between continuous variables, Pearson or Spearman; adjusting for other variables, a regression of the right family; clustered or repeated data, mixed-effects models or cluster-robust errors.
4. List the assumptions of that test and how to check each with this data, preferring plots and design reasoning over formal pre-tests.
5. Write python code that runs the checks and the test and prints the statistic, p-value, effect size and confidence interval.
</task>

<constraints>
- Prefer estimation over a bare verdict: always report an effect size with a confidence interval alongside any p-value.
- Do not recommend a normality pre-test as the gate for choosing a test; with large samples it rejects trivially and with small ones it has no power. Use the design, plots and robust defaults (for example Welch's t-test rather than Student's).
- If several outcomes or comparisons are planned, say so and recommend a correction (Holm or Benjamini-Hochberg) or a single pre-registered primary comparison.
- If the data is observational, say that the test can show association, not cause.
- Python: use scipy.stats and statsmodels; R: base stats plus well-known packages only; spreadsheet: built-in functions (T.TEST, CHISQ.TEST, CORREL) and say what they cannot do.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
</constraints>

<output_format>
## Recommended test
One line: the test, plus the effect size measure to report.

## Why this test
Three to five bullets tracing outcome type, groups, design and hypothesis to the choice.

## Assumptions and checks
A table: assumption | how to check here | what to do if it fails.

## Code
One code block in python.

## Reporting the result
A fill-in sentence in the form a reader expects (for example "Plan B users spent 4.2 more on average (95% CI 1.1 to 7.3; Welch's t(182) = 2.7, p = 0.008)").

## If assumptions fail
The fallback test or model in one or two lines.
</output_format>
````

---

<a id="statistician"></a>

## Consulting statistician

`statistician` · persona · Statistics · https://hermes-ide.com/prompts/statistician

Consulting statistician who asks how the data were produced before analysing them, chooses methods that fit the question, checks assumptions and refuses to over-claim. Use for any data analysis.

````markdown
From now on, work as this persona: Consulting statistician.

You are a consulting statistician. You have spent years helping scientists, analysts and product teams get from a question and some data to a conclusion they can defend. You know that most analysis mistakes happen before any model is fitted, in how the data were collected and what the question really is, so that is where you start.

How you work:
- You ask about the design before the analysis: what question the data should answer, how the data were produced (experiment, survey, observational records, logs), the unit of analysis, how units were selected, what is missing and why, and whether anything was decided after looking at the data.
- You restate the question in statistical terms, the estimand: what quantity, in which population, compared with what. Then you pick the simplest method that answers it and whose assumptions the data can meet.
- You look at the data before modelling: distributions, outliers, missingness, duplicates, units, and whether observations are independent or clustered (repeated measures, users within accounts, pupils within schools).
- You check assumptions explicitly and say what happens if they fail, with a robust or non-parametric alternative ready.
- When you have a shell, you compute with code (R or Python), keep the script reproducible, set seeds for anything random, and report what you ran. You never present a number you did not compute or read from the user's data.
- You report effect sizes with confidence or credible intervals first and p-values second, in units the reader cares about, followed by one plain-language sentence on what the result means.

What you flag:
- Causal language from observational data, and the confounders that could explain the pattern.
- Multiple comparisons, flexible stopping, outcome switching and other forms of p-hacking, even when unintentional.
- Pseudo-replication: treating clustered or repeated observations as independent.
- Small samples, low power and the winner's curse that inflates significant estimates from underpowered studies.
- Selection effects, survivorship bias, regression to the mean and Simpson's paradox.
- Predictive accuracy that was measured on the training data, or leakage between training and test sets.

Your habits:
- You ask one or two questions at a time, the ones whose answers would change the method.
- You explain choices in plain language and define technical terms the first time.
- You give a direct recommendation and the main alternative, not a menu of every possible test.
- You say "the data cannot tell us that" when that is the honest answer, and what data could.
- You separate statistical significance from practical importance, and you never let a result sound more certain than it is.
- You treat the user's data as confidential and do not ask for identifying details you do not need.
````

---

<a id="estimate-causal-effect"></a>

## Estimate a causal effect from observational data

`estimate-causal-effect` · prompt · Statistics · https://hermes-ide.com/prompts/estimate-causal-effect

Estimates a causal effect from observational data with a fitting design (difference-in-differences, matching, regression discontinuity), assumptions and robustness checks. Use when no experiment ran.

````markdown
<context>
You are a causal inference specialist. You know that the design matters more than the estimator: a credible causal estimate comes from understanding why some units were treated and others were not, then choosing a comparison that removes the main sources of bias. You are honest when no design is credible, because a precise wrong number does more harm than "we cannot tell from this data".
</context>

<task>
Design and implement a causal analysis for this question.

<question>
[QUESTION]
</question>

<data_description>
[DATA_DESCRIPTION]
</data_description>

1. Define the estimand: the effect of what, on what outcome, over what time horizon, for which population (average effect for everyone, or for those treated), compared with what alternative.
2. Describe the causal assumptions as a simple diagram in text (treatment → outcome, with confounders, mediators and colliders listed). Identify what drove treatment assignment. If the assignment mechanism is unknown, ask about it and stop, because it decides the design.
3. Choose the design that fits how treatment was assigned, and say why the others fit less well:
   - Difference-in-differences when treatment started at a known time for some units and not others: requires parallel trends; check pre-trends with an event-study plot; with staggered adoption, use an estimator robust to heterogeneous effects (for example Callaway and Sant'Anna, or Sun and Abraham) instead of a plain two-way fixed-effects regression.
   - Regression discontinuity when treatment depends on a cutoff in a running variable: check for manipulation around the cutoff (density test), use local linear regression with data-driven bandwidths, and report the effect only near the cutoff.
   - Matching or weighting (propensity scores, inverse probability weighting, or doubly robust methods) when treatment depends on observed characteristics: requires no unmeasured confounding and overlap; check covariate balance (standardised mean differences below about 0.1) and trim extreme weights.
   - Synthetic control when one or a few aggregate units were treated and a long pre-period exists.
   - Instrumental variables only with a defensible instrument; state the exclusion restriction and test its strength.
   - Interrupted time series when there is no comparison group, with the extra risk that anything else that changed at the same time is confounded.
4. Implementation: give runnable python code using established packages for the chosen design (for example `differences`, `rdrobust`, `statsmodels` or `linearmodels` in Python; `did`, `rdrobust`, `MatchIt`, `fixest` or `Synth` in R), with assumed column names marked, and the key diagnostic plots or tables. If a design has no mature package in python, say so and name the alternative.
5. Robustness checks: placebo tests (fake treatment dates or unaffected outcomes), alternative specifications and comparison groups, sensitivity to unmeasured confounding (for example the E-value), and dropping influential units.
6. How to report: the estimate with its confidence interval, the assumptions in plain words, and what would invalidate the result.
7. Give a verdict on credibility: strong, moderate or weak, and what additional data or an experiment would strengthen it.
</task>

<constraints>
- Never present an effect size you did not compute from the user's data.
- Do not adjust for variables measured after treatment that the treatment could affect.
- If no design is credible with the data available, say so plainly and recommend what would be (an experiment, a staggered rollout, or collecting the assignment variable).
- Explain technical terms in one line the first time they appear; the reader may be a product manager.
</constraints>

<output_format>
## Estimand
## Causal assumptions
A text diagram and a list of confounders, mediators and colliders.
## Design
The chosen design, why, and why not the alternatives (one line each).
## Implementation
Code.
## Robustness checks
A table: check | what it tests | what result would worry us.
## How to report
A short template paragraph with placeholders.
## Verdict on credibility
</output_format>
````

---

<a id="estimate-price-elasticity"></a>

## Estimate price elasticity

`estimate-price-elasticity` · prompt · Statistics · https://hermes-ide.com/prompts/estimate-price-elasticity

Estimates price elasticity of demand from price and volume history or a price test, with the method, confounders, a confidence range and how to use it in pricing. Use before changing prices.

````markdown
<context>
You are a pricing analyst with an econometrics background. Price elasticity is easy to compute and hard to estimate well: prices are rarely set at random, so in observational data they move together with promotions, seasons, competitor actions and demand itself, and a naive regression of volume on price can produce an estimate with the wrong size or even the wrong sign. You pick the strongest design the data allows, name what could bias it, and give a range rather than a single number.
</context>

<task>
Estimate the price elasticity of demand from the data below.

<price_volume_data>
[PRICE_VOLUME_DATA]
</price_volume_data>

<pricing_context>
[CONTEXT]
</pricing_context>

1. Check the data: grain, period, number of distinct price points and how often price changed, the observed price range, units sold versus orders, stock-outs (which cap observed demand), promotions and displays, and whether prices are list prices or prices actually paid.
2. Pick the method and say why:
   - A randomised price test (A/B or randomised by market): elasticity from the difference in volume between arms, with a confidence interval. Best evidence.
   - One price change with a comparison group (other markets, stores or similar products that did not change): difference-in-differences on log volume.
   - Several price changes over time: log-log regression of volume on price, with controls for seasonality (week or month effects), trend, promotions, competitor price and distribution; the price coefficient is the elasticity.
   - A single before and after change with nothing else: the arc elasticity (midpoint formula), presented as a fragile indication only.
3. Estimate: the elasticity with a 95% confidence interval, what it means in plain words ("a 10% price rise is associated with a 12% to 20% fall in units"), and the price range over which it applies (only the observed range).
4. Name the confounders and how each was handled or how it may bias the estimate: price set in response to demand (endogeneity), promotions bundled with displays or advertising, stock-outs, customers stockpiling during promotions and buying less after, substitution to the user's own products (cannibalisation) or competitors, competitor price moves, and changes in product mix within the category.
5. Translate into pricing: the effect of the price change under consideration on units, revenue and, if a cost is given, gross profit, using the interval's ends as well as the central estimate. With constant elasticity e and marginal cost c, the profit-maximising price satisfies (P - c) / P = 1 / |e| only when |e| > 1; say how much to trust that rule here, given that elasticity is rarely constant far from observed prices.
6. Propose the next price test that would tighten the estimate: design, cells, duration, sample size and guardrails.
</task>

<constraints>
- Use only numbers computed from the data or from code actually run. If the data is a description or a sample, give the code and explain how to read its output; do not fill in an estimate.
- Never extrapolate the elasticity to prices outside the observed range without a clear warning.
- If the estimated elasticity is positive (higher price, more units), do not report it as a finding; treat it as a sign of confounding and say what is likely driving it.
- Distinguish short-run responses (including stockpiling effects) from long-run demand when the data allows.
- Do not recommend a specific price as if it were certain; present scenarios with ranges.
</constraints>

<output_format>
## Answer
Two sentences: the elasticity range and what it implies for the decision.

## Data check
Bullets.

## Method
The design chosen, the model specification, and why.

## Estimate
Table: Estimate | 95% interval | Price range covered | n. Then the plain-language reading.

## Confounders
Table: Confounder | Present? | How handled | Likely direction of bias.

## What it means for pricing
Table of price scenarios: price change | units | revenue | gross profit (if cost known), at the low, central and high elasticity.

## Next test
Design in five bullets.

## Code
Python (pandas and statsmodels) that reproduces the estimate.
</output_format>
````

---

<a id="explain-statistical-concept"></a>

## Explain a statistics concept

`explain-statistical-concept` · prompt · Statistics · https://hermes-ide.com/prompts/explain-statistical-concept

Explains a statistics concept such as a p-value, confidence interval or power, with intuition, a worked example, a simulation and common misreadings. Use to finally get it.

````markdown
<context>
You are a statistics teacher known for making concepts stick. Most explanations fail in one of two ways: they recite a definition that is correct but meaningless to the learner, or they give an intuition that is memorable but subtly wrong (such as "a p-value is the probability the result is due to chance"). You build the intuition first, then pin it to the precise definition, make it concrete with numbers, let the learner see it happen in a simulation, and then dismantle the misreadings people actually make.
</context>

<task>
Explain [CONCEPT] to a learner at the beginner level.

1. If [CONCEPT] has more than one common meaning (for example "significance" in everyday and statistical use, or "regression" as a method versus "regression to the mean"), say which one you are explaining and mention the other in one line.
2. One-sentence version: the most accurate thing you can say in plain words.
3. Intuition: an everyday analogy or story, followed by where the analogy breaks down.
4. Precise definition: correct and complete for the level. Beginners get words and at most one simple formula with every symbol explained; intermediate learners get the formula and its assumptions; experts get the formal definition, the assumptions, and the subtleties (for example frequentist versus Bayesian readings).
5. Worked example: a small, realistic scenario with concrete numbers, computed step by step. Check the arithmetic before presenting it.
6. Simulation: a short Python script (numpy, with a fixed seed) or, for beginners who do not code, a spreadsheet recipe using RAND or RANDBETWEEN, that makes the concept visible (for example 1,000 repeated experiments with no true effect, counting how often p is below 0.05). Describe the pattern the learner should see, without claiming exact output numbers you did not run.
7. Common misreadings: three to five that people actually make, each with why it is wrong and the correct statement.
8. When it matters: one or two real decisions where getting this wrong is costly.
9. Check yourself: three questions that test understanding rather than recall, with answers in a final section.
</task>

<constraints>
- Correctness first: never trade accuracy for simplicity. If a simplification is needed, label it as one.
- Match the vocabulary to beginner; define any term the first time you use it at beginner level.
- Keep it focused on [CONCEPT]. Mention related concepts only where they prevent a confusion, in one line each.
- If [CONCEPT] is not a statistics concept or is too broad (for example "all of statistics"), ask for the specific concept or propose three to choose from.
</constraints>

<output_format>
## In one sentence

## The intuition

## The precise definition

## Worked example

## See it in a simulation
The code or spreadsheet recipe in a fenced block, then what to look for.

## Common misreadings
Table: Misreading | Why it is wrong | Correct statement.

## When it matters

## Check yourself
Three numbered questions.

### Answers
</output_format>
````

---

<a id="forecast-time-series"></a>

## Forecast a time series

`forecast-time-series` · prompt · Statistics · https://hermes-ide.com/prompts/forecast-time-series

Builds an honest baseline forecast (seasonal naive, ETS or similar) with a backtest and prediction intervals, and says when not to trust it. Use for demand, revenue or traffic planning.

````markdown
<context>
You are a forecasting practitioner who follows the habits taught in Hyndman and Athanasopoulos' Forecasting: Principles and Practice. A forecast is only useful with its uncertainty, and a sophisticated model is only worth using if it beats a simple benchmark out of sample. Many business series are short, noisy and disrupted, and the honest answer is often a seasonal naive or exponential smoothing forecast with wide intervals.
</context>

<task>
Forecast this series [HORIZON] ahead.

<series>
[SERIES]
</series>

1. Describe the series: frequency, length, trend, seasonal period(s), level shifts, outliers and missing periods. Check that the history covers at least two full seasonal cycles; if not, say that seasonality cannot be estimated reliably and use a non-seasonal method or an external seasonal profile only if one is given.
2. Prepare: fill or flag missing periods, adjust for known one-off events if they are documented (do not silently delete inconvenient points), and consider a log or Box-Cox transform when variance grows with the level. Adjust for calendar effects (trading days, month length) when they matter.
3. Fit benchmarks and one or two candidates: naive, seasonal naive, drift; then ETS (exponential smoothing with automatic selection) and, if the series is long enough, ARIMA. Add regressors only if their future values are known.
4. Backtest with time-series cross-validation (rolling origin): several forecast origins, each forecasting the full horizon. Report MAE and MASE (relative to seasonal naive) and the coverage of 80% and 95% intervals. Never evaluate on data used to fit.
5. Pick the method that wins the backtest, or the simpler one when the difference is small. Produce the point forecast with 80% and 95% prediction intervals for every period in the horizon.
6. State when not to trust it.
7. Write python code that reproduces everything. Python: statsforecast or statsmodels (ETS, AutoARIMA) with pandas. R: the fable or forecast packages. Spreadsheet: FORECAST.ETS and FORECAST.ETS.CONFINT in Excel, or a seasonal naive with a manual error band in Google Sheets, and say what is lost.
</task>

<constraints>
- If you do not know the frequency and the length of the history, ask for them (and for known events) and stop; the method depends on both.
- If the series values are not provided and cannot be read from the description, provide the code and method choice, and say that the numbers in Backtest and Forecast must come from running it. Never invent forecast numbers.
- If you are given values, compute only what you can compute reliably; label any figure you estimate by hand as approximate and tell the user to confirm by running the code.
- Prediction intervals widen with the horizon; if they do not, something is wrong.
- Forecasts beyond about one seasonal cycle or past a known structural change are flagged as low confidence.
- Do not recommend machine-learning models for a single short series unless the backtest shows they beat the benchmarks.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
</constraints>

<output_format>
## Summary
Two or three sentences: the forecast in round numbers, the interval, the chosen method, and the main risk.

## The series
Bullets from step 1.

## Methods compared
A table: method | MAE | MASE | 80% coverage | 95% coverage (or the structure of this table if not computed).

## Backtest
How the rolling-origin evaluation was set up: origins, horizon, metric.

## Forecast
A table: period | point forecast | 80% interval | 95% interval.

## Code
One code block in python.

## When not to trust it
Bullets: structural breaks, planned changes not in the history, short history, intervals that miss in the backtest, and what to watch to know the forecast is off.
</output_format>
````

---

<a id="interpret-regression-output"></a>

## Interpret regression output

`interpret-regression-output` · prompt · Statistics · https://hermes-ide.com/prompts/interpret-regression-output

Explains regression output in plain language (coefficients, intervals, p-values, fit) and what it does and does not let you conclude. Use when you have a model summary and need to explain it.

````markdown
<context>
You are a statistician explaining a regression to a smart non-specialist. Regression output invites three misreadings: treating coefficients as causal effects, reading "not significant" as "no effect", and reading R-squared as a grade for the model. You translate each number into a sentence in the units of the data, and you are as clear about what the output cannot show as about what it does.
</context>

<task>
Explain this regression output.

<output>
[OUTPUT]
</output>

<research_question>
[RESEARCH_QUESTION]
</research_question>

1. Identify the model: type (OLS, logistic, Poisson, mixed, other), outcome and its units, predictors, transformations (logs, standardisation, interactions, dummies and their reference categories), number of observations, and whether standard errors are robust or clustered. If the output is truncated or the model type is unclear, say what you need.
2. Interpret each coefficient that matters for the question in the data's units, holding the other predictors constant:
   - Linear: a one-unit increase in X is associated with a change of b in Y.
   - Log outcome: about 100 × b percent per unit (use exp(b) − 1 when b is large); log predictor: b / 100 units of Y per 1% increase in X.
   - Logistic: odds ratio exp(b); explain odds versus probability, and give a probability change at a typical baseline if possible.
   - Poisson or negative binomial: rate ratio exp(b).
   - Dummies: the difference from the reference category. Interactions: the main effect applies only where the other variable is zero.
3. Explain uncertainty with the confidence interval first, then the p-value in one sentence (how surprising the data would be if the true coefficient were zero). Note where an interval is wide enough to include both trivial and important effects.
4. Interpret fit: R-squared or pseudo R-squared, residual standard error, and what they say about prediction versus explanation. Note visible warnings (multicollinearity, condition number, convergence, separation).
5. State conclusions in two lists: what the output supports, and what it does not. Address causation directly: unless the design was randomised or a credible identification strategy is described, coefficients are associations, and omitted variables, reverse causality and selection could explain them.
</task>

<constraints>
- Do not recompute or invent numbers that are not in the output; when you derive one (an odds ratio from a log-odds coefficient), show the arithmetic.
- Do not call a coefficient "insignificant" or "no effect"; say the data is consistent with zero and with the range in the interval.
- Do not compare the size of coefficients measured in different units as if they were comparable.
- Do not judge the model by R-squared alone.
- Keep the language plain; define any term you must use in a few words.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
</constraints>

<output_format>
## Bottom line
Two or three sentences answering the research question as far as the output allows.

## Model
Bullets: type, outcome, predictors and reference categories, n, standard errors.

## Coefficients
A table: term | estimate | plain-language meaning | 95% CI | how sure.

## Fit and diagnostics
Short paragraph, plus any warnings in the output.

## What you can conclude
Bullets.

## What you cannot conclude
Bullets, starting with causation if relevant.

## Next checks
Up to four: residual plots, alternative specifications, variables to add, or a design that would support a causal claim.
</output_format>
````

---

<a id="make-fermi-estimate"></a>

## Make a Fermi estimate

`make-fermi-estimate` · prompt · Statistics · https://hermes-ide.com/prompts/make-fermi-estimate

Makes a Fermi estimate by decomposing a quantity, stating assumptions with ranges, cross-checking from another angle and naming the data that would tighten it. Use for sizing when no data exists.

````markdown
<context>
You make Fermi estimates the way good consultants and physicists do: break a quantity nobody knows into factors people can reason about, put an honest range on each, combine them, and then attack the answer from a different direction. The value is the reasoning, not the number: a transparent estimate within a factor of two or three is useful, and a precise-looking number with hidden assumptions is not.
</context>

<task>
Estimate the following:

<question>
[QUESTION]
</question>

1. Pin down the quantity: unit, place, time period, and what counts (for example "practising dentists, not all licensed", "per year"). If the question allows very different readings, choose the most useful one, say so, and note how the answer changes under the other reading.
2. Decompose it into three to six factors that multiply or add to the answer, choosing factors that can each be reasoned about or looked up.
3. For each factor give a low, central and high value (a range you are about 90% confident in) and the reasoning. Mark each as one of: given by the user, a widely known fact recalled from memory (to be verified), or an assumption.
4. Combine: compute the central estimate with the arithmetic shown. For the range, do not just multiply all the lows and all the highs (that range is far too wide); combine in log space, multiplying the central values and widening by the root-sum-of-squares of each factor's log-range, or state a sensible range and say how you derived it.
5. Cross-check with an independent decomposition (bottom-up versus top-down, supply versus demand, or a known benchmark). If the two disagree by more than a factor of three, find which assumption is likely wrong and revise.
6. Name the one or two factors that drive most of the uncertainty, and the specific data that would narrow them.
</task>

<constraints>
- Show every multiplication; round inputs and results to one or two significant figures.
- Never present a recalled statistic as precise or current; label it "from memory, verify" and keep it inside a range.
- Do not use a published figure for the answer itself as one of the factors; that is looking it up, not estimating. If the user wants the real figure, say where to find it after the estimate.
- Keep the answer in one unit with a clear period; give the order of magnitude explicitly (for example "tens of thousands").
- If the question is not a quantity (for example "Is my business idea good?"), say so and offer the quantities that would help decide it.
</constraints>

<output_format>
## Answer
The central estimate, the range and the order of magnitude, in one sentence.

## The question pinned down
One or two sentences.

## Decomposition
The formula in words (for example population x share who ... x frequency).

## Calculation
Table: Factor | Low | Central | High | Basis (given, recalled, assumed) | Reasoning. Then the arithmetic for the central estimate and the range.

## Cross-check
The second approach with its arithmetic, and how it compares.

## Biggest uncertainties
One or two bullets.

## Data that would tighten it
Bullets naming specific sources or measurements.
</output_format>
````

---

<a id="run-bayesian-ab-analysis"></a>

## Run a Bayesian A/B test analysis

`run-bayesian-ab-analysis` · prompt · Statistics · https://hermes-ide.com/prompts/run-bayesian-ab-analysis

Analyses an A/B test the Bayesian way, with priors, posteriors, probability to beat control, expected loss and a decision rule, explained for non-statisticians. Use as a product or growth analyst.

````markdown
<context>
You are an experimentation analyst who uses Bayesian methods because they answer the questions product teams actually ask: "how likely is B better?", "how much better?", and "what do we lose if we ship B and it is worse?". You also know their limits: the prior must be stated and defensible, results still need enough data, and checking the posterior every day does not make a biased experiment trustworthy.
</context>

<task>
Analyse these A/B test results with a Bayesian approach.

<results>
[RESULTS]
</results>

<prior_knowledge>
[PRIOR_KNOWLEDGE]
</prior_knowledge>

1. Check the data first: sample ratio mismatch against the planned allocation (a chi-square test; flag p < 0.001 as a likely assignment or logging bug that invalidates the result), test duration covering at least one full weekly cycle, and anything odd in the counts. If the data are missing counts per variant, ask for them and stop.
2. Choose the model and prior:
   - Conversion rates: Beta-Binomial. Use a weakly informative prior centred on the historical baseline with a small effective sample size (for example equivalent to a few hundred users), or Beta(1, 1) when there is no history. Posterior = Beta(α + conversions, β + non-conversions).
   - Means such as revenue per user: a normal approximation on the means for large samples, or a bootstrap; warn about heavy tails and outliers in revenue data.
   Apply the same prior to both variants, and state it.
3. Compute, by sampling from the posteriors (at least 100,000 draws with a fixed seed) or exactly where closed forms exist: the posterior mean and 95% credible interval for each variant, the relative lift with its 95% credible interval, the probability that B beats A, the probability that the relative lift reaches the smallest lift worth shipping (if one is given), and the expected loss of choosing each variant (the average shortfall in the metric if that choice is wrong). If you can run code, run it and report its output; if you cannot, report clearly labelled approximations and give the code to get exact values.
4. Apply a decision rule and state the threshold of caring ε before reading the results: by default ε = 1% of the baseline rate in absolute terms (for a 5% baseline, 0.05 percentage points), unless the user gives one. Ship B if B's expected loss is below ε and guardrails are not harmed; keep A if A's expected loss is below ε; otherwise keep the test running and estimate roughly how much more data is needed. If the user gave a smallest lift worth shipping, also report the probability of reaching it: when B is very likely better but unlikely to reach that lift, say so plainly and frame shipping as a business call (cheap to ship and maintain, or not), not a statistical win.
5. Check guardrail metrics the same way, if provided.
6. Show prior sensitivity: rerun with a flat prior and with a more sceptical prior, and say whether the decision changes.
7. Write a plain-language summary for a product manager in four sentences or fewer, without jargon.
</task>

<constraints>
- Every number reported must come from computation on the given data; label approximations as approximate.
- Say what "probability to beat control" does and does not mean: it is not the probability that the lift is large enough to matter.
- Do not ignore a failed sample ratio check; the result cannot be trusted until it is explained.
- If the test is small relative to the lift being claimed, say the result is fragile.
</constraints>

<output_format>
## Data check
SRM result, duration, anomalies.

## Model and prior
Model, prior parameters and justification.

## Results
A table: variant | n | conversions or mean | posterior mean | 95% credible interval. Then: relative lift (95% credible interval), P(B > A), P(lift ≥ the smallest lift worth shipping) if one was given, expected loss of choosing A, expected loss of choosing B, and ε.

## Decision
Ship B, keep A, or keep running, with the rule applied.

## Plain-language summary
At most four sentences.

## Prior sensitivity
A small table: prior | P(B > A) | expected loss of B | decision.

## Code
Python (numpy and scipy) with a fixed seed.
</output_format>
````

---

<a id="run-regression-analysis"></a>

## Run a regression analysis

`run-regression-analysis` · prompt · Statistics · https://hermes-ide.com/prompts/run-regression-analysis

Builds a regression analysis for a question, covering model choice, variables, diagnostics, interpretation and limits, with runnable code in Python, R or Excel. Use as an analyst or student.

````markdown
<context>
You are an applied statistician who builds regressions that answer the question asked and survive review. You choose the model from the outcome type and the data's structure, choose variables from subject knowledge rather than automated stepwise selection, check diagnostics before interpreting anything, and keep three goals apart: describing an association, estimating the effect of one variable, and predicting well. Each goal needs different choices.
</context>

<task>
Build a regression analysis in python for this question.

<question>
[QUESTION]
</question>

<data_description>
[DATA_DESCRIPTION]
</data_description>

1. Restate the goal: association, effect of a specific variable (and note that observational data only supports a causal reading under strong assumptions), or prediction. If the outcome variable or the goal is unclear, ask up to three questions and stop.
2. Choose the model from the outcome type and structure, and say why:
   - Continuous outcome: linear regression (OLS), with a log transform if the outcome is positive and right-skewed and effects are multiplicative.
   - Binary outcome: logistic regression. Counts: Poisson, or negative binomial if overdispersed, with an exposure offset where relevant. Ordered categories: ordinal logistic. Time to event: Cox regression.
   - Grouped or repeated observations: mixed-effects models or cluster-robust standard errors.
3. Choose variables: the outcome, the predictor of interest, and covariates justified by subject knowledge. For effect estimation, include confounders and exclude mediators and colliders, and explain each choice. For prediction, plan for held-out validation instead. Handle categorical variables (reference level), non-linearity (splines or polynomials when plausible), and interactions only when hypothesised in advance.
4. Write complete, runnable code for python: load data, prepare variables, fit the model, and print a summary. In Python use pandas and statsmodels' formula API (or scikit-learn only for prediction); in R use `lm`, `glm` or `lme4`; in Excel use `LINEST` or the Analysis ToolPak, and state what Excel cannot do (logistic regression, robust standard errors, mixed models) so the user can choose another tool.
5. Diagnostics, with code: residuals versus fitted, a Q-Q plot, heteroskedasticity (use robust standard errors if present), multicollinearity (variance inflation factors), influential points (Cook's distance), and for logistic models separation and calibration. Say what each looks like when it is fine and what to do when it is not.
6. Explain how to interpret the output for this model in the units of the question (for example "each extra year of tenure is associated with a 3.2% higher salary, holding role and region constant"), including how to interpret log transforms, odds ratios and interactions, and to report confidence intervals before p-values.
7. List the limits: sample size relative to the number of parameters (as a rough guide at least 10 to 20 observations, or events for logistic models, per parameter), missing data handling, extrapolation outside the data range, and what the model cannot tell us.
</task>

<constraints>
- Do not report coefficients, p-values or fit statistics unless you computed them from the user's data. With only a description, provide code and an interpretation template.
- Do not use automated stepwise selection for inference, and say why if the user asks for it.
- Do not use causal language for coefficients unless the goal is effect estimation and the assumptions are stated.
- Keep code self-contained with assumed column names marked as comments.
</constraints>

<output_format>
## Question and goal
## Model choice
## Variables
A table: variable | role (outcome, predictor of interest, confounder, control, excluded) | type | transformation | reason.
## Code
## Diagnostics
A table: check | how to run it | what good looks like | what to do if it fails.
## How to interpret
## Limits
</output_format>
````

---

<a id="run-survival-analysis"></a>

## Run a survival (time-to-event) analysis

`run-survival-analysis` · prompt · Statistics · https://hermes-ide.com/prompts/run-survival-analysis

Runs a time-to-event analysis (Kaplan-Meier, Cox) for churn, failure or time-to-hire, handling censoring correctly, with code and a plain reading. Use when the question is how long until.

````markdown
<context>
You are a biostatistician who also works on churn, reliability and HR questions. Time-to-event data has one feature ordinary summaries get wrong: for many subjects the event has not happened yet. Dropping them, or treating them as if the event will never happen, biases the answer. You define the clock and the event precisely, keep censored subjects in the analysis, check the assumptions of the models you fit, and translate hazard ratios into language a manager can act on.
</context>

<task>
Set up and run a survival analysis.

<data_description>
[DATA_DESCRIPTION]
</data_description>

<event_definition>
[EVENT_DEFINITION]
</event_definition>

Write the code in python (Python uses pandas and lifelines; R uses survival, with survminer or ggsurvfit for plots; "any" means both).

1. Define the analysis: time zero (the origin), the event, the time unit, the end of follow-up (the extraction date), and what counts as censored (still active at extraction, lost to follow-up, administratively ended). If the event definition leaves this unclear, state the reading you use and the alternative.
2. Spot the traps in this data: left truncation (subjects who entered observation after time zero, such as customers acquired before the data starts), competing risks (an event that prevents the one of interest, such as a candidate hired elsewhere when the event is "hired by us", or an account closed by fraud), immortal time (covariates defined using information from after time zero), and time-varying covariates.
3. Prepare the data: code to build one row per subject with duration and event indicator (1 = event, 0 = censored), with checks: no negative or zero durations, event dates after start dates, and counts of events and censored subjects.
4. Kaplan-Meier: survival curves overall and by the main group, with confidence bands and a number-at-risk table; median time to event with its confidence interval (or "not reached"); survival at meaningful times (for example 30, 90 and 365 days); and a log-rank test between groups.
5. Cox proportional hazards model with the covariates that answer the question: hazard ratios with 95% confidence intervals, and a check of proportional hazards (Schoenfeld residuals: lifelines check_assumptions, or cox.zph in R) with what to do if it fails (stratify, add a time interaction, or report separate time windows).
6. With competing risks, use cumulative incidence (Aalen-Johansen) instead of 1 minus Kaplan-Meier, and for covariate effects either cause-specific Cox models (one per event type, treating the other events as censored) or a Fine-Gray subdistribution model, saying which question each answers. lifelines has AalenJohansenFitter but no Fine-Gray model; in R use tidycmprsk or cmprsk, and in Python fit cause-specific Cox models rather than inventing an API.
7. Explain the results in plain words, or, if no results were provided, explain how to read each output when it comes back.
</task>

<constraints>
- Never drop censored subjects or compute a simple "percent churned" that ignores follow-up time; explain the bias if the user's current approach does this.
- Do not invent results. The code produces them; if the user pastes output, interpret that output only.
- Use the column names from the data description; where one is missing, put a clearly marked placeholder in one configuration block at the top of the code.
- Interpret a hazard ratio as a relative rate at any given time ("customers on monthly plans cancel at about twice the rate of annual customers at any point"), not as a change in probability or in time, and say "is associated with" unless the design supports causation.
- Keep the code runnable from top to bottom with a fixed random seed where randomness is involved.
</constraints>

<output_format>
## Setup
Table: Item | Definition (time zero, event, censoring, unit, end of follow-up, competing risks).

## Data preparation
Code, then the checks to run and what they should show.

## Kaplan-Meier
Code, then how to read the curve, the median and the log-rank test.

## Cox model
Code, then how to read the hazard ratios.

## Assumption checks
Code and the decision rule for each check.

## What it means
Plain-language summary for a non-statistician, written from actual output or as a template with blanks if no output yet.

## Pitfalls
Up to five bullets specific to this data.
</output_format>
````

---

<a id="write-r-analysis-script"></a>

## Write an R analysis script

`write-r-analysis-script` · prompt · Statistics · https://hermes-ide.com/prompts/write-r-analysis-script

Writes a reproducible R (tidyverse) analysis script for a described dataset and question, with import, checks, analysis, plots and saved outputs. Use when you need an analysis others can re-run.

````markdown
<context>
You are an R developer and applied statistician who writes analysis scripts that a colleague can run a year later and get the same answer. That means explicit column types on import, checks that fail loudly when the data is not what the script expects, one clear path from raw data to results, plots that stand on their own, outputs written to files, and comments that explain why rather than what.
</context>

<task>
Write an R script that answers this question:

<question>
[QUESTION]
</question>

using this data:

<data_description>
[DATA_DESCRIPTION]
</data_description>

Structure the script in these sections, each starting with a comment banner:

1. Header comment: purpose, the question, input file, outputs, required packages, and the R version it was written for (4.1 or later, for the native pipe).
2. Setup: library() calls for the packages used (tidyverse, plus only what the analysis needs, such as broom, janitor, lubridate or a modelling package), a fixed seed if anything is random, and a config block with the input path, the output folder, and any thresholds or parameters as named variables.
3. Import: readr::read_csv (or the right reader for the format) with explicit col_types and na values matching the data description; janitor::clean_names if headers are messy.
4. Checks: stopifnot or explicit if-stop checks for expected columns, row count above zero, key uniqueness, allowed values of categorical columns, value ranges, and a printed summary of missing values per column. Each check has a message that says what went wrong.
5. Preparation: filtering, type fixes, derived variables and joins, each with a comment on why, and a row count printed after every step that can drop or duplicate rows.
6. Analysis: the method that answers the question (descriptive summaries, group comparisons, a test, or a model), chosen for the data and stated in a comment, with tidy output through broom where models are used, and an assumption check where the method has assumptions that matter.
7. Plots: ggplot2 charts that answer the question, with a title that states the takeaway, labelled axes with units, a caption with the data source, a colour-blind-friendly palette, and ggsave to the output folder at a stated size.
8. Outputs: write result tables to CSV in the output folder, and end with sessionInfo() so the environment is recorded.
</task>

<constraints>
- Use the column names exactly as described. If a needed column is missing or ambiguous, put a clearly marked placeholder in the config block and list it under Assumptions; never invent columns silently.
- Use relative paths (or the here package); never setwd() or rm(list = ls()), and never install packages inside the script; list them for the user to install once.
- Keep it runnable from top to bottom with Rscript, without interactive steps.
- Prefer clear tidyverse code over clever code; add a comment wherever a choice affects the answer (exclusions, outlier handling, model terms).
- Do not show results or claim what the script will output; it has not been run. Describe what to check when it runs.
</constraints>

<output_format>
## Assumptions
Bullets: column readings, choices made, placeholders to fill.

## Script
One fenced r code block containing the whole script.

## How to run
The packages to install once, the folder layout, and the Rscript command.

## What to check
Four to six bullets: which printed checks and outputs to look at, and what would mean the analysis needs revisiting.
</output_format>
````