🇺🇸 English | 🇧🇷 Português (BR)
everyday-causal-skills
Did it actually work, or did you just get lucky?
Conversion jumped 12% the week you shipped the new checkout. Was it the checkout, the holiday traffic, or your competitor raising prices the same week? Until you can answer that question, you can't really say your change "worked."
This plugin gives your coding agent the workflow I use: pick the right method for the data you have, check the assumptions before you trust the answer, write the analysis in R or Python, and stress-test the result.
It's a causal inference plugin for AI agents, built as a companion to Everyday Causal Inference.
Works with: Claude Code · Gemini CLI · GitHub Copilot CLI · Codex CLI · Cursor
Built for: anyone who needs to make evidence-based decisions. Marketing and growth, product, BI, data science, revenue and ops, policy researchers, and students.
What you get from this plugin
The plugin works in five steps, from refining the question you want to answer, to writing the report. You are free to pick and start from any step you like.
→ Describe your problem
→ Get a method recommendation
→ Check assumptions and structure the analysis
→ Stress-test the results
→ Write the executive report
Example use case 1: Designing an A/B test
An e-commerce team redesigned their checkout page and wants to know if it increases conversion before rolling it out to everyone. They're not sure how long the test needs to run.
You: /causal-experiments We redesigned our checkout page and want to A/B test if it increases conversion. How long should we run the experiment?
The plugin asks a few follow-up questions in plain language: what's your current conversion rate, how many visitors do you get per week, and what's the smallest improvement that would make the redesign worth it. From your answers, it calculates the sample size and tells you how many weeks the test needs to run to detect that difference reliably.
Then it flags design decisions you might not have thought about — like whether to randomize by visitor or by session, and how to handle users who see both versions during the test.
You: We can randomize by visitor using a cookie. What about users who abandon and come back?
It walks you through those edge cases, writes the analysis code in R or Python, and builds in the checks you'll need: balance diagnostics to make sure the groups are comparable, and a pre-registered analysis plan so you're not fishing for results after the fact.
By the time you launch the test, the analysis is already written. When the data comes in, you run the code and get the answer.
Example use case 2: Measuring the impact of a loyalty program
A retail company rolled out a loyalty program in 12 of its 50 stores and wants to know if repeat purchases actually increased — or if the stores that got the program were already trending up.
You: /causal-planner We launched a loyalty program in 12 stores three months ago. The other 38 stores didn't get it yet. I want to know if repeat purchases increased because of the program.
The plugin asks about your data structure — how far back your records go, whether you chose the 12 stores or they were assigned somehow, and what outcome you're tracking. Based on your answers, it recommends difference-in-differences and explains why: you have treatment and control groups with data before and after the rollout.
You: /causal-did I have weekly repeat purchase rates for all 50 stores going back 18 months.
The skill checks whether the treated and untreated stores were following similar trends before the program launched — the key assumption that makes the method work. It writes the estimation code in R or Python, runs placebo and robustness checks, and flags problems before you waste time on results that won't hold up.
Once you have the estimate, /causal-auditor stress-tests the analysis: could something other than the program explain the difference? Were the 12 stores chosen in a way that biases the result? You get a list of threats to address before presenting the findings.
Skills
