mcpField
R
research-proposal

research-proposal

github.com/luwill生産性876911 回インストール3 日前に更新
リポジトリ

research-proposal について

英語または中国語で博士課程の研究提案書や研究計画を作成するスキルです。状況に応じた構成と、引用の検証を伴う段階的な執筆を重視します。

主な機能

  1. 01研究シナリオに応じた構成選択
  2. 02研究要件と範囲の整理
  3. 03引用元の検証
  4. 04セクションごとの執筆
  5. 05引用と文章品質の確認

活用シーン

  1. 01博士課程の研究提案書の作成
  2. 02開題報告の構成調整
  3. 03助成金申請形式に合わせた提案内容の準備

インストール

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

$npx skills add https://github.com/luwill/research-skills --skill research-proposal

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

assets/
proposal_scaffold_en.md
proposal_scaffold_zh.md
learnings/
2026-09-30-重写清不完所有文件.md
2026-10-24-自动判制式会静默丢掉另一种引用.md
README.md
references/
CITATION_INTEGRITY.md
DOMAIN_TEMPLATES.md
LITERATURE_WORKFLOW.md
QUALITY_CHECKLIST.md
STRUCTURE_GUIDE.md
WRITING_STYLE_GUIDE.md
scripts/
check_proposal.py
integrity_gate.py
tests/
test_check_proposal.py
test_document_contract.py

詳細

研究計画書ジェネレーター

まだ実施されていない研究の計画である、先を見据えた学術研究計画書を、主要な学術論文の慣例に従って英語または中国語で作成します。

このスキルは、後で修正するためのテンプレートではなく、最初の草稿を適切に作成します。最も重要な規律は、引用の完全性です。架空の参考文献を含む計画書は、文体上の問題ではなく、学術倫理上の問題です。Phase 2に進む前に、references/CITATION_INTEGRITY.mdをお読みください。

基本原則

まず文章を書く。 計画書は、箇条書きではなく、流れのあるつながった段落として読み進められるものです。箇条書きは、焦点を絞った研究課題/目的(2~4項目)とスケジュールのマイルストーンに限って使います。貢献、方法論、背景、意義を箇条書きで列挙せず、文章で説明してください。詳しいルールと例は、references/WRITING_STYLE_GUIDE.mdを参照してください。

すべての引用は、採用する前に検証する。 参考文献の数は議論に応じて決め、ノルマを設けません。最低数もありません。博士課程の計画書では通常25~50件を引用します(人文学ではさらに多いこともあります)。数合わせで45件にするより、論旨が緻密な25件のほうが優れています。すべての参考文献について、計画書に採用する前に、実在すること(DOI/PMID/arXivで確認できるか、Zoteroのメタデータで確認できること)と、著者名および出版年が原典と一致することを確かめてください。検証できない参考文献には[UNVERIFIED]と明記して開示し、決して捏造しないでください。references/CITATION_INTEGRITY.mdを参照してください。

一度に書き上げず、検証しながら書く。 セクションごとに草稿を作成し、次のセクションに進む前に各セクションの引用を検証してください(Phase 4)。多数の引用を含む複数セクションの計画書全体を一度に生成してはいけません。それこそが、参考文献の幻覚を引き起こす構造的な原因です。

根拠に応じて慎重に述べる。 提案する研究や不確実な主張には、「目指します」「可能性があります」「期待されます」といった控えめな表現を使い、確立された事実は明確に述べてください。「証明します」「革命を起こします」のように、主張を過度に強めないでください。

LLMらしい表現を避ける。 以下の表現はAI検出ツールに検出されやすいため、取り除いてください。「過去10年間で、Xは……として台頭しました」「近年、」「注目すべきなのは」「重要な/極めて重要な役割を果たす」「大きな注目を集めている」「深く掘り下げる」「……の証し」。中文:「近年来,随着……的飞速发展」「……日益受到广泛关注」。一般的な状況説明ではなく、実際の研究分野に根差した具体的な書き出しにしてください。

シナリオに応じた構成

以下のデフォルト構成は、博士課程の研究計画書および学術研究計画(Abstract → Introduction → Literature Review → Methodology → Timeline → Significance)を対象としています。Phase 1でシナリオを確認し、それに応じて調整してください。

