Answer a Statistics Question With a Defensible R Script
Get a complete R script with assumption checks, effect sizes and plain-language printed conclusions a non-statistician can read.
You are a statistician-programmer who writes R scripts that answer a stated question defensibly — assumptions checked, output readable by a non-statistician.
<context>
[THE QUESTION — in plain words — e.g. "did the new opening hours change average daily sales?"]
[MY DATA — paste str() or head() output, or describe: columns, types, example values, row count, and what one row represents]
[THE ANALYSIS I THINK I NEED — e.g. "a t-test?", or "you choose"]
[R SETUP — e.g. "base R only", "tidyverse is fine", "RStudio"]
[AUDIENCE FOR THE RESULTS — e.g. "just me", "my business partner who hates stats"]
</context>
Before writing code, check the analysis actually fits: does my suggested method suit the question and the data's structure (paired versus independent, counts versus continuous, one row per day versus per transaction)? If my suggestion misfits, say so in two lines and use the right method — the script must answer the QUESTION, not perform the requested ritual.
<task>
1. Write the complete script in commented sections: setup (packages per my stated constraint), import with explicit types, cleaning limited to what the analysis needs (every exclusion counted and printed), an exploratory summary (the 2-3 tables or plots that show the data's shape before any test), assumption checks for the chosen method — named, run, and interpreted in comments, with the fallback method coded to trigger if a check fails — then the analysis and results.
2. Make the output self-explaining: print statements that state findings as sentences with the numbers filled in ("Average daily sales after the change: $X vs $Y before; difference $Z, 95% CI ..."), pitched at [AUDIENCE].
3. Report effect size and uncertainty, not just a p-value — plus one comment line on what the p-value does and doesn't mean here.
4. Print a caveats block with the results: the 2-3 threats to validity specific to MY setup (seasonality across the window, other changes at the same time) — reminders, not disclaimers.
5. End the script with a plain-language conclusion template the numbers flow into, and what evidence would strengthen it (a longer window, more data).
</task>
<output_format>
Two lines on method fit, then one complete R script (runnable top to bottom once the file path is set), then a 4-line guide to reading the output.
</output_format>
Rules:
- Use only variables from my data description; missing essentials become [NEEDED: ...] at the top, never guessed columns.
- Respect my package constraint exactly; anything version-sensitive gets [VERIFY: ...].
- Never overclaim: printed conclusions carry their uncertainty, and causal language is off-limits unless my design supports it — say which it is.
Copy the block above straight into Claude — anything in [BRACKETS] is yours to fill in.
Want it tuned to your business? Bring it to the free weekly call and we'll adapt it live.
Join the free callMore coding & technical prompts
Keep a Two-Minute Daily Engineering Log That Pays Off Later
Turn end-of-day scraps into a structured log entry — decisions with their why, lessons, blockers — capped at 120 words and searchable months later.
Break a Stalled Decision With a Structured Tiebreak
Lay out the options, score them against your own criteria, price the delay, and get a verdict with a 48-hour commitment step — plus what would legitimately reopen it.
Engineer a Distraction-Proof Deep-Work Block
Set up a recurring focus block matched to your energy and team reality — device rules, a status script, an interruption protocol and a two-week bedding-in plan.