From causal-powers
Use throughout the EXECUTION of any analysis — while running, debugging, modeling, or cleaning data — to decide which decisions you may make on your own and which you must STOP and bring to the user first. Forces a human-in-the-loop checkpoint before any consequential analytical choice — changing the research design, estimand, or identification strategy; deviating from the framed question or pre-analysis plan; dropping/filtering/winsorizing data or changing the sample; choosing between materially different specifications; redefining a metric; or changing any number the user has already seen. Use this whenever you catch yourself about to "just fix it", "upgrade the design", "drop the outliers", or otherwise decide something on the user's behalf — especially mid-debugging, where design changes get smuggled in as bug fixes.
How this skill is triggered — by the user, by Claude, or both
Slash command
/causal-powers:analysis-checkpointsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Autonomy is the point of a good analysis loop — and also its biggest hazard. You can iterate fast toward a goal, but the same momentum that makes you productive makes you redefine the goal mid-flight without noticing: a debugging session quietly becomes a redesign, an outlier "obviously" gets dropped, a near-vs-far DiD silently becomes a triple-difference. Each step felt like progress. Collecti...
Autonomy is the point of a good analysis loop — and also its biggest hazard. You can iterate fast toward a goal, but the same momentum that makes you productive makes you redefine the goal mid-flight without noticing: a debugging session quietly becomes a redesign, an outlier "obviously" gets dropped, a near-vs-far DiD silently becomes a triple-difference. Each step felt like progress. Collectively, the user got an analysis they never agreed to.
Core principle: Loop autonomously toward the agreed goal. Never redefine the goal — the design, the sample, the spec, the estimand, the metric — behind the user's back. When execution wants to change any of those, that is a checkpoint, not a task: stop, surface it, and let the user decide.
This is the execution-time form of "Think Before Coding": don't decide silently, surface the tradeoff. The up-front skills (question-framing, pre-analysis-plan) establish the agreed goal; this skill protects it while the work runs.
The test is simple — does this change what is being estimated, on what data, or a number the user has already seen? If yes, it's the user's call. Run this one question on every decision you're about to make; the two lists below are just worked examples of "yes" (STOP) and "no" (proceed and report).
structural-estimation).executing-analysis-plans).analysis-craft.)The dividing question between a fix and a redesign: "Am I restoring the analysis we agreed on, or changing it?" Restoring → proceed and report. Changing → checkpoint.
When you hit one, stop and present — don't implement past it:
If you cannot reach the user (a batch, cron, or otherwise non-interactive run), a deadlock is wrong but so is deciding for them: stop at the last validated state, do NOT implement the checkpoint-class change, and return the options + your recommendation as the deliverable for a human to resolve. Surfacing the decision unresolved is the correct output, not a failure.
Worked example (the kind that should always stop):
While debugging the high near-clinic effect I found the 2016 citywide recording jump is geographically uneven — Beverly's 2 mi ring is +66% in 2016 while its 0.5 mi ring is flat. A plain near-vs-far DiD would misread this as an acquisition effect. Options: (a) upgrade Design B to a triple-difference (add band×month FE to absorb the citywide near-vs-far differential) — most robust, but changes the pre-registered design; (b) keep Design B and add the differential as a documented caveat; (c) restrict to cities without the uneven jump. My recommendation: (a), because it directly removes the confound — but it's a deviation from the PAP, so it's your call.
That stops before the band×month FE is written. The earlier behavior — writing the triple-difference and presenting it as "the fix" — is what this skill exists to prevent.
Goal-driven autonomy (from analysis-craft / the gateway) means: iterate freely toward fixed, agreed success criteria, and don't stop at "the code ran." It does not authorize changing the criteria, the design, or the sample to reach a result. If hitting the goal seems to require changing the goal, that's the loudest possible checkpoint — stop and say so.
| Excuse | Reality |
|---|---|
| "It's clearly the right fix, I'll just do it." | If it changes the design or sample, "right" is the user's judgment to make. Surfacing it costs a paragraph; the wrong silent change costs their trust in every number. |
| "I'm just fixing a bug." | Restoring the agreed computation is a fix. Changing what's estimated is a redesign wearing a bug's clothes. Ask which one it is. |
| "I'll show them the redesigned version, that's clearer." | Then they're reviewing a fait accompli, not deciding. Present the options before you build one. |
| "Stopping breaks my flow." | Your flow is not the goal. An analysis the user didn't authorize is rework at best and a wrong decision at worst. |
| "Looping until verified means I keep going." | Toward the agreed goal — yes. By changing the goal — no. That's the line. |
A checkpoint is a STOP-and-ask gate, not a place to keep working. It is the gate the whole discipline routes INTO — so its job is to return the decision to the user, then propel into exactly one skill to absorb that decision before you resume what you interrupted:
digraph analysis_checkpoints_next {
"User decided?" [shape=diamond];
"Change is to the framed question / estimand?" [shape=diamond];
"invoke question-framing — re-frame, then re-derive the plan" [shape=box style=filled fillcolor=lightgreen];
"invoke pre-analysis-plan — record the deviation, re-lock" [shape=box style=filled fillcolor=lightgreen];
"WAIT — present options + recommendation, do not implement" [shape=box style=filled fillcolor=lightyellow];
"User decided?" -> "WAIT — present options + recommendation, do not implement" [label="no"];
"User decided?" -> "Change is to the framed question / estimand?" [label="yes — approved"];
"Change is to the framed question / estimand?" -> "invoke question-framing — re-frame, then re-derive the plan" [label="yes"];
"Change is to the framed question / estimand?" -> "invoke pre-analysis-plan — record the deviation, re-lock" [label="no — deviation from the locked PAP"];
}
question-framing to re-frame, then re-derive the brief.pre-analysis-plan to record the deviation and re-lock before any further estimation.wrong-number-debugging, executing-analysis-plans, structural-estimation) and continue from the now-approved state — never resume on the silent change.## The bottom lineExecuting well → loop autonomously toward the agreed goal; stop and ask before changing the design, sample, spec, estimand, or any number already seen
Otherwise → an analysis the user never agreed to, assembled one reasonable-looking step at a time
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.