菜单
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