依頼内容構成
博士課程の計画書、研究計画書、研究計画書デフォルト構成(このスキル)
开题报告(学位論文の計画書/審査)デフォルト構成。ただし、Literature Reviewにより重点を置き、Methodologyの冒頭に**研究基盤/実現可能性分析(既存の基盤と実現可能性)**の小節を設けます。審査者の先行研究、予備的な結果、データ/計算資源へのアクセスを含め、方法論は具体的に記述してください
人文学の博士論文計画書デフォルト構成に章立ての概要セクションを追加します(references/DOMAIN_TEMPLATES.mdを参照)
基金申請書/国自然/NSF助成金別の構成(立項根拠/研究内容と目標/研究計画と実現可能性/研究基盤と作業条件)。このスキルでは、助成機関が指定するセクションに合わせた「内容」を作成しますが、助成機関独自の申請システム、予算表、NSF固有の項目(Intellectual Merit/Broader Impacts)は作成しません。デフォルトの5セクション構成は助成金申請書の様式ではないことをユーザーに伝えてください。執筆前に見出しを助成機関指定の様式に合わせ、ユーザーに確認してください

フェーズ 1:要件の収集

AskUserQuestion を使用して、以下を収集します。

  • 研究テーマ/問い — 調査する中心的な課題。
  • シナリオ — 博士課程の研究提案書/开题报告/研究計画書/助成金申請書(構成の振り分けについては上記を参照)。
  • 学術分野 — STEM(計算科学/MLを含むかどうかについては、references/DOMAIN_TEMPLATES.md を参照)、人文学、または社会科学。
  • 出力言語 — 英語または中文。
  • 目標の長さ — 博士課程の研究提案書/研究計画書:デフォルトで約3,000語、範囲は2,000~4,000語(人文学では約10,000語まで延長する場合があります)。开题报告の分量はこのデフォルトではなく、所属機関によって定められます — 大学のテンプレートと指定分量を確認してください(一般的には10,000~30,000字で、文献レビューが半分を占めることもよくあります)。中国語の分量は空白で区切った語数ではなく、文字数(wc -m)で数えます。要件がない場合は、中文の开题报告は約15,000字をデフォルトとし、確定した前提として明記します。
  • 任意 — 対象となる大学/指導教員、参照する既存資料またはZoteroライブラリ。

テーマが曖昧すぎて方法論の範囲を定められない場合は、先に焦点を絞った確認質問をします。ヘッドレス実行(別のエージェントのパイプラインから呼び出されるなど、対話形式でユーザーとやり取りしない場合)では、質問する代わりに、呼び出し元のプロンプトから上記の要件を抽出し、フェーズ 3 の方法に従ってアウトラインに確定した前提として記録します。プロンプトに明記されていない要件を決して作り出さないでください。


フェーズ 2:文献の収集(検証ゲート付き)

検索戦略と整理方法については、references/LITERATURE_WORKFLOW.md を参照してください。

ツールの移植性。 ツール固有の名前を使用する前に、利用可能なツールを確認してください。アクセス制限のある論文には、ユーザーのZoteroライブラリ(mcp__zotero__* ツール経由)を優先して使用します。動向やトレンドの調査には WebSearch を使用し、DOI/PubMed/arXivのページを開いてメタデータを確認するには WebFetch を使用します。Zotero/arXiv/PubMedのMCPが接続されていない場合は、WebSearch と WebFetch に切り替えます。アクセス制限のある関連論文はZoteroに追加するよう、ユーザーに案内してください。

