メニュー
Use when notebook results depend on parameters, caches, run order, hidden state, seeds, external helper code, or exported tables and the analysis must be rerunnable by another analyst
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when a research question spans multiple SQL, pandas, or notebook steps and you need explicit cohorts, windows, metrics, validation checks, outputs, and statistical methods before touching queries or cells
Use when you already have a written analysis plan and want to execute SQL, notebook, or validation tasks in a separate session with review checkpoints and rerun-based evidence between batches
Use when a metric definition, denominator, CUPED covariate, linearization choice, invariant, outlier treatment, missingness pattern, or leakage risk may distort an experiment or validation readout
Use when creating, editing, reviewing, or finalizing analytical notebooks whose code, assumptions, transformations, diagnostics, or conclusions need to be understandable to another analyst
Use when an experiment analysis, metric study, notebook investigation, or methodology proposal is close to decision-ready and you need an independent check of design, statistics, interpretation, and reproducibility
Use when executing a written analysis plan in the current session and tasks are mostly independent across SQL extracts, notebook sections, metric validations, robustness checks, or memo sections
| name | ds-notebook-reproducibility |
| description | Use when notebook results depend on parameters, caches, run order, hidden state, seeds, external helper code, or exported tables and the analysis must be rerunnable by another analyst |
A notebook is trustworthy only when another analyst can rerun it and get the same result or understand exactly why not.
The default reproducible form for analytical notebook work is one self-contained notebook with explicit parameters and notebook-local one-off logic.
Notebook must optimize for analyst readability. Prefer diagnostic outputs over interleaved assertions. Use runtime exceptions only for true prerequisites or one final strict-validation pass.
Use this before ds-verification-before-completion if reruns are fragile or outputs depend on stale notebook state.
Apply the shared validation budget from ds-using-superpowers. Reproducibility work should remove hidden state and stale outputs, not add a large validation framework to the notebook.
tqdm only when it updates in place in the notebook environment; otherwise use concise stage, timing, row-count, or percentage checkpoints.py modules only for real cross-project reuse, production needs, or another explicit technical reasontqdm bars when they create many saved output lines. For large inner loops, prefer one outer bar plus sparse checkpoints, or set coarse mininterval/miniters, leave=False, or disable=True for inner bars.