mcpbeat

Research Refine Pipeline

wanshuiyin/research-refine-pipeline

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.

2k tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
14221
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/wanshuiyin/Auto-claude-code-research-in-sleep --skill research-refine-pipeline

What it tells the agent to use

found in the instruction text
Bash runs shell commands — read the instruction before connecting
Write writes files
WebFetch fetches pages from the network
WebSearch reads your files

The instruction itself

14 sections, as written by the author

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-refine for method refinement
  • experiment-plan for 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.md
  • refine-logs/REVIEW_SUMMARY.md
  • refine-logs/REFINEMENT_REPORT.md
  • refine-logs/EXPERIMENT_PLAN.md
  • refine-logs/EXPERIMENT_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 research-refine stage.
  • If the proposal is already strong and aligned, reuse it and jump to experiment planning.
  • If in doubt, prefer re-running research-refine rather 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.md
  • refine-logs/REVIEW_SUMMARY.md
  • refine-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-experiment

Output 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, and PIPELINE_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    -> execution

How to use it

Copy the folder

Take wanshuiyin/research-refine-pipeline from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.