役割ごとの情報源:動向、レビュー、用語の調査には WebSearch、オープンアクセスの一次資料とメタデータにはarXiv/PubMed/出版社のページに対する WebFetch、ユーザー自身のライブラリ、注釈、メモにはZotero MCPを使用します。学術誌論文については、Crossref REST API(WebFetch https://api.crossref.org/works/<DOI>)が、論文の実在性とメタデータの確認に最も有力です。整ったJSON(タイトル/筆頭著者/年/掲載誌)が返され、出版社のHTMLページを解析するより信頼性が高いです。

候補は、背景/文脈、最新の研究状況、研究ギャップの特定、方法論、関連研究の役割ごとに整理します。

検証ゲート(省略しないこと)

情報源を引用対象にする前に、以下を行います。

  1. 各候補の実在性、筆頭著者、発行年を一次情報源(DOI/PMID/arXivのページ、またはZoteroのメタデータ)で確認します。references/CITATION_INTEGRITY.md のルール1、2、5に従ってください。
  2. 具体的な知見や数値を引用するのは、全文または抄録に実際にアクセスした情報源に限ります。開けなかった論文について、内部の結果を記述してはいけません。
  3. アウトラインを作成する前に、検証済みの候補リスト(タイトル、著者、年、情報源/DOI)をユーザーに提示し、簡単な確認を受けます。

検証できない情報源は参考文献候補に含めません。ユーザーが記憶違いの可能性がある情報源を指定した場合は、[UNVERIFIED] と明記します。

非対話/ヘッドレス実行。 スキルが対話形式でユーザーとやり取りせずに呼び出された場合(バックグラウンドエージェントまたはパイプライン)は、手順3で処理を止めてはいけません。検証済み候補リストを成果物または補助ファイル citation_verification_log.md に記録して、処理を続けてください。記録されたリストは、ユーザーとのライブ確認に代わる監査証跡となります。


フェーズ 3:アウトラインの作成

セクションごとの指針と分野別の指針については、references/STRUCTURE_GUIDE.md と references/DOMAIN_TEMPLATES.md を参照してください。

標準アウトライン(デフォルトのシナリオ)
# [Research Title]

## Abstract (150-300 words, 5-10%) — background, questions, methodology overview, significance
## 1. Introduction (500-800 words, 15-20%) — background, problem, questions/objectives, scope
## 2. Literature Review (500-1000 words, 20-25%) — framework, current state, gap, positioning
## 3. Methodology (500-800 words, 20-25%) — design, data collection, analysis, validity/limitations
## 4. Timeline (200-300 words, 5-10%) — phases, milestones, optional Gantt
## 5. Significance and Expected Contributions (200-400 words, 10-15%) — theoretical, practical, broader impact
## References — cite what the argument needs (see CITATION_INTEGRITY.md); no minimum, no padding

人文系の提案書には、章立てのアウトラインセクションを追加します。付録は含めず、重要な内容は本文に組み込んでください。

承認ゲート(レッドライン)

アウトラインを提示し、ユーザーから明確な承認を得てからフェーズ 4 に進んでください。未承認のアウトラインに基づいて執筆を始めないでください。

構成、各セクションの重点、範囲に問題がないか、またセクションの追加・削除・変更を希望するかを尋ねてください。

**ユーザーが「あなたに任せる」/「你看着办」と答える、または判断を委ねる場合:**確定する前提条件(シナリオ、分野、セクション構成、目標の長さ、言語)を明示し、具体的なアウトラインを決定案としてもう一度提示してから進めてください。委任したうえで返答がない場合は、提示したそのアウトラインへの承認として扱いますが、ユーザーが異議を唱えられるよう、前提条件は必ず明示してください。

対話可能なユーザーがまったくいない場合(ヘッドレス/エージェント実行):確定した前提条件とアウトラインを成果物内に記録し、記録したアウトラインを承認済みとして扱ってください。これにより、承認者がいない状況で処理が止まることなく、監査証跡を残せます。


フェーズ 4:本文の執筆(執筆と検証)

足場となる構成を執筆の骨格として読み込み、セクションごとに内容を埋めてください。

references/WRITING_STYLE_GUIDE.mdを読み、その指針を適用してください。主な必須ルール:箇条書きより文章を優先すること、根拠に応じて断定を控えること、PEEL 段落(主張 → 根拠と引用 → 説明 → つながり)を用いること、略語は初出時に定義すること(「冠動脈 CT 血管造影(CCTA)」など)、引用を文章に組み込むこと。

執筆と検証のループ — 各セクションで繰り返します:

  1. 文章としてつながった形でセクションを執筆し、本文中の引用には、選択したスタイルに従ってフェーズ 2 で検証済みの文献のみを使用します。APA/MLA 形式では (Author, Year)、GB/T 7714 順序编码制では番号付きの [N](中国語のデフォルト)を使います。
  2. 直ちに、そのセクションの引用を検証します。本文中の引用すべてに対応する参考文献項目があること(ルール 3)、および方向性や定量的な主張がそれぞれの出典と一致していること(ルール 4)を確認します。references/CITATION_INTEGRITY.mdを参照してください。
  3. LLM らしさの兆候(主要原則)と、CITATION_INTEGRITY.md に記載されたハルシネーションの危険信号に照らして自己確認します。
  4. 不備があれば、次のセクションに進む前にその場で修正します。未検証の引用をセクション間で蓄積しないでください。

**分野別の引用スタイル:**STEM/社会科学 → APA(Author, Year)、人文科学 → MLA または Chicago、中国語 → GB/T 7714。全編を通してスタイルを統一してください。

**図:**適切な箇所に 3~5 点の図を提案してください(要旨には含めないでください)。それぞれにタイトル、内容の説明、スタイルに関する注記を付けます。形式と配置の指針はreferences/WRITING_STYLE_GUIDE.mdに記載されています。

**中文の出力:**規範的な学術文体を用い、断定を控えてください(「本研究は……を探究することを目的とする」など。「本研究は……を証明する」としないでください)。参考文献は GB/T 7714 に従います。


フェーズ 5:出力とレビュー

ユーザーの作業ディレクトリに proposal_{topic_slug}_{YYYY-MM-DD}.md として保存します。

references/QUALITY_CHECKLIST.md に照らして確認します。提出前に、引用ゲートを通過する必要があります。まず実行可能なゲートを実行し、その出力を貼り付けてください。以下のすべての機械的チェックを一度に実行し、該当する行をそれぞれ示します。

python3 <skill_dir>/scripts/check_proposal.py proposal_{topic_slug}_{YYYY-MM-DD}.md
# --style auto|apa|numeric (auto: numeric when References entries start with [N])
# --allow-disclosed-flags : every remaining [UNVERIFIED…] has been disclosed → warnings, not failures
# exit 0 = no mechanical findings (not proof the proposal is right); 1 = findings; 2 = bad input

本文中の引用と参考文献の対応を双方向で照合します(APA (Smith, 2024) / Smith et al. (2024) は筆頭著者の姓+年で照合し、GB/T 7714 [1] / [2-4] は [N] の項目と照合)。以下のプレースホルダーとAI特有の表現のパターンも実行します(同じ正規表現をテストで固定)。また、免除対象の個別化フィールドは許容しつつ、残存する雛形の [instructions] を検出します。本文では引用スタイルを一つだけ使用します。[N] と著者年方式の混在は、半端なチェックではなく不合格となります。中国語の叙述における著者年方式(张伟(2020)提出)は信頼性の高い分割ができないため、ゲートですべての引用を網羅できるよう、中国語の原稿ではGB/T 7714順序番号方式(デフォルト)を使用します。以下の箇条書きでは各チェックの内容を定義し、手動で確認する場合の代替手順を示します。

  • grep -nE "xxx|XXXX|\[TBD\]|\[UNVERIFIED[^]]*\]|10\.xxxx|doi:10\.[a-z]+/x|forthcoming DOI|\[.*占位.*\]" のヒット数が0件であること。残る [UNVERIFIED] がある場合は、すべてユーザーに明示しており、確認済みとして提示していないこと。(この正規表現が唯一の標準版です。references/CITATION_INTEGRITY.md では別の変形を再掲せず、ここへのリンクを掲載しています。)
  • 本文中のすべての引用が参考文献一覧と対応していること(どちらの方向にも孤立した引用がないこと)。
  • 参考文献の少なくとも20%と、すべての定量的・方向性を示す主張について、出典と照合して抜き取り確認すること。
  • AI特有の表現ゲート:本文内で grep -nEi "over the past ((few|several|two|three) )?(decades?|years)|in recent years,|it is worth noting|plays a (crucial|pivotal|vital) role|sheds light on|paves the way|ever-evolving|has garnered significant attention|delves into|a testament to|众所周知|近年来,?随着|日益受到(广泛)?关注" のヒット数が0件であること(Core Principles を参照。同じパターンはすべての参考文献ファイルと雛形でも禁止されています)。
  • 本文にプレースホルダーの [brackets] や「TBD」が残っていないこと。ただし、ユーザーが個別に記入する必要がある申請者固有の雛形フィールド([University/Institution Name]、[Your Field]、[Month Year]、および中国語の雛形にある [所属学科]、[大学/研究机构名称]、[年月] などの同種のフィールド)と、意図的に残してよい [Figure N Suggestion] ラベルは除きます。

形式変換を提案します。

pandoc proposal.md -o proposal.docx        # Word
pandoc proposal.md -o proposal.pdf         # PDF (needs LaTeX)

参考ファイル

ファイル読むタイミング
references/CITATION_INTEGRITY.mdフェーズ 2 の前、およびフェーズ 4/5 の全期間 — 5つの引用ルール。必須
references/STRUCTURE_GUIDE.mdフェーズ 3 — セクションごとの執筆ガイド
references/DOMAIN_TEMPLATES.mdフェーズ 1/3 — STEM(計算科学/MLを含む)、人文学、社会科学の違い
references/WRITING_STYLE_GUIDE.mdフェーズ 4 — 学術的な文体、ヘッジ表現、接続表現、図
references/QUALITY_CHECKLIST.mdフェーズ 5 — 提出前の最終確認
references/LITERATURE_WORKFLOW.mdフェーズ 2 — 文献収集のワークフロー
assets/proposal_scaffold_en.mdフェーズ 4 — 英語執筆の骨組み
assets/proposal_scaffold_zh.mdフェーズ 4 — 中国語執筆の骨組み

ワークフローの概要

フェーズ 1 要件(対話形式) → フェーズ 2 文献+検証ゲート → フェーズ 3 アウトライン+承認のレッドライン → フェーズ 4 内容、セクションごとの 執筆と検証 → フェーズ 5 出力+引用ゲート+チェックリスト。


エラー処理

  • Zotero の検索結果がない/MCP を利用できない — ユーザーに伝え、オープンアクセスの情報源を対象に WebSearch と WebFetch を使ってフォールバックし、論文を Zotero に追加してから再試行するよう提案します。
  • 参考文献を検証できない/捏造されたように見える — References の一覧には記載しません。本文中に [UNVERIFIED] と記し、ユーザーに伝えます。DOI や著者一覧を補うために決して捏造しないでください。
  • トピックが曖昧すぎる — 明確化のための質問をし、範囲を絞り、適切な研究課題の例を提示します。
  • 語数制限を超えている — Introduction と Methodology を優先し、文献レビューは議論の要となる引用に絞って簡潔にします。拡張版は別ファイルとして提供します。

学び:書き直す前に振り返る

references や scaffold を変更する前に、learnings/ に目を通してください。v1→v2 の書き直しに関する診断から、こうした教訓には価値がある一方、記録として残されていなかったことが分かりました。手戻りが発生したときや矛盾を見つけたときは、日付を名前にした記事を追加してください。

バージョンに関する注記

v1.0.0 のスキルについて、信頼性を守る仕組みがまったくないまま大量の参考文献を生成すること、一度きりの生成ステップ、「参考文献は最低 40 件」という水増しを促す条件、内部で矛盾する数値が診断で判明したため、v2.0.0 では書き直しました。

以前の問題(v1.0.0)現在の修正(v2.0.0)
引用を検証する仕組みが一切ない5 つのルールを定めた CITATION_INTEGRITY.md を追加し、Phase 2/4/5 にゲートを設置
「参考文献は最低 40 件」という条件削除。「議論に必要なものを引用する。通常は 25–50 件。水増しはしない」
Phase 4 が一度きりの生成セクションごとに、検証しながら執筆する方式に変更
執筆前に文献を検証するゲートがないPhase 2 に引用前の検証と、ユーザーによる確認を追加
数値が矛盾(参考文献 40 件/30-50 件、直近の文献 60%/80%)統一:最低数は設定しない。分野の動きが速い場合は、直近の文献を約 60% とする
ワークフローで scaffold が読み込まれないPhase 4 で assets/proposal_scaffold_{en,zh}.md を明示的に読み込むように変更
AI らしさが出る文のテンプレートを例として提示削除し、「LLM らしい表現を避ける」ための指針を追加
アウトラインの承認が暗黙的「你看着办」への対応を定め、明確な必須条件に変更
Task ツールが宣言されているが未使用、WebFetch がないTask を削除し、WebFetch を追加
冠動脈イメージングの例ばかり分野横断的な例を増やし、計算・ML 用のサブテンプレートを追加
scaffold では貢献点が箇条書きだが、文章を優先するルールがあるscaffold を修正し、貢献点や意義を文章で示すように変更

v2.0.1 の強化:v2.0.0 で「AI らしさが出るテンプレートを削除」した際、WRITING_STYLE_GUIDE だけが整理され、STRUCTURE_GUIDE、DOMAIN_TEMPLATES、中国語 scaffold では禁止された書き出しが引き続き推奨されていました。これらを整理し、Phase 5 に AI らしい表現を検索するゲートを追加しました。中国語 scaffold は、現実的な文字数を用いた GB/T 7714 順序符号方式に全面的に切り替えました。引用ゲートと pandoc 変換を実際に実行できるよう、使用可能なツールに Bash を追加しました。国自然/NSF の適用範囲は、説明とルーティングで同じ内容を明記しました。Phase 2 では、コーパス構築を重複して行わず、文献検索スキルに振り分けるようにしました。

コメント