Modeling Discovery

Workflow 1: 建模方案发现流水线

Orchestrate a complete modeling discovery workflow for: $ARGUMENTS

Overview

This skill chains sub-skills into a single automated pipeline:

/problem-analysis → /model-creator → /feasibility-check → /model-review → /model-refine-pipeline
  (survey)      (brainstorm)    (verify novel)    (critical feedback)  (refine method + plan experiments)

Each phase builds on the previous one's output. The final deliverables are a validated MODEL_REPORT.md with ranked 建模方案, plus a refined proposal (refine-logs/FINAL_PROPOSAL.md) and experiment plan (refine-logs/SOLVE_PLAN.md) for the top 建模方案.

Constants

• VERIFY_MAX_MINUTES = 15 — Skip any 快速验证 estimated to take > 15 minutes locally. Flag as "needs manual 验证" in the report.
• VERIFY_TIMEOUT_MINUTES = 20 — Hard timeout: kill any running 验证 that exceeds 20 minutes. Collect partial results if available.
• MAX_VERIFY_APPROACHES = 3 — Run 验证s for at most 3 top approaches in parallel. Additional 建模方案 are validated on paper only.
• MAX_TOTAL_COMPUTE_MINUTES = 60 — Total compute budget across all 验证s. If exceeded, skip remaining 验证s and note in report.
• AUTO_PROCEED = true — If user doesn't respond at a checkpoint, automatically proceed with the best option after presenting results. Set to false to always wait for explicit user confirmation.
• REVIEWER_MODEL = gpt-5.4 — Model used via Codex MCP. Must be an OpenAI model (e.g., gpt-5.4, o3, gpt-4o). Passed to sub-skills.
• METHOD_SEARCH_DEPTH = standard — When true, /problem-analysis downloads the top relevant 参考资料 during Phase 1. When false (default), only fetches metadata. Passed through to /problem-analysis.
• COMPACT = false — When true, generate compact summary files for short-context models and session recovery. Writes MODEL_CANDIDATES.md (top 3-5 建模方案 only) at the end of this workflow. Downstream skills read this instead of the full MODEL_REPORT.md.
• REF_METHOD = false — 参考方法 to base 建模方案 on. Accepts: local PDF path, 方法参考链接, or any paper URL. When set, the paper is summarized first (REF_METHOD_SUMMARY.md), then 建模方案 generation uses it as context. Combine with base repo for "improve this paper with this codebase" workflows.

💡 These are defaults. Override by telling the skill, e.g., /modeling-discovery "topic" — ref method: https://method-search.org/abs/2406.04329 or /modeling-discovery "topic" — compact: true.

Pipeline

Phase 0: Load 赛题描述 (if available)

Before starting any other phase, check for a detailed 赛题描述 in the project:

1. Look for PROBLEM_BRIEF.md in the project root (or path passed as $ARGUMENTS)
2. If found, read it and extract:
   • Problem statement and context
   • Constraints (compute, data, timeline, venue)
   • What the user already tried / what didn't work
   • Domain knowledge and non-goals
   • Existing results (if any)
3. Use this as the primary context for all subsequent phases — it replaces the one-line prompt
4. If both PROBLEM_BRIEF.md and a one-line $ARGUMENTS exist, merge them (brief takes priority for details, argument sets the direction)

If no brief exists, proceed normally with $ARGUMENTS as the 赛题描述.

💡 Create a brief from the template: cp templates/PROBLEM_BRIEF_TEMPLATE.md PROBLEM_BRIEF.md

Phase 0.5: 参考方法概要 (when REF_METHOD is set)

Skip entirely if REF_METHOD is false.

Summarize the 参考方法 before searching the 参考资料:

