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`**: ```markdown # 参考方法概要 **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: ```markdown # 建模方案发现报告 **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 建模方案: ```markdown # 建模方案候选 | # | 建模方案 | 验证 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. ```