mcpField
R
research-refine-pipeline

research-refine-pipeline

github.com/wanshuiyin生産性18.2k511 回インストール4 日前に更新
リポジトリ

research-refine-pipeline について

research-refine-pipelineは、研究手法の精緻化と主張に基づく実験計画を組み合わせるスキルです。手法を固めてから検証計画を立てたい研究者向けで、提案書、レビュー記録、実験計画、追跡文書を一貫して作成します。

主な機能

  1. 01計画前に手法を精緻化
  2. 02問題を軸にした提案
  3. 03主張に基づく実験ロードマップ
  4. 04実行順序、予算、判断ゲート
  5. 05提案書とレビュー記録
  6. 06実験トラッカーとパイプライン概要

活用シーン

  1. 01実験前に研究手法を精緻化
  2. 02固まった提案を検証手順に変換
  3. 03論文の主張に沿ってアブレーションを計画
  4. 04手法と実験の文書を連携

MCP 対応

レビュー段階の経路を指定しており、Codex MCPをデフォルトとしています。MCPサーバーやクライアントのインターフェースを提供するとは記載されていません。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/wanshuiyin/auto-claude-code-research-in-sleep --skill research-refine-pipeline

インストール後、Claude Code で/research-refine-pipelineを入力して読み込まれたか確認します。

詳細

Research Refine Pipeline: エンドツーエンドの手法と実験計画

各レビュアーの担当枠の前に、Selectable Reviewers に従ってください。 呼び出し → .aris/reviewer.json → Claude Code のデフォルト（Codex MCP）の順に解決し、 正規のヘルパーリゾルバーを通じて reviewer_route.py を使用し、この担当枠のティア、新しいコンテキスト、ソース／画像入力、決定論的ゲートを維持します。 以下の Codex の例／ピン留めは backend=codex にのみ適用されます。それ以外のルートでは、 それぞれの初回呼び出し／返信の契約を使用します。ルートと実際に返された ID を保存してください。 選択したものを利用できない場合は REVIEW_UNAVAILABLE とします。実際のファミリー／完了状況／範囲に基づいて受け入れ可否を分類してください。 呼び出し時のレビュアー／モデル／負荷の上書き設定は、レビュアーを含む子に引き継いでください。生成ワーカーに変更はありません。

精緻化して具体化する：$ARGUMENTS

概要

ユーザーが、手法を精緻化するだけで終わらせたくない場合にこのスキルを使用します。目標は、以下を含む一貫したパッケージを作成することです。

  • 問題に根ざした洗練された最終提案
  • 手法を絞り込んだ理由を説明するレビュー履歴
  • 論文の主張に結び付いた詳細な実験ロードマップ
  • 次に何を実行すべきかを示す簡潔なパイプライン概要

このスキルは、既存の 2 つのワークフローを組み合わせます。

  1. 手法の精緻化を行う research-refine
  2. 主張に基づく検証計画を作成する experiment-plan

各段階の詳細が必要な場合に限り、次の関連スキルを読みます。

  • ../research-refine/SKILL.md
  • ../experiment-plan/SKILL.md

基本ルール

不安定な手法を土台に、大規模な実験一式を計画してはいけません。まず主張を安定させ、その後で安定した主張を実験に落とし込みます。

標準の出力

  • 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

ワークフロー

フェーズ 0：開始時点の状況を整理する
  • 問題、概略的なアプローチ、制約、リソース、投稿先の候補を抽出します。
  • refine-logs/FINAL_PROPOSAL.md がすでに存在し、現在の依頼と一致しているかを確認します。
  • 提案が存在しない、古くなっている、または現在の依頼と実質的に異なる場合は、research-refine の全段階を実行します。
  • 提案がすでに優れており、依頼とも一致している場合は、それを再利用して実験計画に進みます。
  • 判断に迷う場合は、誤った手法に対する実験を計画するより、research-refine を再実行してください。
フェーズ 1：手法の精緻化

research-refine ワークフローを実行し、その V3 の考え方を維持します。

  • Problem Anchor を維持する
  • 必要十分な最小限の仕組みを優先する
  • 中心となる貢献を 1 つに絞る
  • 論文の質を高める場合に限り、手法を最新化する

次の項目が明確になるまで、この段階を終了しないでください。

  • 最終的な手法の主張
  • 中心となる貢献
  • 意図的に採用を見送った複雑さ
  • 主要な主張と、必ず実施するアブレーション
  • 残っているリスク（ある場合）

判定がまだ REVISE の場合、残る弱点が明確に記録されているときに限り、実験計画へ進みます。

フェーズ 2：計画のゲート

実験段階に進む前に、短いゲート確認を記述します。

  • 最終的な手法の主張は何か？
  • 中心となる貢献は何か？
  • どのような複雑さを意図的に採用しなかったか？
  • 検証において、レビュアーのどの懸念が依然として重要か？
  • フロンティア・プリミティブは中心的か、任意か、それとも含まれないか？

これらの答えが明確でない場合は、まず最終提案を練り直してください。

フェーズ 3：実験計画

以下を土台として、experiment-plan ワークフローを実行します。

  • refine-logs/FINAL_PROPOSAL.md
  • refine-logs/REVIEW_SUMMARY.md
  • refine-logs/REFINEMENT_REPORT.md

実験計画には、以下を必ず含めます。

  • 主要なアンカー結果
  • 新規性の切り分け
  • 単純化または削除の検証
  • 該当する場合はフロンティア技術の必要性の検証
  • 実行順序、予算、判定ゲート
フェーズ 4：統合サマリー

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`
フェーズ 5：ユーザーに簡潔なサマリーを提示する
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

出力プロトコル

すべての出力ファイルで、以下の共通プロトコルに従ってください。

主なルール

  • 大きなファイルの扱い：ファイルサイズが原因で Write ツールが失敗した場合は、直ちに Bash（cat << 'EOF' > file）を使ってチャンク単位で書き込んでください。ユーザーの許可を求めず、そのまま実行してください。

  • 実験計画で Problem Anchor を上書きしないでください。

  • 手法の改良後、真に必要な検証ブロックが不足している場合を除き、論文のストーリーを拡大しないでください。

  • FINAL_PROPOSAL.md、EXPERIMENT_PLAN.md、PIPELINE_SUMMARY.md で同じ主張を再利用してください。

  • 論文の主なストーリーは簡潔に保ってください。

  • 手法が意図的にシンプルな場合は、新たな構成要素を追加するのではなく、実験計画でそのシンプルさを正当化してください。

  • 手法で最新の LLM／VLM／Diffusion／RL プリミティブを使用する場合は、その必要性を明示的に検証してください。

  • フロンティアプリミティブが不要な手法の場合は、そのことを明確に述べ、無理に導入しないでください。

  • ユーザーが単一の段階だけを必要としている場合は、段階別スキルを優先し、統合されたフローにはこのスキルを使用してください。

他のスキルとの組み合わせ

/research-refine-pipeline -> one-shot method + experiment planning
/research-refine   -> method refinement only
/experiment-plan   -> experiment planning only
/run-experiment    -> execution

コメント

Markdown 対応