research-refine-pipeline
Skill2 starsChanged 6 months agoMITView on GitHub
Run an end-to-end workflow that chains `research-refine` and `experiment-plan`. Use when the user wants a one-shot pipeline from vague research direction to focused final proposal plus detailed experiment roadmap, or asks to "串起来", build a pipeline, do it end-to-end, or generate both the method and experiment plan together.
We split this skill into the rules it gives an agent
23 rules. 16 are common, 0 are distinctive, and 7 are very specific to this project.
16
Common
Most of the 5 edited versions we read keep these.
0
Distinctive
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Common: line 13
Use this skill when the user does not want to stop at a refined method.
- Common: line 32
Do not plan a large experiment suite on top of an unstable method.
- Very specific: line 48
Check whether refine-logs/FINAL_PROPOSAL.md already exists and still matches the current request.
- Very specific: line 49
If the proposal is missing, stale, or materially different from the current request, run the full research-refine stage.
- Common: line 50
If the proposal is already strong and aligned, reuse it and jump to experiment planning.
- Very specific: line 51
If in doubt, prefer re-running research-refine rather than planning experiments for the wrong method.
- Very specific: line 55
Run the research-refine workflow and keep its V3 philosophy intact:
- Common: line 58
prefer the smallest adequate mechanism
- Common: line 59
keep one dominant contribution
- Very specific: line 70
If the verdict is still REVISE, continue into experiment planning only if the remaining weaknesses are clearly documented.
- Common: line 74
Before the experiment stage, write a short gate check:
- Common: line 82
If these answers are not crisp, tighten the final proposal first.
- Very specific: line 86
Run the experiment-plan workflow grounded in:
- Common: line 92
Ensure the experiment plan covers:
- Common: line 98
run order, budget, and decision gates
- Very specific: line 168
Large file handling: If the Write tool fails due to file size, immediately retry using Bash (cat << 'EOF' > file) to write in chunks.
- Common: line 170
Do not let the experiment plan override the Problem Anchor.
- Common: line 171
Do not widen the paper story after method refinement unless a missing validation block is truly necessary.
- Common: line 173
Keep the main paper story compact.
- Common: line 174
If the method is intentionally simple, defend that simplicity in the experiment plan rather than adding new components.
- Common: line 175
If the method uses a modern LLM / VLM / Diffusion / RL primitive, make its necessity test explicit.
- Common: line 176
If the method does not need a frontier primitive, say that clearly and avoid forcing one.
- Common: line 177
Prefer the staged skills when the user only needs one stage.
“Common” is measured: kept by at least 6 in 10 of the 5 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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 experiment roadmap tied to the paper's claims
- a compact pipeline summary that says what to run next
This skill composes two existing workflows:
research-refinefor method refinementexperiment-planfor claim-driven validation planning
For stage-specific detail, read these sibling skills only when needed:
../research-refine/SKILL.md../experiment-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.mdrefine-logs/REVIEW_SUMMARY.mdrefine-logs/REFINEMENT_REPORT.mdrefine-logs/EXPERIMENT_PLAN.mdrefine-logs/EXPERIMENT_TRACKER.mdrefine-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.mdalready exists and still matches the current request. - If the proposal is missing, stale, or materially different from the current request, run the full
research-refinestage. - If the proposal is already strong and aligned, reuse it and jump to experiment planning.
- If in doubt, prefer re-running
research-refinerather than planning experiments for the wrong method.
Phase 1: Method Refinement Stage
Run the research-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 ablations
- the remaining risks, if any
If the verdict is still REVISE, continue into experiment planning 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 experiment-plan workflow grounded in:
refine-logs/FINAL_PROPOSAL.mdrefine-logs/REVIEW_SUMMARY.mdrefine-logs/REFINEMENT_REPORT.md
Ensure the experiment plan 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:
# 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/EXPERIMENT_PLAN.md`
- Experiment tracker: `refine-logs/EXPERIMENT_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-experiment`Phase 5: Present a Brief Summary to the User
Pipeline complete.
Method output:
- refine-logs/FINAL_PROPOSAL.md
Experiment output:
- refine-logs/EXPERIMENT_PLAN.md
- refine-logs/EXPERIMENT_TRACKER.md
Pipeline summary:
- refine-logs/PIPELINE_SUMMARY.md
Best next step:
- /run-experimentOutput Protocols
Follow these shared protocols for all output files:
- Output Versioning Protocol — write timestamped file first, then copy to fixed name
- Output Manifest Protocol — log every output to MANIFEST.md
- Output Language Protocol — respect the project's language setting
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 experiment plan 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,EXPERIMENT_PLAN.md, andPIPELINE_SUMMARY.md. - Keep the main paper story compact.
- If the method is intentionally simple, defend that simplicity in the experiment plan 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
/research-refine-pipeline -> one-shot method + experiment planning
/research-refine -> method refinement only
/experiment-plan -> experiment planning only
/run-experiment -> executionOther versions6 projects use a version of this.
Word for word · 1
- Chanw-research/claude-code-paper-writing★ 42100% same
Edited · 5
- wanshuiyin/Auto-claude-code-research-in-sleep★ 18k89% same
- zjunlp/Mechanist★ 7599% same
- catalsqlb-cmd/Prism-H★ 1679% same
- yvesory/academic-research-suite★ 9100% same
- talhaMah56/claude_skills★ 0100% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository84 other files it gives its agents.
- skills/rules/common/agents.mdAGENTS.md
- skills/rules/zh/agents.mdAGENTS.md
- ablation-plannerSkill
- alphaxivSkill
- analyze-resultsSkill
- arxivSkill
- auto-paper-improvement-loopSkill
- auto-review-loop-llmSkill
- auto-review-loop-minimaxSkill
- auto-review-loopSkill
- citation-auditSkill
- claims-draftingSkill
- comm-lit-review-claude-singleSkill
- deepxivSkill
- dse-loopSkill
- embodiment-descriptionSkill
- exa-searchSkill
- experiment-auditSkill
- experiment-bridgeSkill
- experiment-planSkill
- experiment-queueSkill
- feishu-notifySkill
- figure-descriptionSkill
- figure-specSkill
- formula-derivationSkill
- gemini-searchSkill
- grant-proposalSkill
- idea-creatorSkill
- idea-discovery-robotSkill
- idea-discoverySkill
- invention-structuringSkill
- jurisdiction-formatSkill
- kill-argumentSkill
- mermaid-diagramSkill
- meta-optimizeSkill
- monitor-experimentSkill
- novelty-checkSkill
- openalexSkill
- overleaf-syncSkill
- paper-claim-auditSkill
- paper-compileSkill
- paper-figureSkill
- paper-illustration-image2Skill
- paper-illustrationSkill
- paper-planSkill
- paper-posterSkill
- paper-slidesSkill
- paper-talkSkill
- paper-writeSkill
- paper-writingSkill
- patent-novelty-checkSkill
- patent-pipelineSkill
- patent-reviewSkill
- pixel-artSkill
- prior-art-searchSkill
- proof-checkerSkill
- proof-writerSkill
- qzcliSkill
- rebuttalSkill
- research-litSkill
- The first 60 shown.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