1. If 方法参考链接 (e.g., https://method-search.org/abs/2406.04329):

   • Invoke /method-search "ARXIV_ID" — download to fetch the PDF
   • Read the first 5 pages (title, abstract, intro, method overview)

2. If local PDF path (e.g., papers/reference.pdf):

   • Read the PDF directly (first 5 pages)

3. If other URL:

   • Fetch and extract content via WebFetch

4. Generate REF_METHOD_SUMMARY.md:

# 参考方法概要

**Title**: [paper title]
**Authors**: [authors]
**Venue**: [venue, year]

## What They Did
[2-3 sentences: core method and contribution]

## Key Results
[Main quantitative findings]

## Limitations & Open Questions
[What the paper didn't solve, acknowledged weaknesses, future work suggestions]

## Potential Improvement Directions
[Based on the limitations, what could be improved or extended?]

## Codebase
[If `base repo` is also set: link to the repo and note which parts correspond to the paper]

🚦 Checkpoint: Present the summary to the user:

📄 参考方法 summarized:
- Title: [title]
- Key limitation: [main gap]
- Improvement directions: [2-3 bullets]

Proceeding to 赛题分析 with this as context.

Phase 1 and Phase 2 will use REF_METHOD_SUMMARY.md as additional context — /problem-analysis searches for related and competing work, /model-creator generates 建模方案 that build on or improve the 参考方法.

Phase 1: 赛题分析与方法检索

Invoke /problem-analysis to map the 方法地图:

/problem-analysis "$ARGUMENTS"

What this does:

• Search 数模优秀论文库, CNKI, 经典教材 for recent papers
• Build a landscape map: sub-directions, approaches, open problems
• Identify structural gaps and recurring limitations
• Output a 参考资料 summary (saved to working notes)

🚦 Checkpoint: Present the landscape summary to the user. Ask:

📚 Literature survey complete. Here's what I found:
- [key findings, gaps, open problems]

Does this match your understanding? Should I adjust the scope before generating 建模方案?
(If no response, I'll proceed with the top-ranked direction.)

• User approves (or no response + AUTO_PROCEED=true) → proceed to Phase 2 with best direction.
• User requests changes (e.g., "focus more on X", "ignore Y", "too broad") → refine the search with updated queries, re-run /problem-analysis with adjusted scope, and present again. Repeat until the user is satisfied.

Phase 2: 建模方案 Generation + Filtering + 验证s

Invoke /model-creator with the landscape context (and REF_METHOD_SUMMARY.md if available):

/model-creator "$ARGUMENTS"

What this does:

• If REF_METHOD_SUMMARY.md exists, include it as context — 建模方案 should build on, improve, or extend the 参考方法
• Brainstorm 8-12 concrete 建模方案 via GPT-5.4 xhigh
• Filter by feasibility, compute cost, quick 可行性 search
• Deep validate top 建模方案 (full 可行性检查 + devil's advocate)
• Run parallel 快速验证s on available 本地计算 (top 2-3 建模方案)
• Rank by empirical signal
• Output MODEL_REPORT.md

🚦 Checkpoint: Present MODEL_REPORT.md ranked 建模方案 to the user. Ask:

💡 Generated X 建模方案, filtered to Y, 验证ed Z. Top results:

1. [建模方案 1] — 验证: POSITIVE (+X%)
2. [建模方案 2] — 验证: WEAK POSITIVE (+Y%)
3. [建模方案 3] — 验证: NEGATIVE, eliminated

Which 建模方案 should I validate further? Or should I regenerate with different constraints?
(If no response, I'll proceed with the top-ranked 建模方案.)

• User picks 建模方案 (or no response + AUTO_PROCEED=true) → proceed to Phase 3 with top-ranked 建模方案.
• User unhappy with all 建模方案 → collect feedback ("what's missing?", "what direction do you prefer?"), update the prompt with user's constraints, and re-run Phase 2 (建模方案 generation). Repeat until the user selects at least 1 建模方案.
• User wants to adjust scope → go back to Phase 1 with refined direction.

Phase 3: Deep 可行性 Verification

For each top 建模方案 (positive 验证信号), run a thorough 可行性检查:

/feasibility-check "[top 建模方案 1 description]"
/feasibility-check "[top 建模方案 2 description]"

What this does:

• Multi-source 参考资料 search (数模论文库, Scholar, Semantic Scholar)
• Cross-verify with GPT-5.4 xhigh
• Check for concurrent work (last 3-6 months)
• Identify closest existing work and differentiation points

Update MODEL_REPORT.md with deep 可行性 results. Eliminate any 建模方案 that turns out to be already published.

Phase 4: External Critical Review

For the surviving top 建模方案(s), get brutal feedback:

/model-review "[top 建模方案 with hypothesis + 验证结果]"

What this does:

• GPT-5.4 xhigh acts as a senior reviewer (数模竞赛评委水准)
• Scores the 建模方案, identifies weaknesses, suggests minimum viable improvements
• Provides concrete feedback on experimental design

Update MODEL_REPORT.md with reviewer feedback and revised plan.

Phase 4.5: Method Refinement + Experiment Planning

After review, refine the top 建模方案 into a concrete proposal and plan experiments:

/model-refine-pipeline "[top 建模方案 description + 验证结果 + reviewer feedback]"

What this does:

• Freeze a Problem Anchor to prevent scope drift
• Iteratively refine the method via GPT-5.4 review (up to 5 rounds, until score ≥ 9)
• Generate a claim-driven experiment roadmap with 灵敏度分析s, budgets, and run order
• Output: refine-logs/FINAL_PROPOSAL.md, refine-logs/SOLVE_PLAN.md, refine-logs/SOLVE_TRACKER.md

🚦 Checkpoint: Present the refined proposal summary:

🔬 Method refined and experiment plan ready:
- Problem anchor: [anchored problem]
- Method thesis: [one sentence]
- Dominant contribution: [what's new]
- Must-run experiments: [N blocks]
- First 3 runs to launch: [list]

Proceed to implementation? Or adjust the proposal?

• User approves (or AUTO_PROCEED=true) → proceed to Final Report.
• User requests changes → pass feedback to /model-refine for another round.
• Lite mode: If reviewer score < 6 or 验证 was weak, run /model-refine only (skip /solve-plan) and note remaining risks in the report.

Phase 5: Final Report

Finalize MODEL_REPORT.md with all accumulated information:

# 建模方案发现报告

**Direction**: $ARGUMENTS
**Date**: [today]
**Pipeline**: problem-analysis → model-creator → feasibility-check → model-review → model-refine-pipeline

## Executive Summary
[2-3 sentences: best 建模方案, key evidence, recommended next step]

## Literature Landscape
[from Phase 1]

## Ranked 建模方案
[from Phase 2, updated with Phase 3-4 results]

### 🏆 建模方案 1: [title] — RECOMMENDED
- 验证: POSITIVE (+X%)
- 可行性: CONFIRMED (closest: [paper], differentiation: [what's different])
- Reviewer score: X/10
- Next step: implement full experiment → /auto-optimize-loop

### 建模方案 2: [title] — BACKUP
...

## Eliminated 建模方案
[建模方案 killed at each phase, with reasons]

## Refined Proposal
- Proposal: `refine-logs/FINAL_PROPOSAL.md`
- Experiment plan: `refine-logs/SOLVE_PLAN.md`
- Tracker: `refine-logs/SOLVE_TRACKER.md`

## Next Steps
- [ ] /run-solver to deploy experiments from the plan
- [ ] /auto-optimize-loop to iterate until 可提交
- [ ] Or invoke /mathmodel-pipeline for the complete end-to-end flow

Phase 5.5: Write Compact Files (when COMPACT = true)

Skip entirely if COMPACT is false.

Write MODEL_CANDIDATES.md — a lean summary of the top 3-5 surviving 建模方案:

# 建模方案候选

| # | 建模方案 | 验证 Signal | 可行性 | Reviewer Score | Status |
|---|------|-------------|---------|---------------|--------|
| 1 | [title] | +X% | Confirmed | X/10 | RECOMMENDED |
| 2 | [title] | +Y% | Confirmed | X/10 | BACKUP |
| 3 | [title] | Negative | — | — | ELIMINATED |

## Active 建模方案: #1 — [title]
- Hypothesis: [one sentence]
- Key evidence: [验证 result]
- Next step: /solve-bridge or /model-refine

This file is intentionally small (30 lines) so downstream skills and session recovery can read it without loading the full MODEL_REPORT.md (200+ lines).

Key Rules

• Large file handling: If the Write tool fails due to file size, immediately retry using Bash (cat << 'EOF' > file) to write in chunks. Do NOT ask the user for permission — just do it silently.

• Don't skip phases. Each phase filters and validates — skipping leads to wasted effort later.

• Checkpoint between phases. Briefly summarize what was found before moving on.

• Kill 建模方案 early. It's better to kill 10 bad 建模方案 in Phase 3 than to implement one and fail.

• Empirical signal > theoretical appeal. An 建模方案 with a positive 验证 outranks a "sounds great" 建模方案 without evidence.

• Document everything. Dead ends are just as valuable as successes for future reference.

• Be honest with the reviewer. Include negative results and failed 验证s in the review prompt.

• Feishu notifications are optional. If ~/.claude/feishu.json exists, send checkpoint at each phase transition and pipeline_done at final report. If absent/off, skip silently.

Composing with Workflow 2

After this pipeline produces a validated top 建模方案:

/modeling-discovery "direction"         ← you are here (Workflow 1, includes method refinement + experiment planning)
/run-solver                     ← deploy experiments from the plan
/auto-optimize-loop "top 建模方案"        ← Workflow 2: iterate until 可提交

Or use /mathmodel-pipeline for the full end-to-end flow.