model-refine-pipeline

# Research Refine Pipeline: End-to-End Method and Experiment Planning Refine and concretize: **$ARGUMENTS** ## Overview Use this skill when the user does not want to stop at a refined method. The goal is to produce a coherent package that includes: - a problem-anchored, elegant final proposal - the review history explaining why the method is focused - a detailed 求解路线图 tied to the paper's claims - a compact pipeline summary that says what to run next This skill composes two existing workflows: 1. `model-refine` for method refinement 2. `solve-plan` for claim-driven validation planning For stage-specific detail, read these sibling skills only when needed: - `../model-refine/SKILL.md` - `../solve-plan/SKILL.md` ## Core Rule Do not plan a large experiment suite on top of an unstable method. First stabilize the thesis. Then turn the stable thesis into experiments. ## Default Outputs - `refine-logs/FINAL_PROPOSAL.md` - `refine-logs/REVIEW_SUMMARY.md` - `refine-logs/REFINEMENT_REPORT.md` - `refine-logs/SOLVE_PLAN.md` - `refine-logs/SOLVE_TRACKER.md` - `refine-logs/PIPELINE_SUMMARY.md` ## Workflow ### Phase 0: Triage the Starting Point - Extract the problem, rough approach, constraints, resources, and target venue. - Check whether `refine-logs/FINAL_PROPOSAL.md` already exists and still matches the current request. - If the proposal is missing, stale, or materially different from the current request, run the full `model-refine` stage. - If the proposal is already strong and aligned, reuse it and jump to 求解计划ning. - If in doubt, prefer re-running `model-refine` rather than planning experiments for the wrong method. ### Phase 1: Method Refinement Stage Run the `model-refine` workflow and keep its V3 philosophy intact: - preserve the Problem Anchor - prefer the smallest adequate mechanism - keep one dominant contribution - modernize only when it improves the paper Exit this stage only when these are explicit: - the final method thesis - the dominant contribution - the complexity intentionally rejected - the key claims and must-run 灵敏度分析s - the remaining risks, if any If the verdict is still `REVISE`, continue into 求解计划ning only if the remaining weaknesses are clearly documented. ### Phase 2: Planning Gate Before the experiment stage, write a short gate check: - What is the final method thesis? - What is the dominant contribution? - What complexity was intentionally rejected? - Which reviewer concerns still matter for validation? - Is a frontier primitive central, optional, or absent? If these answers are not crisp, tighten the final proposal first. ### Phase 3: Experiment Planning Stage Run the `solve-plan` workflow grounded in: - `refine-logs/FINAL_PROPOSAL.md` - `refine-logs/REVIEW_SUMMARY.md` - `refine-logs/REFINEMENT_REPORT.md` Ensure the 求解计划 covers: - the main anchor result - novelty isolation - a simplicity or deletion check - a frontier necessity check if applicable - run order, budget, and decision gates ### Phase 4: Integration Summary Write `refine-logs/PIPELINE_SUMMARY.md`: ```markdown # Pipeline Summary **Problem**: [problem] **Final Method Thesis**: [one sentence] **Final Verdict**: [READY / REVISE / RETHINK] **Date**: [today] ## Final Deliverables - Proposal: `refine-logs/FINAL_PROPOSAL.md` - Review summary: `refine-logs/REVIEW_SUMMARY.md` - Experiment plan: `refine-logs/SOLVE_PLAN.md` - Experiment tracker: `refine-logs/SOLVE_TRACKER.md` ## Contribution Snapshot - Dominant contribution: - Optional supporting contribution: - Explicitly rejected complexity: ## Must-Prove Claims - [Claim 1] - [Claim 2] ## First Runs to Launch 1. [Run] 2. [Run] 3. [Run] ## Main Risks - [Risk]: - [Mitigation]: ## Next Action - Proceed to `/run-solver` ``` ### Phase 5: Present a Brief Summary to the User ``` Pipeline complete. Method output: - refine-logs/FINAL_PROPOSAL.md Experiment output: - refine-logs/SOLVE_PLAN.md - refine-logs/SOLVE_TRACKER.md Pipeline summary: - refine-logs/PIPELINE_SUMMARY.md Best next step: - /run-solver ``` ## 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. - Do not let the 求解计划 override the Problem Anchor. - Do not widen the paper story after method refinement unless a missing validation block is truly necessary. - Reuse the same claims across `FINAL_PROPOSAL.md`, `SOLVE_PLAN.md`, and `PIPELINE_SUMMARY.md`. - Keep the main paper story compact. - If the method is intentionally simple, defend that simplicity in the 求解计划 rather than adding new components. - If the method uses a modern LLM / VLM / Diffusion / RL primitive, make its necessity test explicit. - If the method does not need a frontier primitive, say that clearly and avoid forcing one. - Prefer the staged skills when the user only needs one stage; use this skill for the integrated flow. ## Composing with Other Skills ``` /model-refine-pipeline -> one-shot method + 求解计划ning /model-refine -> method refinement only /solve-plan -> 求解计划ning only /run-solver -> execution ```