From causal-powers
Use when reviewing a data analysis, notebook, script, model, or result — your own before you ship it, a colleague's before it's published, or one handed to you to "check" or "sanity-check" — in R, Julia, or Python. Hunts specifically for the silent-failure classes that pass code review but produce wrong answers — unchecked joins, leakage, fished specifications, unreconciled totals, undefined metrics, identification gaps, and structural-model failures (non-identified parameters, no recovery test, counterfactuals with prices held fixed). Use when the user says "review this analysis", "can you check my notebook", "does this look right", "sanity-check these numbers", "before I send this", or is about to accept someone else's analytical result. Also use when receiving review feedback on your own analysis, to verify the critique rather than reflexively agreeing.
How this skill is triggered — by the user, by Claude, or both
Slash command
/causal-powers:analysis-reviewThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Code review asks "is this code correct?" Analysis review asks a harder question: "is this *conclusion* correct?" — and the two come apart completely. Analytics code can be clean, idiomatic, well-tested, and pass any software review while delivering a confidently wrong number, because the bugs that matter here don't live in the syntax. They live in a join that fanned out, a metric nobody defined...
Code review asks "is this code correct?" Analysis review asks a harder question: "is this conclusion correct?" — and the two come apart completely. Analytics code can be clean, idiomatic, well-tested, and pass any software review while delivering a confidently wrong number, because the bugs that matter here don't live in the syntax. They live in a join that fanned out, a metric nobody defined, a feature that leaked the target, a specification that was fished. This skill is a review lens aimed at exactly those.
Core principle: Review the path from data to claim, not just the code. The question is never "does it run?" — it's "would I bet the decision on this number?"
"Review it" re-fires this skill every time — including mid-session. A design you reviewed last week, or earlier in this conversation, doesn't stay reviewed: a new cut, a re-run, or a fresh "does this look right?" is a new artifact to review from scratch. Don't answer from loaded context ("I already looked at this") — re-run the checklist against this result.
Work down from the conclusion to the data. Each item is a class of silent error that survives ordinary code review:
The claim
question-framing.)The data path
NA/missing rows and bias the result? How is missing data handled, and was that decided by rule or by eye?Models & causal claims
causal-identification — parallel trends, first-stage F, manipulation test, balance.)pre-analysis-plan.)structural-estimation.)Reproducibility
For a genuinely independent pass — especially before results ship, or in parallel
with the work itself — dispatch the analysis-reviewer agent that Causal
Powers ships. A reviewer with fresh context catches what the author (you)
rationalized; it returns concrete findings with severity rather than a
rubber stamp. Use it in addition to, not instead of, reviewing as you go.
The useful question isn't "can I follow this?" — it's "how would this be wrong, and what would I check to find out?" For each headline number, form the specific failure hypothesis (this total looks high → maybe the join fanned out) and ask for the evidence that rules it out (show me the row counts). A review that only confirms the code is readable has reviewed the wrong thing. If you can't see the intermediate checks, the right response is "show me the reconciliation," not "looks good."
If you're the author, make the analysis reviewable:
question-framing brief).A review of a polished output with no visible checks can only catch typos. Hand over the checks.
When someone critiques your analysis, the failure mode is reflexive agreement: "good catch, fixing now" to a critique you haven't verified. That's as bad as reflexive defense. The discipline is to check the claim against the data:
| Excuse | Reality |
|---|---|
| "The code is clean, so the analysis is fine." | Clean code computes the wrong thing just as reliably as messy code. Review the data path. |
| "I trust the author, they're careful." | Careful people fan out joins too. The check costs a minute; trust isn't a row-count. |
| "It's just an internal review, ship it." | The internal number drives the decision. Internal is exactly when nobody else will catch it. |
| "They flagged it, so it must be wrong — fixing." | Maybe. Verify it against the data first; agreeing without checking can introduce a new bug. |
| "There's no time to ask for the intermediate checks." | Then there's no time to know whether the number is real. Reviewing only the output is reviewing nothing. |
Review is not terminal and it does not end at "looks good / here are my notes." It is the silent-failure sweep result-verification dispatches before shipping — every finding propels into a fixing skill. Route imperatively on what the review surfaced:
digraph analysis_review_next {
"Review surfaced a wrong number / data-integrity failure?" [shape=diamond];
"invoke wrong-number-debugging — bisect the pipeline to the bad step" [shape=box style=filled fillcolor=lightgreen];
"Review surfaced a design issue? (identification gap / spec search / misspecification)" [shape=diamond];
"invoke analysis-checkpoints — route the design decision to the user" [shape=box style=filled fillcolor=lightgreen];
"Clean — return to result-verification to ship" [shape=box style=filled fillcolor=lightgreen];
"Review surfaced a wrong number / data-integrity failure?" -> "invoke wrong-number-debugging — bisect the pipeline to the bad step" [label="yes"];
"Review surfaced a wrong number / data-integrity failure?" -> "Review surfaced a design issue? (identification gap / spec search / misspecification)" [label="no"];
"Review surfaced a design issue? (identification gap / spec search / misspecification)" -> "invoke analysis-checkpoints — route the design decision to the user" [label="yes"];
"Review surfaced a design issue? (identification gap / spec search / misspecification)" -> "Clean — return to result-verification to ship" [label="no"];
}
wrong-number-debugging to bisect to the bad step.analysis-checkpoints to route the decision to the user (it in turn hands to causal-identification, pre-analysis-plan, or structural-estimation).docs/LESSONS.md (symptom, cause, the check that would have caught it; create the file if absent). A review that only fixes this artifact fixes one artifact; the logged pattern hardens every future one (result-verification → "Capture what bit you").result-verification to ship.Reviewed analysis → metric defined, joins checked, totals reconciled, leakage ruled out, identification stated, reproduces clean
Otherwise → you reviewed the spelling, not the answer
npx claudepluginhub lancegui/causal-powers --plugin causal-powersProvides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Searches MemPalace before answering questions about past work, people, projects, or prior decisions. Returns verbatim stored content instead of guessing from model memory.