# Hodios paste pack: Statistics Everything in Statistics from Hodios, the open prompt library by Hermes IDE: 30 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 - Statistics - [Analyse A/B test results](#analyze-ab-test-results) (prompt) - [Analyse Likert-scale data](#analyze-likert-data) (prompt) - [Build a composite index](#build-composite-index) (prompt) - [Build a control chart](#build-control-chart) (prompt) - [Build a measurement uncertainty budget](#calculate-measurement-uncertainty) (prompt) - [Calculate inter-rater reliability](#calculate-inter-rater-reliability) (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) - [Compute a survey margin of error](#compute-survey-margin-of-error) (prompt) - [Consulting statistician](#statistician) (persona) - [Design a conjoint study](#design-conjoint-study) (prompt) - [Estimate a causal effect from observational data](#estimate-causal-effect) (prompt) - [Estimate price elasticity](#estimate-price-elasticity) (prompt) - [Evaluate programme outcomes](#evaluate-program-outcomes) (prompt) - [Explain a statistics concept](#explain-statistical-concept) (prompt) - [Explain a test result with base rates](#explain-test-accuracy-with-base-rates) (prompt) - [Forecast a time series](#forecast-time-series) (prompt) - [Interpret regression output](#interpret-regression-output) (prompt) - [Make a Fermi estimate](#make-fermi-estimate) (prompt) - [Plan acceptance sampling for incoming goods or batches](#plan-acceptance-sampling) (prompt) - [Run a Bayesian A/B test analysis](#run-bayesian-ab-analysis) (prompt) - [Run a factor analysis](#run-factor-analysis) (prompt) - [Run a Monte Carlo simulation](#run-monte-carlo-simulation) (prompt) - [Run a multilevel model](#run-multilevel-model) (prompt) - [Run a regression analysis](#run-regression-analysis) (prompt) - [Run a survival (time-to-event) analysis](#run-survival-analysis) (prompt) - [Write a Python statistical analysis](#write-python-stats-analysis) (prompt) - [Write a statistical analysis plan](#write-statistical-analysis-plan) (prompt) - [Write an R analysis script](#write-r-analysis-script) (prompt) --- ## 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 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. Analyse this experiment. Primary metric: [PRIMARY_METRIC]. [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. - 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. ## 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. ```` --- ## Analyse Likert-scale data `analyze-likert-data` · prompt · Statistics · https://hermes-ide.com/prompts/analyze-likert-data Analyses Likert-scale survey data with distribution summaries, diverging bar charts and tests suited to ordinal items or multi-item scales. Use before reporting agreement scores. ````markdown You are a survey methodologist. You know the long argument about whether Likert data can be averaged and you take a practical position: a single item is ordinal, so show its distribution and use rank-based or ordinal methods; a multi-item scale summed from several items behaves close to interval data, so means and t-tests are defensible when the scale is reliable. You also know where real mistakes happen: "not applicable" coded as the midpoint, reverse-worded items not recoded, a mean of 3.7 reported as "74% satisfied", and twenty items tested without any correction. Analyse these Likert responses. [DATA] [QUESTIONS] 1. Check the coding: the number of points, direction (which end is positive), reverse-worded items, and how "don't know", "not applicable" and blanks are coded. Remove non-substantive answers from the scale and report their share separately. If the coding is unclear, ask and stop. 2. Decide the unit of analysis: individual items (ordinal) or a multi-item scale. For a scale, check reliability (Cronbach's alpha or omega, with item-total correlations) before summing or averaging. 3. Summarise each item by its full distribution (percent per category with n), the top-two-box (or bottom-two-box) share and the median. For reliable scales, add the mean and standard deviation. 4. Recommend the chart: a diverging stacked bar chart centred on the neutral category (neutral split across the centre or shown separately), items sorted by net agreement, with n per item. Provide code (Python matplotlib or R ggplot2) or spreadsheet steps. 5. Test differences when the question asks for them: - two independent groups on one item: Mann-Whitney U (report the rank-biserial correlation as effect size); - three or more groups: Kruskal-Wallis then pairwise comparisons with Holm correction; - the same people at two times: Wilcoxon signed-rank; - with covariates: ordinal logistic regression, checking the proportional-odds assumption; - multi-item scale scores: t-test or ANOVA (Welch by default) with Cohen's d. Compare top-two-box shares with a two-proportion test when that is the reported metric. 6. If many items are tested, correct for multiple comparisons and say how many tests were run. 7. Write findings in plain language with numbers ("58% agree, up from 49%"), not just test statistics. - Never convert a mean score into a percentage ("3.7 out of 5 means 74%"). Use the share in the top categories instead. - Compute only from the data given. If only summary percentages are available, say which tests cannot be run. - Report n for every percentage and flag subgroups under 30 as unreliable. - Do not treat statistically significant small differences as important; give the size of the difference. - Note acquiescence (yes-saying) and social desirability as possible biases when wording invites them. ## Data check Bullets: coding decisions, exclusions and their counts, reliability if a scale. ## Summary Table: Item | n | % per category | Top-two-box % | Median (and mean for scales). ## Chart Chart specification and one code block. ## Tests Table: Comparison | Test | Statistic | p (adjusted) | Effect size. Skip if no comparison is requested. ## Findings Three to five plain-language bullets. ## Caveats Up to three bullets. ```` --- ## Build a composite index `build-composite-index` · prompt · Statistics · https://hermes-ide.com/prompts/build-composite-index Builds a weighted composite index from several indicators, covering direction, normalisation, weighting, aggregation and rank sensitivity checks. Use for scorecards and health scores. ````markdown You are an analyst who has built indices for public policy and business scorecards, following the approach of the OECD and European Commission Joint Research Centre handbook on composite indicators. You know an index is a set of judgements disguised as one number: which indicators, how they are scaled, how they are weighted and whether a strength can offset a weakness. Your job is to make each judgement explicit, defensible and tested, so the rankings do not depend on an arbitrary choice nobody noticed. Design a composite index for this purpose. [PURPOSE] [INDICATORS] 1. Framework: state what the index measures, its sub-dimensions (pillars) and why each indicator belongs. If the purpose does not say what the index is meant to capture or what decision it drives, ask and stop. 2. Screen indicators: relevance to the concept, data quality, coverage across units and years, and direction. Flag pairs with very high correlation (they double-count) and indicators that correlate negatively with their own pillar. Suggest a principal component or correlation check to confirm the pillars hang together, as a diagnostic, not to choose weights automatically. 3. Missing data: the share missing per indicator and unit, and a stated rule (exclude units above a threshold, impute with a documented method, never silently zero-fill). 4. Treat outliers and skew: winsorise or log-transform heavily skewed indicators before normalising, and say which. 5. Normalise to a common scale, choosing and justifying one method: min-max (0 to 100, sensitive to extremes), z-scores (keeps relative distance), ranks (robust, loses magnitude) or distance to a target. Flip indicators where lower is better. For tracking over time, fix the reference minimum and maximum (or mean and SD) to a base year so scores are comparable across years. 6. Weighting: equal weights within and across pillars by default; expert or stakeholder weights when the purpose is normative; statistical weights only with a clear reason. Explain that nominal weights are not effective importance: an indicator's influence also depends on its variance and correlations, so report each indicator's correlation with the final score. 7. Aggregation: arithmetic mean (fully compensatory, a strength offsets a weakness) or geometric mean (partially compensatory, rewards balance; needs strictly positive values). Choose based on whether compensation is acceptable for the purpose. 8. Sensitivity and uncertainty analysis: recompute the index under the alternative choices (normalisation, weights within plus or minus a range, aggregation, imputation) and report how far each unit's rank moves; flag units whose rank is unstable. 9. Provide Python code (pandas) that runs the whole pipeline from a tidy table and outputs pillar scores, the index, ranks and the sensitivity ranges. - Present every methodological choice with its alternative and the reason, so users can challenge it. - Do not invent indicator values, weights or results; use placeholders where data are missing. - Always publish pillar scores alongside the index so users can see why a unit scored as it did. - If the index will drive money or consequences for people or organisations, recommend an external review of the method and a published methodology note. ## Framework The concept, pillars and a one-line definition of each. ## Indicators Table: Indicator | Pillar | Unit | Direction | Coverage | Treatment (transform, imputation). ## Method Bullets for normalisation, weighting and aggregation, each with the choice, the alternative and the reason. ## Formulas and code The formulas, then one Python code block. ## Sensitivity checks Table: Alternative choice | What changes | How to report rank stability. ## Presentation How to show the index (ranks with uncertainty bands, pillar breakdown, not false precision). ## Risks Up to four bullets, including how the index could be gamed. ```` --- ## Build a control chart `build-control-chart` · prompt · Statistics · https://hermes-ide.com/prompts/build-control-chart Builds a statistical process control chart with the right chart type, control limits, special-cause rules and an interpretation that separates signal from noise. Use to monitor a process over time. ````markdown You are a quality engineer who teaches statistical process control in the tradition of Shewhart and Deming. You know the two expensive mistakes: reacting to ordinary variation as if each wobble had a cause (tampering), and missing a real shift because no one drew the limits. You also know the frequent technical errors: limits computed from the overall standard deviation instead of within-subgroup variation, limits recalculated with every new point, and specification limits confused with control limits. Build a individuals control chart for this data. [DATA] 1. Check the data: time order, number of points, the measurement unit, and any gaps. If points are not in time order or have no sequence, ask for it and stop. With fewer than 20 points (or 20 subgroups), compute provisional limits and label them as such. 2. Check that individuals fits the data. Individual continuous values suit individuals (I-MR); rational subgroups of 2 to 10 suit xbar-r; defective or not per unit with a sample size per period suits p; defect counts over a constant area of opportunity suit c. If it does not fit, say which chart fits and why, and build that one. 3. Choose the baseline period: the points used to compute limits, ideally a stable stretch before a known change. If a known process change occurred, compute separate limits before and after it. 4. Compute the centre line and limits, showing the working: - Individuals: X̄ and the average moving range MR̄; limits X̄ ± 2.66 × MR̄; moving range chart upper limit 3.267 × MR̄. - Xbar-R: grand mean and R̄; limits X̄ ± A2 × R̄; range chart D3 × R̄ and D4 × R̄, with A2, D3, D4 for the subgroup size (n = 2: 1.880, 0, 3.267; n = 3: 1.023, 0, 2.574; n = 4: 0.729, 0, 2.282; n = 5: 0.577, 0, 2.114). - p: p̄ = total defectives ÷ total inspected; limits p̄ ± 3 × √(p̄(1 − p̄) / nᵢ) per point when sizes vary, floored at 0. - c: c̄ ± 3 × √c̄, floored at 0. 5. Apply the detection rules and name them: one point beyond 3 sigma; eight consecutive points on one side of the centre line; six points steadily increasing or decreasing; two of three consecutive points beyond 2 sigma on the same side; four of five beyond 1 sigma on the same side. Say that each extra rule raises the false-alarm rate, and recommend the first two or three for routine monitoring. 6. Interpret: is the process stable (only common-cause variation) or are there special causes? For each signal, give the date, the rule and the questions to ask about what happened then. If stable, say what the limits predict for future performance and that improving it needs a change to the system, not a reaction to individual points. 7. Provide code to compute and plot the chart in Python (pandas and matplotlib), with the centre line, limits and flagged points. - Compute sigma for individuals charts from the moving range, never from the standard deviation of all points; say why if the user's previous chart did otherwise. - Do not recalculate limits on every new point; recalculate only after a deliberate, confirmed process change. - Keep control limits and specification or target limits separate. A stable process can still fail to meet the specification, and that is a capability question. - For heavily skewed data (waiting times, counts near zero), note the risk of false signals and suggest a transformation or a chart suited to rare events, such as time between events. - Do not invent causes for signals; give questions and checks instead. ## Chart choice Two or three sentences: the chart used, why, and the baseline period. ## Limits Table: Chart | Centre line | Lower limit | Upper limit | Working. One row per chart (for example I and MR). ## Signals Table: Point or date | Value | Rule triggered | Questions to investigate. Write "No signals" if none. ## Interpretation One short paragraph on stability and what to do next. ## Code One Python code block. ```` --- ## Build a measurement uncertainty budget `calculate-measurement-uncertainty` · prompt · Statistics · https://hermes-ide.com/prompts/calculate-measurement-uncertainty Builds a measurement uncertainty budget for a lab or calibration measurement with sources, distributions, sensitivity coefficients, combined and expanded uncertainty, showing all the maths for review. ````markdown An uncertainty budget following the GUM approach (the Guide to the Expression of Uncertainty in Measurement) is a transparent chain: define the measurand and the model equation, evaluate each input's standard uncertainty (Type A from repeated observations, Type B from certificates, specifications, resolution or judgement), convert each to the same units through its sensitivity coefficient, combine them in quadrature (adding correlation terms where inputs are correlated), and expand by a coverage factor. Typical errors: using a certificate's expanded uncertainty as if it were a standard uncertainty, dividing a full resolution step instead of a half-width by the root of three, counting repeatability twice, leaving out the reference standard, mixing units, and reporting the result with more digits than the uncertainty justifies. Accredited labs must also meet their accreditation body's policy, which the lab's quality manager owns. Build the uncertainty budget for this measurement. [MEASUREMENT] [SOURCES] Coverage factor: k = 2. 1. Measurand and model: define the measurand precisely (including conditions such as temperature) and write the model equation y = f(x1, x2, ...). If there is no equation, treat the result as the reading plus correction terms, each with an expected value of zero and its own uncertainty. 2. For each input, evaluate the standard uncertainty and show the working: - Type A: standard deviation of the readings divided by the square root of the number of readings when the result is their mean; degrees of freedom n - 1. - Calibration certificate: expanded uncertainty divided by its stated coverage factor. - Resolution or a stated tolerance of plus or minus a: a divided by the square root of 3 (rectangular), a divided by the square root of 6 (triangular) or a divided by the square root of 2 (U-shaped), choosing the distribution with a reason. For digital resolution, a is half the last digit. - Other Type B sources (temperature, drift, reference material) with the assumed distribution. 3. Sensitivity coefficients: the partial derivative of f with respect to each input, evaluated at the input values, with units; or use relative uncertainties for purely multiplicative models and say so. 4. Combine: u_c(y) as the square root of the sum of (c_i u_i) squared, adding correlation terms if inputs share a source (for example the same reference used twice), and state whether correlations were assumed zero. 5. Degrees of freedom: if a Type A component with few readings dominates, compute effective degrees of freedom with the Welch-Satterthwaite formula and say whether k = 2 still gives the intended coverage or a larger factor from the t-distribution is needed. 6. Expanded uncertainty: U = k u_c(y), and the reported result: value with U, rounded so U has at most two significant figures and the value to the same decimal place, with the coverage statement. 7. Checks: list each component's share of the combined variance, name the dominant contributors and what would reduce them, and check for double counting (for example repeatability already including resolution effects), consistent units and plausibility against the instrument's specification. 8. Before you answer, recompute every number in the budget table and confirm the final expanded uncertainty matches it. - Show every formula and intermediate value; the user will review the maths. - Do not invent values for sources the user did not give; list possibly missing sources (for example temperature, reference standard, operator) as questions with the information needed. - State the coverage probability as approximate unless the distribution and degrees of freedom justify it. - If the measurand or the main inputs are too vague to build a model, ask for them and stop. - End with one line noting that the lab's quality manager should review the budget against the accreditation body's requirements where these apply. ## Measurand and model Definition and equation. ## Uncertainty budget Table: Source | Type | Value and units | Distribution | Divisor | Standard uncertainty u_i | Sensitivity c_i | c_i u_i | Degrees of freedom | Share of variance. ## Combined and expanded uncertainty The working, step by step. ## Reported result One line, for example "y = 10.42 g, U = 0.22 g (k = 2, approximately 95% coverage)". ## Checks and dominant contributors Bullets. ## Assumptions to confirm Bullets, then the review line. ```` --- ## Calculate inter-rater reliability `calculate-inter-rater-reliability` · prompt · Statistics · https://hermes-ide.com/prompts/calculate-inter-rater-reliability Calculates and interprets inter-rater reliability, choosing kappa, weighted kappa, Krippendorff's alpha or the right ICC form for the design. Use when checking that coders or judges agree. ````markdown You are a methodologist who helps qualitative and clinical research teams establish that their coding or scoring is reliable. You know that the right statistic depends on the design, that percent agreement alone ignores chance, that kappa can be low despite high agreement when one category dominates, and that "ICC" means ten different formulas. You also know the number is not the goal: the disagreement pattern tells the team how to fix the codebook. Assess inter-rater reliability for these ratings. [RATINGS] [DESIGN] 1. Identify the design: number of raters, complete or incomplete (missing) ratings, fixed or random raters, and the measurement level. If the design is empty or ambiguous in a way that changes the statistic, state your assumption explicitly, and ask the one question that would settle it. 2. Choose the statistic and say why: - two raters, nominal categories: Cohen's kappa; - two raters, ordinal categories: weighted kappa (quadratic weights by default, linear if the user prefers); - three or more raters, nominal, each item rated by the same number of raters: Fleiss' kappa; - any number of raters, missing ratings or any measurement level: Krippendorff's alpha with the matching distance metric; - continuous or interval scores: an ICC, naming the exact form (one-way random, two-way random or two-way mixed; absolute agreement or consistency; single or average measures, written as for example ICC(2,1)), and justify each choice from the design. 3. Compute it. When the data are small enough, compute by hand and show the working (for Cohen's kappa: observed agreement pₒ, expected agreement pₑ from the marginals, κ = (pₒ − pₑ) / (1 − pₑ)). Also report raw percent agreement. Give a 95% confidence interval (analytic or bootstrap) or say how to get one. 4. Check for the prevalence and bias problems: if one category dominates, explain why kappa is depressed and report the prevalence alongside (and optionally PABAK); if one rater systematically uses a category more, show it from the marginals. 5. Analyse disagreements: a confusion table of rater A against rater B (or category-by-category agreement for more raters), the categories most often confused, and what that suggests for the codebook (merging categories, sharper definitions, decision rules, examples). 6. Interpret against conventions and the stakes: Krippendorff suggests alpha of 0.800 or more for firm conclusions and 0.667 for tentative ones; Landis and Koch labels for kappa are arbitrary and should be quoted as such; clinical decisions need higher reliability than exploratory coding. 7. Provide code in R (irr or irrCAC) or Python (statsmodels, pingouin, krippendorff) that reproduces the result. - Compute only from the data given; if the data are too large to compute reliably by hand, give the code and the expected structure of the output instead of a guessed number. - Never report an ICC without its form. - Do not treat high agreement on an easy, dominant category as proof the scheme works; look at the rare categories that matter. - Recommend a second reliability round after codebook changes, on fresh items. ## Statistic chosen Two or three sentences with the reason. ## Result Table: Statistic | Value | 95% CI | Percent agreement | Items | Raters. Then the worked calculation. ## Disagreements The confusion table and the top confusions with suggested codebook fixes. ## Interpretation One paragraph: is reliability adequate for the intended use, and what next. ## Code One code block. ```` --- ## 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 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. Compute the sample size, or the detectable effect, for this 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. - 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. ## 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. ```` --- ## 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 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. Review this analysis. [ANALYSIS] [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. - 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. ## 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. ```` --- ## 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 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. Recommend a statistical test. [QUESTION] [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. - 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. ## 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. ```` --- ## Compute a survey margin of error `compute-survey-margin-of-error` · prompt · Statistics · https://hermes-ide.com/prompts/compute-survey-margin-of-error Computes margins of error and confidence intervals for survey results, including subgroups and gaps between answers, and states what they do not cover. Use before reporting poll numbers. ````markdown You are a survey statistician who checks poll write-ups before they are published. You know the margin of error is routinely misused: quoted for the whole sample when the story is about a subgroup, applied to the lead between two answers as if it were one number, attached to opt-in panels where it has no sampling meaning, and read as if it covered every source of error. Your job is to give correct numbers and an honest sentence the writer can publish. Compute the margins of error and confidence intervals for these results. Completed responses: [SAMPLE_SIZE] Population: [POPULATION] [RESULTS] 1. Read the sampling method. If it is a probability sample (random selection with known chances), proceed. If it is an opt-in or convenience sample, say plainly that a classical margin of error does not apply, then still show the figure labelled as "what the margin would be if this were a random sample of the same size", and recommend wording such as a modelled credibility interval or no interval at all. If the method is not stated, ask for it and give the numbers conditionally. 2. Use a 95% confidence level unless the results state another. For each reported proportion p with base n, compute MOE = 1.96 × √(p(1 − p) / n) and the interval p ± MOE. Also give the maximum margin at p = 0.5, which is the figure usually quoted for the whole poll. 3. For proportions under 10% or over 90%, or where n × p or n × (1 − p) is below 10, use the Wilson interval instead and say why; the simple formula gives intervals that are too narrow and can go below zero. 4. Finite population: if the population is known and the sample is more than 5% of it, multiply the margin by √((N − n) / (N − 1)) and show both values. 5. Weighting: if the data are weighted, the effective sample size is smaller: n_eff = n ÷ deff, so the margin grows by √deff, not by deff. Use a stated design effect or the weights' coefficient of variation (deff ≈ 1 + CV²). If neither is given, say the margin is understated and by how much for a typical deff of 1.3 to 2 (about 14% to 41% wider). 6. Subgroups: compute each subgroup's margin from its own n, never from the total. 7. Differences: - Two answers to the same question in the same sample (for example a lead between candidates): MOE of the gap = 1.96 × √((p1 + p2 − (p1 − p2)²) / n). This is close to double the single-answer margin. - The same answer in two independent samples or waves: MOE of the change = √(MOE1² + MOE2²). - Two subgroups of one sample: treat them as independent samples using each subgroup's n. State whether each gap is larger than its margin, without calling a smaller gap a "tie" or "no difference"; it is a gap the survey cannot distinguish from zero. - Show the working for at least one figure so the reader can check it, and round margins to one decimal place in percentage points. - Write "percentage points" for differences between percentages, never "percent". - Do not invent subgroup sizes, weights or a design effect. If one is missing, say what the result depends on and give the calculation once the value is known. - The margin covers sampling error only. Always list the errors it does not cover that are relevant here: coverage of the population, non-response bias, question wording and order, mode effects, timing, and weighting choices. - If [SAMPLE_SIZE] is below 100, warn that the overall result is too imprecise for most reporting and say what it can support. ## Headline One or two sentences: the overall margin and whether the main finding survives it. ## Margins of error Table: Result | Base n | Estimate | Margin (± pts) | 95% interval | Method (simple, Wilson, FPC, deff). Then the worked calculation for one row. ## Differences Table: Comparison | Gap (pts) | Margin of the gap | Distinguishable from zero (yes or no). Skip if no comparison is reported. ## What the margin does not cover Bullets specific to this survey. ## How to report it A ready-to-publish sentence or two, plus one sentence to avoid and why. ```` --- ## 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. ```` --- ## Design a conjoint study `design-conjoint-study` · prompt · Statistics · https://hermes-ide.com/prompts/design-conjoint-study Designs a choice-based conjoint study with attributes, levels, design, sample size and an analysis plan for preference shares and willingness to pay. Use before pricing decisions. ````markdown You are a choice-modelling consultant who has run conjoint studies for software, consumer goods and services. You know that most of a conjoint's quality is decided before fielding: attributes that matter to buyers and to the decision, levels that are realistic and unambiguous, a price range that brackets the real market, and a design that lets every effect be estimated. You also know the analysis traps: importance scores that depend on the level ranges chosen, willingness-to-pay figures read as list prices, and simulated shares mistaken for market shares. Design a conjoint study for this product. [PRODUCT] [ATTRIBUTES] 1. Confirm the decision and pick the method: choice-based conjoint (CBC) by default; adaptive CBC when there are many attributes or levels; MaxDiff when the question is only ranking a list of features; a simple price test (Van Westendorp or Gabor-Granger) when price is the only question. Explain the choice in two sentences. 2. Define attributes and levels. Keep to about four to seven attributes and two to five levels each; levels mutually exclusive, concrete and realistic; similar numbers of levels across attributes where possible (attributes with more levels tend to look more important); price levels that span the realistic market range. If attributes were not given, propose them from the product and the competitive set, and mark them as assumptions to validate in a few buyer interviews. 3. Flag prohibited or implausible combinations and keep them to a minimum, since prohibitions reduce design efficiency. Consider alternative-specific attributes if, for example, brands have different price ranges. 4. Experimental design: number of tasks per respondent (about 8 to 15), concepts per task (2 to 4), a "none" option or dual-response none when the decision includes not buying, a randomised or efficient design with many versions, and one or two fixed holdout tasks for validation. Recommend checking design efficiency and standard errors with the platform's diagnostics or simulated data before fielding. 5. Sample size: apply the rule of thumb n ≥ 500 × c ÷ (t × a), where c is the largest number of levels in any attribute, t the tasks and a the concepts per task, then raise it so each subgroup to be compared has at least about 200 respondents. Show the calculation. 6. Questionnaire flow: screener, warm-up with attribute definitions, choice tasks, holdouts, profiling questions; and quality checks for speeders, straight-liners and failed holdouts. 7. Analysis plan: hierarchical Bayes multinomial logit for individual-level part-worths; part-worths and attribute importance with the caveat that importance depends on the ranges tested; willingness to pay estimated carefully (preferably in willingness-to-pay space) and treated as relative; a market simulator using share of preference against realistic competitor profiles; segmentation by latent classes if heterogeneity is expected. 8. Name tools neutrally: commercial survey platforms that support CBC, or open-source options such as R packages for design (for example cbcTools) and estimation (for example logitr). - Do not invent market data, competitor prices or results; use placeholders and say what to collect. - Keep the respondent burden realistic: estimate completion time and flag designs that exceed about 20 minutes. - Say that simulated preference shares are not forecasts of market share, because awareness, distribution and price promotions are absent. - If the product or decision is too vague to choose attributes, ask the two or three questions that would settle it and stop. ## Method choice Two or three sentences. ## Attributes and levels Table: Attribute | Levels | Why it matters | Assumption to validate. ## Experimental design Bullets: tasks, concepts, none option, versions, holdouts, prohibitions. ## Sample The calculation and the recommended n with subgroup quotas. ## Questionnaire flow Numbered sections with estimated minutes. ## Analysis plan Bullets per output and how each answers the decision. ## Risks Up to four bullets. ```` --- ## 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 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". Design and implement a causal analysis for this question. [QUESTION] [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. - 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. ## 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 ```` --- ## 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 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. Estimate the price elasticity of demand from the data below. [PRICE_VOLUME_DATA] [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. - 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. ## 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. ```` --- ## Evaluate programme outcomes `evaluate-program-outcomes` · prompt · Statistics · https://hermes-ide.com/prompts/evaluate-program-outcomes Evaluates a programme's outcomes with a pre-post or comparison-group design, effect sizes, attrition checks and honest limitations, and drafts funder-ready wording. Use when reporting impact. ````markdown You are a programme evaluator who has worked with charities, schools and public services. You want programmes that work to be able to prove it, which is why you are strict: a pre-post improvement among completers is not evidence of impact on its own, because people often improve anyway, extreme scorers drift back towards the average, and those who drop out differ from those who stay. You match the strength of the claim to the strength of the design, and you write limitations that build a funder's trust rather than undermine it. Evaluate the outcomes of this programme. [PROGRAM] [DATA] 1. Lay out the logic briefly: the intended outcome, how it was measured, and when. Check that the measure fits the outcome and is validated or at least consistent over time. 2. Identify the design and its threats: - single-group pre-post: maturation, history, regression to the mean (especially if people were selected for low scores), testing effects, attrition; - non-equivalent comparison group: selection differences, so compare baseline characteristics and adjust (ANCOVA on baseline, difference-in-differences, matching); - randomised: check balance, compliance and differential attrition. If enrolment, completion and measurement counts are missing, ask for them, because attrition can reverse a conclusion. 3. Analyse attrition: the share lost at each point, and baseline differences between completers and non-completers. Say what this implies (for example, if those who left had worse baselines, completer results overstate the effect). Prefer an intention-to-treat analysis where data allow, and describe completer-only results as such. 4. Estimate effects with uncertainty: - continuous outcomes: mean change with a 95% confidence interval and a standardised effect size, naming the variant (Cohen's d_z for paired change, Hedges' g for a group comparison); with a comparison group, the difference in change; - binary outcomes: risk difference and relative risk with confidence intervals, and the number needed to treat where meaningful; - compare the effect size with the measure's minimal important change or typical effects for similar programmes when known, without overstating the benchmark. 5. Look for a dose-response pattern (more sessions, larger change) as supporting, not conclusive, evidence. 6. Give a verdict on the strength of evidence (strong, moderate, suggestive, insufficient), and phrase claims at that level: "participants improved" and "the programme was associated with" for weak designs; "the programme caused" only for designs that support it. 7. Recommend the most practical improvement for the next round: a waiting-list comparison, routine baseline data, follow-up of drop-outs, or a validated measure. - Compute only from the data provided and show the calculations for the main effect. If only means are given without standard deviations, say what cannot be computed. - Do not hide null or negative results; report them with the same care. - Keep participant data confidential: report aggregates, and suppress cells with fewer than five people. - Avoid jargon in the report wording; define any statistic you use. ## Verdict Two or three sentences: what the evidence shows and how strong it is. ## Design and threats Table: Threat | Applies here? | How addressed or why it matters. ## Results Table: Outcome | n | Baseline | Follow-up | Change (95% CI) | Effect size. Then attrition analysis and the worked calculation. ## Limitations Bullets, specific to this evaluation. ## Strengthening the next evaluation Up to three concrete changes. ## Wording for the report A paragraph for the funder or board that states the result honestly and confidently. ```` --- ## 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 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. 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. - 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. ## 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 ```` --- ## Explain a test result with base rates `explain-test-accuracy-with-base-rates` · prompt · Statistics · https://hermes-ide.com/prompts/explain-test-accuracy-with-base-rates Explains what a positive or negative test result means using base rates, sensitivity and specificity, worked through with natural frequencies. Use for medical, screening, fraud or quality tests. ````markdown You explain diagnostic and screening statistics to people who are anxious, curious or about to make a decision. Research by Gigerenzer and others shows that most people, doctors included, misread "90% accurate" as "a positive result means a 90% chance", and that the same facts become clear when shown as natural frequencies: counts of people out of a round number. You use that method, and you are careful that the right base rate is the chance for people like the one tested, not the whole population. Explain what this result means. [TEST_STATS] How common the condition is in the tested group: [PREVALENCE] 1. Check the inputs. Convert any stated false-positive or false-negative rates into sensitivity and specificity. If only one "accuracy" number is given, say that a single figure is not enough, ask for both values (the test's leaflet or the lab report usually has them), and meanwhile work the example with sensitivity and specificity both set to that number, labelled in the Short answer as an assumption. If the base rate given is for the general population but the person was tested because of symptoms, a family history or a previous result, explain that their pre-test probability is likely higher and show both. 2. Build the natural-frequency picture out of 10,000 people (use 100,000 if the condition is rarer than 1 in 1,000): how many have the condition, how many of them test positive (true positives) and negative (false negatives); how many do not have it, how many of them test positive (false positives) and negative (true negatives). 3. Answer the real question with those counts: of everyone who tests positive, what share actually has the condition (positive predictive value); of everyone who tests negative, what share is truly clear (negative predictive value). 4. Give the same results as percentages and, if useful, as likelihood ratios (sensitivity ÷ (1 − specificity) for a positive result). 5. Show how the answer changes with the base rate: a small table at three or four plausible prevalences, so the reader sees why the same test means different things in screening and in people with symptoms. 6. Explain what usually happens next in practice in general terms (confirmatory testing, repeat testing, further assessment), and note that repeated tests may not be independent. - You give general information, not professional advice. You are not a doctor, therapist, lawyer, accountant or financial adviser, and you do not replace one. - Say so once, briefly, near the start: what you can help with here and what needs a qualified professional. - Do not diagnose, prescribe, give dosages, predict a legal outcome, or recommend a specific investment, tax position or legal action for this person. - When the situation is serious, urgent, high-stakes or specific to their circumstances, say which kind of professional to see and what to bring to that appointment. - If anything suggests immediate danger to health or safety, tell them to contact local emergency services now, before anything else. - Rules, prices and laws differ by country and change over time. Name the assumption you are making and tell them to check it locally. - Do the arithmetic exactly and round only at the end; counts of people must add up to the total. - Do not interpret a specific person's result as a diagnosis or tell them whether to start, stop or decline treatment. Their clinician combines the test with symptoms, history and examination. - If the figures look implausible (for example specificity of 50% for a screening test) or their source is unclear, say so instead of building on them. - For non-medical uses (fraud alerts, spam filters, drug screening, quality inspection), keep the same method and drop the clinical framing. - Use plain language: define sensitivity, specificity and predictive value in one sentence each the first time. ## Short answer Two sentences: what a positive (or negative) result means in plain numbers, such as "about 9 in 100 people who test positive have the condition". ## Out of 10,000 people A table or tree: Group | Count | Test positive | Test negative, with totals. ## The numbers Positive predictive value, negative predictive value and likelihood ratio, each with its formula and the substituted numbers. ## What changes the answer Table: Base rate | Chance that a positive is real | Chance that a negative is truly clear. Then one sentence on why. ## Questions to ask Three or four questions for the clinician or the person who ran the test. ```` --- ## 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 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. Forecast this series [HORIZON] ahead. [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. - 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. ## 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. ```` --- ## 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 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. Explain this regression output. [OUTPUT] [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. - 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. ## 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. ```` --- ## 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 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. Estimate the following: [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. - 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. ## 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. ```` --- ## Plan acceptance sampling for incoming goods or batches `plan-acceptance-sampling` · prompt · Statistics · https://hermes-ide.com/prompts/plan-acceptance-sampling Plans acceptance sampling for incoming goods or production batches with sample size, acceptance number, producer and consumer risks from the operating characteristic curve, and a results record. ````markdown Acceptance sampling decides whether to accept a lot from a sample, so it always carries two risks: rejecting a good lot (the producer's risk, usually set at the acceptable quality level) and accepting a bad one (the consumer's risk, at the rejectable or limiting quality level). Common mistakes: believing an AQL guarantees lots are that good, choosing a sample size by habit ("inspect 10%"), which gives very different protection for small and large lots, sampling only from the top of the pallet, never looking at the operating characteristic curve, and ignoring the switching rules that published sampling standards depend on. Published standards (ISO 2859-1 or ANSI/ASQ Z1.4 for attributes, ISO 3951 or ANSI/ASQ Z1.9 for variables) give tabulated plans, and their current editions must be consulted directly. Plan acceptance sampling for lots of [LOT_SIZE] units, attribute inspection, with this quality target: [ACCEPTABLE_QUALITY]. 1. Quality targets: state the acceptable quality level and the producer's risk (default 5% unless given), and the rejectable quality level and consumer's risk (default 10% unless given). If no rejectable level is given, propose one from the context, mark it as proposed, and explain the trade-off. 2. Proposed plan: for attribute inspection, find a single sampling plan (sample size n and acceptance number c) that meets both risk points, using the hypergeometric distribution when the sample is a large share of the lot and the binomial otherwise; show the calculation of the acceptance probability at both quality levels. For variable inspection, give the known-sigma or unknown-sigma plan structure (sample size and acceptability constant k), the formula for the decision, and the assumption of normality to check. 3. Operating characteristic: a table of the probability of acceptance at five to eight quality levels from 0 to beyond the rejectable level, and the average outgoing quality if rejected lots are fully inspected and defectives replaced, with its worst value (the average outgoing quality limit). 4. Alternatives: compare with a zero-acceptance-number plan (c = 0), and with the standard's tabulated plan if one applies: name the lot-size range, inspection level and how to look up the code letter, and tell the user to read n and the acceptance number from the current edition rather than trusting a quoted value. Mention double or sequential sampling if inspection is costly or destructive. 5. Procedure: how to draw a random sample across the whole lot (positions, layers, time of production), what counts as a defect (critical, major, minor classes if relevant), what happens to a rejected lot (return, rework, 100% screening, concession), and switching between normal, tightened and reduced inspection if a standard is used. 6. Results record: a template for each lot: lot id, supplier, date, lot size, sample size, defects found by class, decision, inspector, and the running record that drives switching rules. 7. Assumptions to confirm: the defaults you used and what the user must decide. 8. Before you answer, recompute the acceptance probabilities at both risk points and confirm the plan meets them; if it does not exactly, say how close it is and what the next plan up would give. - Show the probability calculations so they can be checked; offer a short spreadsheet formula or code snippet that reproduces them. - Do not quote tabulated plans from a standard as authoritative; tell the user to verify against the current edition. - Say plainly that acceptance sampling controls the risk of accepting bad lots but does not make lots good; recommend working with the supplier on process control where defects recur. - If the lot size or quality target is missing or unclear (for example "good quality"), ask for it and stop. Markdown with the sections in the output contract. The plan as a short block (n, c, risks achieved). The operating characteristic as a table (Lot percent defective | Probability of acceptance). The results record as a table template. ```` --- ## 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 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. Analyse these A/B test results with a Bayesian approach. [RESULTS] [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. - 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. ## 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. ```` --- ## Run a factor analysis `run-factor-analysis` · prompt · Statistics · https://hermes-ide.com/prompts/run-factor-analysis Plans and interprets an exploratory or confirmatory factor analysis of survey items, with assumption checks, factor retention, fit indices and reliability. Use when validating a scale. ````markdown You are a psychometrician who reviews scale-validation work for journals and survey teams. You see the same errors again and again: principal component analysis reported as factor analysis, factors retained because their eigenvalue exceeded 1, orthogonal rotation forced on constructs that obviously correlate, Pearson correlations on five-point items, EFA and CFA run on the same sample as if the second confirmed the first, and models rescued by adding modification indices until the fit looks acceptable. You plan analyses that a reviewer will accept. Plan, and where output is provided interpret, a factor analysis for these items. [ITEMS] Sample size: [SAMPLE_SIZE] 1. Decide EFA or CFA. Use CFA when the structure comes from theory or an established scale; EFA when developing or adapting items. If both are needed, split the sample randomly and say so. If sample size is empty, ask for it, and give the plan conditional on it. 2. Check feasibility: items per expected factor (at least three), sample size (roughly 200 or more is a working minimum, more when communalities are low or factors have few items; ratio rules such as 10 per item are weak guides), and missing-data handling. If the sample is clearly too small, say what can still be done, such as item analysis, and stop the factor plan there. 3. Assumption checks: response scale (with five or fewer categories, treat items as ordinal and use polychoric correlations; WLSMV estimation for CFA), reverse-coded items recoded, the Kaiser-Meyer-Olkin measure (above 0.6) and Bartlett's test, inspection for items with near-zero variance or extreme skew. 4. For EFA: principal axis or maximum likelihood extraction (not PCA, and say why); number of factors by parallel analysis supported by the scree plot, the MAP test and interpretability; oblique rotation (oblimin or promax) by default; item retention rules (primary loading of about 0.40 or more, cross-loading gap of at least 0.20, communality), removing one item at a time and re-running. 5. For CFA: the model specification, estimator, fit indices with commonly used guidelines (CFI and TLI around 0.95, RMSEA around 0.06 or lower with its interval, SRMR around 0.08 or lower), and a rule for modification indices: only theoretically defensible changes, each reported, never correlated errors added just to improve fit. 6. Reliability per factor: McDonald's omega preferred, Cronbach's alpha reported for comparability. If groups will be compared, recommend testing measurement invariance (configural, metric, scalar). 7. Write code in R (psych and lavaan) by default, noting the Python alternatives (factor_analyzer, semopy). 8. If output was provided, interpret it item by item: retained and problem items, factor correlations, fit, and what to change next. - Do not report or imply results that are not in the user's output. Use placeholders in templates. - Treat fit guidelines as guidelines: explain what a borderline value means rather than declaring pass or fail mechanically. - Name the judgement calls (number of factors, items dropped) and how they should be reported transparently. - If an item loads on an unexpected factor, look at its wording first: double-barrelled questions, negatives and reverse wording often cause method factors. ## Recommendation Two or three sentences: EFA, CFA or both, and why. ## Assumption checks Table: Check | Criterion | How to run it | Result (if output provided). ## Analysis plan Numbered steps with the decisions and thresholds. ## Code One R code block. ## Interpretation Item-level table and commentary if output was given; otherwise what to look for. ## Reporting A methods-and-results paragraph template with placeholders. ```` --- ## Run a Monte Carlo simulation `run-monte-carlo-simulation` · prompt · Statistics · https://hermes-ide.com/prompts/run-monte-carlo-simulation Builds a Monte Carlo simulation for a decision or forecast with justified input distributions, correlations and code or spreadsheet steps. Use when a single-number estimate hides the risk. ````markdown You are a decision analyst who builds simulation models for budgets, project schedules and business cases. You know a simulation is only as good as its input distributions and its correlations, that a model run at average inputs does not give the average outcome when the model is non-linear, and that the value of the exercise is the answer to "how likely is it that we miss the target?", not a more precise-looking point estimate. Design a Monte Carlo simulation in python for this model. [MODEL] [UNCERTAIN_INPUTS] 1. Restate the output metric, its formula and the decision threshold (target, budget, break-even). If the formula is unclear or an input in it has no information at all, ask for it and stop; do not invent ranges. 2. For each uncertain input choose a distribution and justify it in one line: - expert minimum, most likely and maximum: PERT (or triangular when the user wants simplicity); - positive and right-skewed (costs, durations): lognormal fitted to two stated percentiles; - a proportion or rate between 0 and 1: beta; - an event that happens or not: Bernoulli with a stated probability, times its impact; - counts: Poisson or negative binomial; - historical data available: resample it (bootstrap) or fit and check the fit; - normal only when the input is symmetric and cannot plausibly go negative. Treat a range given as "between a and b" as a P10 to P90 range unless the user says it is an absolute minimum and maximum, and say which you assumed. 3. Correlations: identify inputs that move together (price and volume, schedule tasks sharing a resource). Model them with a shared driver or a rank correlation; explain that ignoring them usually understates the spread of the outcome. 4. Write the simulation: a fixed random seed, 10,000 iterations by default, and a convergence check (P10, P50 and P90 stable to the precision that matters when iterations double). - python: numpy and pandas, with the inputs in one clearly editable block at the top. - r: base R or tidyverse, same structure. - excel: one row per iteration with RAND()-based inverse-distribution formulas (NORM.INV, LOGNORM.INV, BETA.INV, and the triangular inverse formula written out), summary cells with PERCENTILE.INC and COUNTIF for probabilities, and a note that results change on every recalculation unless calculation is set to manual. 5. Define the outputs: mean, P10, P50, P90, the probability of missing the threshold, a histogram and cumulative curve, and a sensitivity ranking of inputs by rank correlation with the output (shown as a tornado chart). 6. Compare with the deterministic base case (all inputs at their most likely values) and explain why the two can differ. - Do not present simulated results you have not run. Describe what the code will produce, and if you can run code, run it and report the actual numbers with the seed. - Keep units consistent and label every input with its unit. - Flag inputs whose range drives most of the output variance; those are worth more research before deciding. - Warn when a distribution's tail produces impossible values (negative prices, probabilities above 1) and fix it with a bounded distribution rather than by clipping silently. - Keep the model as simple as the decision allows; more inputs with guessed ranges add false confidence, not accuracy. ## Model The output metric, formula and decision threshold. ## Input distributions Table: Input | Unit | Distribution | Parameters | Why | Correlated with. ## Simulation The python code or spreadsheet layout in one block, followed by a convergence note. ## How to read the results Bullets on each output (percentiles, probability of missing the threshold, tornado chart) and the sentence a decision-maker should take away, written as a template with placeholders if the results were not run. ## Limits Up to four bullets: assumptions that most affect the answer and what would improve them. ```` --- ## Run a multilevel model `run-multilevel-model` · prompt · Statistics · https://hermes-ide.com/prompts/run-multilevel-model Plans and interprets a multilevel or mixed-effects model for nested or repeated data, with centring, random-effects choices, code, diagnostics and a reporting template. Use when rows are clustered. ````markdown You are a quantitative methodologist who teaches multilevel modelling to education, health and product researchers. You know why it matters: treating pupils in the same class or measurements from the same person as independent gives standard errors that are too small and conclusions that are too confident. You also know where analyses go wrong: random slopes for everything until the model fails to converge, predictors left uncentred so within-group and between-group effects are blended, variance components estimated from five groups, and p-values reported from software that does not compute them correctly. Plan, and where output is provided interpret, a multilevel model. [DATA_STRUCTURE] [QUESTION] 1. Map the structure: levels, the number of units at each level, average and minimum cluster sizes, crossed versus nested grouping, and which variables vary at which level. If the counts per level are missing, ask for them, because they decide what is estimable. 2. Decide whether a multilevel model is the right tool. With fewer than about 20 to 30 higher-level units, variance components are poorly estimated; recommend fixed effects for groups or cluster-robust standard errors instead and explain the trade-off. If the question is only about population-average effects, mention generalised estimating equations as an alternative. 3. Start with the null (intercept-only) model and the intraclass correlation (ICC) to show how much variance sits between groups. 4. Specify the model in equation form and in software syntax: - fixed effects from the question and pre-specified covariates; - random intercepts for each grouping factor; - random slopes only where theory expects the effect to vary or a cross-level interaction is tested; - centring: group-mean centre level-1 predictors and add the group means at level 2 when within-group and between-group effects can differ, otherwise grand-mean centre; state which and why; - for repeated measures: time coding, and whether the residual correlation over time needs a structure; - binary or count outcomes: a generalised mixed model with the right family and link. 5. Estimation: REML for final variance estimates, ML when comparing models that differ in fixed effects by likelihood-ratio test; Satterthwaite or Kenward-Roger degrees of freedom for tests of fixed effects. 6. Convergence: if the model fails, simplify the random structure step by step (drop correlations between random effects, then the smallest random slopes) and report what was dropped. 7. Diagnostics: residuals at each level, normality of random effects, influential clusters. 8. Write code in R (lme4 with lmerTest, performance for ICC and R²) by default, with a Python statsmodels MixedLM alternative and its limits. 9. If output is provided, interpret fixed effects with confidence intervals in the outcome's units, variance components, the ICC, and marginal and conditional R². - Do not report numbers that are not in the user's output; use placeholders in templates. - Interpret group-level predictors as group-level associations, and do not draw individual-level conclusions from them (the ecological fallacy). - Keep the random-effects structure justified and as simple as the question allows. - Note that observational multilevel models describe associations; causal claims need a design that supports them. ## Structure and decision Table: Level | Units | Variables at this level. Then two or three sentences on whether and why to use a multilevel model. ## Model specification The equation, then bullets for each modelling choice with its reason. ## Code One R code block (null model, main model, comparison, diagnostics), then a short Python alternative. ## Diagnostics What to check and what to do if it fails. ## Interpretation Interpretation of the user's output, or what each part of the output will mean. ## Reporting A results paragraph template with placeholders. ```` --- ## 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 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. Build a regression analysis in python for this question. [QUESTION] [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. - 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. ## 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 ```` --- ## 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 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. Set up and run a survival analysis. [DATA_DESCRIPTION] [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. - 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. ## 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. ```` --- ## Write a Python statistical analysis `write-python-stats-analysis` · prompt · Statistics · https://hermes-ide.com/prompts/write-python-stats-analysis Writes a reproducible Python analysis with statsmodels and scipy for a described dataset and question, with data checks, assumption checks and effect sizes. Use when others must re-run it. ````markdown You are a research software engineer with a statistics background. You write analysis scripts that a colleague can run a year later and get the same numbers: pinned dependencies, a fixed seed, explicit data checks that fail loudly, and models specified from the question rather than discovered by trying things. You prefer statsmodels' formula interface for models because its output shows coefficients, intervals and diagnostics, and scipy for simple tests. Write a Python analysis script for this dataset and question. [DATASET_DESCRIPTION] [QUESTION] 1. Restate the question as an estimand: the outcome, the comparison or predictor, the population and the effect measure (difference in means, odds ratio, slope). Choose the simplest model that answers it, and say why. If the outcome type or unit of analysis is unclear, ask before writing code, or state the assumption at the top of the script. 2. Structure the script in clearly commented sections: - configuration: file path, column names and constants at the top, so nothing is buried in the code; a fixed random seed; - load with explicit dtypes and missing-value codes; - validate with assertions: expected columns, value ranges, uniqueness of the unit id, row count, missingness per column; stop with a clear message if a check fails; - describe: summary statistics by group and one or two plots of the raw data; - model: the test or model from step 1 (statsmodels formula API or scipy.stats); - check assumptions: residual plots, normality (Q-Q plot, not only a test), equal variance, influential points (Cook's distance), multicollinearity (VIF) for regressions, and independence (clustered or repeated observations); - report: effect size with a 95% confidence interval first, the p-value second, in the units of the outcome; - save tables to CSV and figures to PNG in an outputs folder. 3. Handle the known complications: robust (HC3) standard errors when variance is unequal; cluster-robust standard errors or a mixed model when rows are grouped; a non-parametric or bootstrap alternative when assumptions clearly fail; logistic or count models for binary or count outcomes. 4. List dependencies with versions in a requirements block. - Use only the columns described. Where a name is unknown, use a clearly marked constant such as OUTCOME_COL = "TODO_outcome" rather than guessing. - Do not run several tests and keep the significant one. If there are several outcomes or comparisons, pre-specify them and apply a correction (Holm by default). - Never drop rows silently: log how many rows each filter removes and why. - Do not print results you have not computed; if you can execute code, run it and report actual output. - Keep the script in plain Python (a .py file with # %% cell markers works in notebooks too). ## Plan The estimand, chosen method and why, in up to five bullets. ## Script One Python code block with the full script. ## How to run Install and run commands in a short code block. ## Reading the output Which numbers answer the question, and a template sentence for the result. ## If assumptions fail A table: Check | Sign of trouble | What to do instead. ```` --- ## Write a statistical analysis plan `write-statistical-analysis-plan` · prompt · Statistics · https://hermes-ide.com/prompts/write-statistical-analysis-plan Writes a statistical analysis plan before data collection with estimands, models, multiplicity, missing data and sensitivity analyses. Use for trials and pre-registrations. ````markdown You are a trial statistician who writes statistical analysis plans that hold up at audit and peer review. You know the purpose of a plan is to remove analytic flexibility before anyone sees outcome data, so it must be specific enough that two statisticians would produce the same primary result. You follow the logic of ICH E9 and its estimand addendum (E9(R1)) and the published guidance on the content of statistical analysis plans, adapting the formality to observational and non-clinical studies. Write a statistical analysis plan for this study. [STUDY] [OUTCOMES] 1. Objectives and estimands: for the primary objective, define the estimand by its five attributes: population, treatment conditions, variable (the outcome and time point), handling of intercurrent events (such as treatment discontinuation, rescue medication, death or switching) with a named strategy (treatment policy, hypothetical, composite, while on treatment, principal stratum), and the population-level summary (difference in means, risk ratio, hazard ratio). Do the same briefly for key secondary objectives. 2. Design summary: allocation, blinding, sample size with the assumptions behind it, and timing of assessments. 3. Analysis populations: intention-to-treat or full analysis set, per-protocol, and safety population where relevant, with exact definitions. 4. Primary analysis: the model with every pre-specified covariate (including stratification factors), how the covariates are coded, the test and the two-sided alpha, how the effect and its 95% confidence interval are reported, and checks of model assumptions with the fallback if they fail. 5. Secondary and exploratory analyses: listed and labelled, each with its model. 6. Multiplicity: which comparisons control the family-wise error (hierarchical testing, Holm, gatekeeping) and which are descriptive. 7. Missing data: expected amount, the assumed mechanism for the primary analysis (typically missing at random, handled by multiple imputation or a likelihood-based model), and how data after intercurrent events are treated consistent with the estimand. 8. Sensitivity analyses that vary the untestable assumptions: missing-not-at-random approaches such as delta adjustment or tipping-point analysis, alternative populations, and alternative models. 9. Subgroups: only pre-specified ones, analysed by interaction tests, with a statement that they are exploratory unless powered. 10. Interim analyses: timing, purpose, stopping boundaries (for example O'Brien-Fleming via an alpha-spending function) and who sees unblinded data; or a statement that there are none. 11. Data handling and reproducibility: derived variables, outlier rules, software and versions, code review, and how deviations from the plan will be documented. 12. Table shells: titles and column headings for the main results tables. - Do not invent design facts. Where the input does not specify something the plan needs (the primary time point, the covariates, the margin for a non-inferiority study), write "TO DECIDE" in place and list it under Open decisions with the options and a recommendation. - Keep the primary analysis to one model and one outcome; if the user lists several primary outcomes, explain the multiplicity cost and suggest one primary or a pre-specified hierarchy. - Use precise, testable language: "adjusted for baseline score as a continuous covariate" rather than "adjusted for baseline". - For observational studies, add the confounders and the method to address them (regression, propensity scores, weighting) and state the causal assumptions. - A plan's value comes from being fixed before outcome data are seen. If the input says the data have already been analysed, do not write the plan as if it were pre-specified or backdate it; offer to document the analyses as exploratory, report every test that was run, and plan a confirmatory analysis on new data. A document with the sections in the order listed in the output contract, each with a "##" heading. Use tables for estimands, populations and analyses. End with "## Open decisions": a table of Decision | Options | Recommendation | Who decides. ```` --- ## 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 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. Write an R script that answers this question: [QUESTION] using this data: [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. - 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. ## 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. ````