メニュー
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
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
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 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
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
SOC 職業分類に基づく
| name | ds-requesting-analysis-review |
| description | 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 |
Ask for review before the conclusion hardens into a decision. The reviewer should challenge methodology, not just style.
Request review before publishing, socializing, or escalating a result. After review, use ds-receiving-analysis-review to process feedback rigorously.
Dispatch an analysis-reviewer subagent to catch methodological errors before they become business decisions.
Core principle: Review the work that can change decisions. Do not turn light exploratory tasks into review-heavy process by default.
Mandatory:
standard or strict tasks in ds-subagent-driven-analysis that affect final conclusionsOptional but valuable:
light task if a risk signal appears: unit mismatch, denominator drift, SRM, invariant failure, stale cache, leakage risk, or narrative/output disagreementProvide:
1. Gather the review package
{WHAT_WAS_ANALYZED} - what was produced{PLAN_OR_REQUIREMENTS} - plan section, design doc, or task requirements{DESCRIPTION} - brief summary of the result{NOTEBOOK_PATH} - notebook or script path{QUERY_REFERENCE} - SQL path or query reference{ARTIFACT_REFERENCE} - output tables, figures, exports2. Dispatch analysis-reviewer subagent
Use the template at analysis-reviewer.md
3. Act on feedback
See template at: ds-requesting-analysis-review/analysis-reviewer.md