Agent Skills
› brycewang-stanford/Awesome-Journal-Skills
› ors-data-analysis
ors-data-analysis
GitHub用于运筹学论文的计算实验与可复现性工作。涵盖基准测试设计、随机结果统计处理及ORJournal代码数据提交流程，提供数值证据以支持方法有效性，但不涉及理论证明或图表制作。
Trigger Scenarios
需要数值证据证明算法有效性和扩展性
准备ORJournal期刊的代码和数据复现审查材料
对随机输出进行统计分析以确保结果可信
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill ors-data-analysis -g -y
SKILL.md
Frontmatter
{
"name": "ors-data-analysis",
"description": "Use when running and reporting the computational study for an Operations Research (OR) manuscript — benchmark instances, baselines, reproducible experiments, statistical care for stochastic output, and the ORJournal code-and-data reproducibility workflow. Executes and reports the numerical evidence; it does not prove the results (ors-methods) or lay out the exhibits (ors-tables-figures)."
}
Computational Study & Reproducibility (ors-data-analysis)
When to trigger
- Theory is in place and you need numerical evidence that the method works and scales.
- You must benchmark against credible baselines on standard instances.
- You are preparing the code/data deposit for the ORJournal reproducibility review.
Design a defensible computational study
Operations Research judges computation as evidence supporting a methodological claim, not as the contribution by itself. Make it convincing:
- Instances: use recognized benchmark libraries (e.g., MIPLIB, TSPLIB, DIMACS, QPLIB) plus, where relevant, instances from the motivating application; report sizes and characteristics so difficulty is visible.
- Baselines: compare against the closest prior methods and a strong off-the-shelf
solver, not a weak strawman. Tie experiments to the claims in
ors-literature-positioning. - Metrics: report what the theory predicts — optimality gap, solution time, iterations/oracle calls, scaling with size, and where relevant the quality at a fixed budget. Show how empirics corroborate proved bounds/rates.
- Reporting: specify hardware, solver versions, time limits, and termination criteria. State which configuration produced each table.
Statistical care for stochastic output
Where output is random (simulation, randomized algorithms, learning-driven OR):
- Report confidence intervals, not point estimates, with the procedure (replications, batch means, regenerative) and the number of replications.
- Use common random numbers for paired comparisons and report the paired analysis.
- For ranking/selection or sim-opt, report the statistical guarantee and the budget.
- Average over multiple seeds; report dispersion, and fix seeds for reproducibility.
The ORJournal code-and-data workflow (mandatory where applicable)
For papers with algorithmic or empirical components, Operations Research expects all code, scripts, and data with instructions sufficient to reproduce the results. Materials are deposited in the journal's ORJournal GitHub organization and reviewed through a pull-request process:
- Provide a README and LICENSE and follow the prescribed directory structure.
- Document hardware, software, data, installation, and run steps; pin versions and seeds so every table/figure regenerates exactly from raw inputs.
- Separate data preparation from experiments; one command per reported result where possible.
- If data are confidential/licensed/non-public, or the paper is purely methodological, request an exemption with rationale in the cover letter (Area Editor decides, EiC final).
- Retain raw data sufficient to support verification/replication if the editors ask.
Execution bridge (StatsPAI / Stata MCP)
Run the battery, don't just enumerate it. Full map:
execution-with-mcp. Operations Research is predominantly analytical / optimization / stochastic modeling; use the chain below only for its empirical/causal papers — modeling, optimization, and simulation are outside this causal-inference toolchain.
- Many outcomes / specifications:
romano_wolf(step-down FWER) orbenjamini_hochberg— report the adjusted threshold. - OVB sensitivity:
oster_delta/sensemakr. - Inference:
wild_cluster_bootstrap(few clusters),twoway_cluster/conley; multilevel data → cluster at the right level. - Re-fit off one handle:
audit_result(result_id)lists the missing checks and the exactsuggest_functionfor each. - Exhibits:
etable/did_summary_to_latexfrom the handle — no retyped numbers.
Keep the decisive checks in the body and the exhaustive battery in the appendix. See the executed chain in the JF execution walkthrough.
Anti-patterns
- Cherry-picked instances or a tuned method vs. a default-config baseline.
- Reporting means of stochastic runs with no confidence intervals or seeds.
- Unspecified hardware/solver/time-limit, making results irreproducible.
- Treating the computational section as the contribution when the theory is thin.
- Planning to "share code on request" instead of using the ORJournal deposit.
Output format
【Instances】benchmark + application; sizes reported
【Baselines】closest prior + strong solver (no strawman)
【Metrics】gap / time / scaling; corroborates proved bounds?
【Stochastic care】CIs, CRN, seeds, replications ...
【Reproducibility】ORJournal repo: README/LICENSE/structure; exemption?
【Next step】ors-tables-figures
Version History
- 1839142 Current 2026-07-05 14:07
