---

name: challenge description: Stress-test a finding against the choices you did not make. Enumerates the discrete forks a competent analyst could have taken (measure definition, sample filter, control set, clustering level, weighting, functional form), runs the specification grid, and reports the distribution rather than a point estimate — then attacks the identifying assumption with named, computable sensitivity statistics. Use when the user says "is this robust", "challenge this result", "specification curve", "multiverse", "how sensitive is this", "what if I'd used a different measure", "stress-test my estimate", or before a result becomes a headline claim. NOT a reviewer of prose or code — it challenges the CLAIM. argument-hint: "[script or results file] [--forks N] [--dry-run]" allowed-tools: ["Read", "Grep", "Glob", "Bash", "Write", "Edit", "Agent", "Task"] disable-model-invocation: true metadata: protocol: threat-prioritization

Challenge — does the result survive the choices you didn't make?

A single specification is one draw from a distribution you never looked at.

Why this exists, measured rather than asserted. In a controlled study, 150 autonomous agents were given the same data and the same questions. Effect-size interquartile ranges reached ~10.7 %/yr, and the spread concentrated in discrete measure-choice forks — not in estimation noise. Within a measure family, agents agreed to ~0.25 %/yr. Two findings from that study shape this skill:

• AI peer review left the spread essentially unchanged. Review catches errors; it does not reduce analytical-choice variance. A clean referee report is not robustness.
• Exposure to exemplar papers collapsed the spread by 80–99 % — convergence by imitation, not by correctness. Herding is not agreement.

So the spread has to be measured, not reviewed away.

Preconditions

• A working baseline specification that runs and produces the headline estimate.
• The estimate's estimand stated in words — "the ATT for units treated in 2015, over 2013–2019, on the treated population". If you cannot state it, stop: you cannot challenge a claim you have not defined.
• A fork budget (--forks, default 64). Grid size is the product of your choices; it grows faster than intuition.

Step 1 — Enumerate the forks, before running anything

List every point where a competent, honest analyst could have chosen differently. Do this before seeing any alternative result, and write it down — the list is the pre-registration of the challenge.

Fork	Typical alternatives
Measure definition	level vs rate vs share; dollar vs count; stock vs flow
Sample filter	balanced vs unbalanced; trimming rules; inclusion windows
Control set	none / baseline / baseline+trends / interacted
Clustering level	unit / treatment-assignment / two-way
Weighting	unweighted / population / inverse-propensity
Functional form	levels / logs / IHS / Poisson
Winsorization	none / 1% / 5%

Some forks change the estimand, not just the estimate — averaging over them is meaningless. references/fork-catalog.md labels every fork; record estimand forks separately and say so in the report.

Ship --dry-run first. Print the grid size and an estimated runtime before executing anything. A 6-fork grid with 3 options each is 729 fits.

Step 2 — Run the grid

One fit per cell, same seed, same data build. Persist every cell — including failures. A specification that does not converge is information about fragility, not a cell to drop.

Record per cell: the fork coordinates, the point estimate, the standard error, N, and the convergence status.

Step 3 — Report the distribution, not the winner

• Specification curve: estimates sorted, with the fork coordinates shown underneath so a reader can see which choices move the result.
• The share of specifications with the same sign, and the share significant at conventional levels. Report both; they answer different questions.
• Which fork drives the spread. This is the payload. "The result is robust except to the choice between dollar and share volume" is a far more useful sentence than a robustness paragraph.
• Your baseline's percentile in its own distribution. If the headline sits at the 97th percentile of specifications you yourself called defensible, say so.

The descriptive curve is not a test — read it as a description of fragility. If you need inference over the whole curve, use specification-curve analysis's joint permutation test (Simonsohn, Simmons & Nelson 2020), which supplies the sharp null the picture alone lacks.

Step 4 — Attack the identifying assumption

The grid varies what you can vary. The identifying assumption is what you cannot test — so bound it instead, with a named, computable statistic. See references/sensitivity-statistics.md.

Concern	Statistic
Unobserved confounding	E-value; Cinelli–Hazlett robustness value
Selection on observables → unobservables	Oster δ (with a stated R²max)

Rows for the causal-identification designs are deliberately absent (unvetted-methods veto): populate them from your field's canonical sources after vetting.

Label every statistic executable-here or describe-and-cite. Honesty about what your environment can actually run is itself a verification step; a cited-but-unrun statistic is not evidence.

Step 5 — Placebo and falsification

Where a falsification test exists, run it: a negative-control outcome that should show nothing, a negative-control exposure, a timing placebo. A passed placebo is weak positive evidence; a failed placebo is strong negative evidence. Report both with equal prominence.

Step 6 — Write the ledger entry

Append to the specification-search ledger (verification-ladder.md rung 5): the fork list, the grid size, the distribution summary, which forks moved the result, the sensitivity statistics with their values, and every attempt including the failures.

Pre-commit the interpretation. Before running the grid, write down what result would SUPPORT and what would WEAKEN the claim. The ledger is the arbiter. A robustness exercise interpreted after the fact is not a robustness exercise.

Anti-patterns

• Running until something interesting appears. That is the pathology this skill exists to prevent. Fixed fork list, fixed budget, stated stopping rule.
• Reporting only the specifications that agree — a curve showing only supporting cells is a fishing expedition with better graphics.
• Treating a wide curve as failure. Wide is a finding. Publish it and say what drives it.
• Adding forks nobody would defend to pad the denominator and dilute the fragile cells.

Reference files

File	Read when
references/sensitivity-statistics.md	a challenge rests on an untestable identifying assumption and needs a computable bound
references/fork-catalog.md	enumerating forks for a design you have not challenged before

Cross-references

• verification-ladder.md — rung 4 (analytic verification) and rung 5 (the ledger)
• /simulation-study — when the question is finite-sample performance, not robustness
• /preregister — reserve a holdout before the search, not after