grant-proposal

研究助成金申請書：研究アイデアから採択可能な申請書へ

各レビュアースロットの前に、選択可能なレビュアーに従ってください： 呼び出し元を解決 → .aris/reviewer.json → Claude Code のデフォルト（Codex MCP） reviewer_route.py を正規のヘルパーリゾルバー経由で使用し、この スロットのティア、新しいコンテキスト、ソース／画像入力、決定論的ゲートを維持します。 以下の Codex の例／固定設定は backend=codex にのみ適用されます。それ以外のルートでは、 それぞれの初回呼び出し／応答の契約を使用します。ルートと実際に返された ID を保存してください。 選択したレビュアーを利用できない場合は REVIEW_UNAVAILABLE とします。実際の ファミリー／完了状況／範囲に基づいて採択を判定してください。 呼び出し元によるレビュアー／モデル／effort の上書き設定は、レビュアーを含む子処理に 引き継いでください。生成ワーカーに変更はありません。

以下に基づいて研究助成金申請書を作成します：$ARGUMENTS

概要

このスキルは、検証済みの研究アイデアを、構成が整ったレビュアー向けの研究助成金申請書に仕上げます。サブスキルを連携させ、助成金申請に特化したパイプラインを構成します。

/research-lit → /novelty-check → [structure design] → [draft] → /research-review → [revise] → GRANT_PROPOSAL.md
  (survey)      (verify gap)     (aims + matrix)     (prose)    (panel review)     (fix)      (done!)

これは並列ブランチであり、直線的な Workflow 1→1.5→2→3 パイプラインの一部ではありません。 /idea-discovery で検証済みのアイデアが得られた後、次のいずれかを選べます：

• /experiment-bridge → /auto-review-loop → /paper-writing に進む（実装して公開する）
• /grant-proposal に進む（まず資金獲得の申請書を作成し、採択後に実装する）

                    ┌→ /experiment-bridge → /auto-review-loop → /paper-writing  (publish track)
/idea-discovery ────┤
                    └→ /grant-proposal → [get funded] → /experiment-bridge → ...  (funding track)

研究助成金申請書では、完了した研究（結果＋主張）ではなく、今後の研究（実現可能性＋可能性）を論じます。このスキルでは、研究助成金申請書に固有の要件、つまり論旨の構成、レビュアー向けの構成、予算の正当化、スケジュールの策定、助成機関ごとの書式に対応します。

定数

• GRANT_TYPE = KAKENHI — 既定の助成金種別です。対応：KAKENHI、NSF、NSFC、ERC、DFG、SNSF、ARC、NWO、GENERIC。引数で上書きできます（例：/grant-proposal "topic — NSF"）。
• GRANT_SUBTYPE = auto — 助成機関内のサブタイプです。例：KAKENHI の Start-up／Wakate／Kiban-B、NSFC の Youth／Excellent-Youth／Distinguished／Overseas／Key、NSF の CAREER／CRII／Standard。引数から自動検出し、検出できない場合は最も一般的なサブタイプを使用します。
• REVIEWER_MODEL = gpt-6-astra — 申請書のレビューに Codex MCP 経由で使用するモデルです。backend=codex の場合は、OpenAI モデル（例：gpt-6-astra、gpt-6.1-sol）を使用します。
• OUTPUT_FORMAT = markdown — 出力形式です。対応形式：markdown、latex。LaTeX では、利用可能な場合に助成金申請用テンプレートを使用します。
• MAX_REVIEW_ROUNDS = 2 — 最終確定までに行う外部レビューと修正のサイクルの最大数です。
• OUTPUT_DIR = grant-proposal/ — 生成した申請書ファイルの保存先ディレクトリです。
• LANGUAGE = auto — 出力言語です。助成金種別から自動検出します：KAKENHI→日本語、NSF→英語、NSFC→中国語、ERC→英語、DFG→英語（またはドイツ語）、SNSF→英語、ARC→英語、NWO→英語。必要に応じて明示的に上書きできます。
• AUTO_PROCEED = false — 各チェックポイントでは、次に進む前に必ずユーザーの明示的な確認を待ちます。研究助成金申請書では、すべての段階で PI 固有の判断が必要です。ユーザーが完全自律モードを明示的に求めた場合に限り、true に設定します。

💡 これらは既定値です。たとえば、/grant-proposal "topic — NSF CAREER, latex output" や /grant-proposal "topic — NSFC Youth, language: English" のようにスキルに伝えて上書きできます。

オプション：スタイル参照（— style-ref: <source>、オプトイン）

PI が、過去に成功した参考にしたい提案書や論文に合わせて、提案書の構成上のレイアウト（セクション順の傾向、段落の長さ、図表の密度、引用スタイル）を調整できるようにします。デフォルトでは OFF — ユーザーが — style-ref を指定しない場合、従来と異なる動作はしません。

— style-ref: <source> が $ARGUMENTS に含まれている場合に限り、ドラフトの作成前にまずヘルパーを実行します。

# Resolve $STYLE_HELPER via the canonical strict-safe chain (see
# shared-references/integration-contract.md §2). Policy A — gate:
# unresolved helper means --style-ref cannot be satisfied, so abort.
cd "$(git rev-parse --show-toplevel 2>/dev/null || pwd)" || exit 1
if [ -z "${ARIS_REPO:-}" ] && [ -f .aris/installed-skills.txt ]; then
    ARIS_REPO=$(awk -F'\t' '$1=="repo_root"{print $2; exit}' .aris/installed-skills.txt 2>/dev/null) || true
fi
if [ -z "${ARIS_REPO:-}" ] && [ -f "$HOME/.aris/repo" ]; then
    ARIS_REPO=$(cat "$HOME/.aris/repo" 2>/dev/null) || true
fi
STYLE_HELPER=".aris/tools/extract_paper_style.py"
[ -f "$STYLE_HELPER" ] || STYLE_HELPER="tools/extract_paper_style.py"
[ -f "$STYLE_HELPER" ] || { [ -n "${ARIS_REPO:-}" ] && STYLE_HELPER="$ARIS_REPO/tools/extract_paper_style.py"; }
[ -f "$STYLE_HELPER" ] || {
  echo "ERROR: extract_paper_style.py not resolved at .aris/tools/, tools/, \$ARIS_REPO/tools/, or via ~/.aris/repo." >&2
  echo "       Fix: rerun bash tools/install_aris.sh or smart_update.sh (refreshes ~/.aris/repo), export ARIS_REPO, or copy the helper to tools/." >&2
  echo "       --style-ref cannot be satisfied; aborting." >&2
  exit 1
}
STYLE_STATUS=0
CACHE=$(python3 "$STYLE_HELPER" --source "<source>") || STYLE_STATUS=$?
case "$STYLE_STATUS" in
  0) ;;                                       # use $CACHE/style_profile.md as structural guidance
  2) echo "warning: style-ref skipped (missing optional dep)" >&2 ;;
  3) echo "error: --style-ref source failed; aborting proposal" >&2 ; exit 1 ;;
  *) echo "error: helper failed unexpectedly; aborting proposal" >&2 ; exit 1 ;;
esac

利用可能なソース：ローカルの TeX ディレクトリ／ファイル、ローカル PDF、arXiv ID、http(s) URL。Overleaf の URL／ID は受け付けません。まずプロジェクトをローカルにクローンし、ローカルパスを指定してください。

厳守事項（契約の全文は tools/extract_paper_style.py の docstring を参照）：

• style_profile.md を使って、段落の長さの傾向、図表の上限、引用の密度を合わせてください。研究費種別で定められたセクション順（KAKENHI の 研究目的 → 研究計画・方法 → 準備状況、NSF の Intellectual Merit → Broader Impacts など）が常に優先されます。機関のテンプレートを優先し、スタイル参照は副次的な構成のみを調整します。
• キャッシュ経由で参照できるものから、提案書の文章、主張、ビジョンに関する記述、予算項目を決してコピーしないでください。参照先は他者の採択済み提案書である可能性があります。文章を流用すると、盗用のリスクがあります。
• ドラフトを評価する際、— style-ref（またはキャッシュの内容）を GPT-6-Astra のレビュアーサブエージェントに決して渡さないでください。提案書そのものの価値で評価する必要があります。

研究費種別の仕様

KAKENHI（日本 — JSPS）

項目	詳細
セクション	研究目的（研究目的）、研究計画・方法（研究計画・方法）、準備状況（準備状況）、人権の保護（該当する場合の倫理）
種別	基盤研究 A/B/C（基盤）、若手研究、研究活動スタート支援、国際共同研究、学術変革領域、挑戦的研究、DC1/DC2（博士課程）
言語	日本語（英語の専門用語も使用可能）
審査基準	学術的重要性、独創性、研究計画の妥当性、研究遂行能力（PI の能力）
慣習	年度ごとの明確なマイルストーン（1年目／2年目）、計画に予算の根拠を組み込む、社会的意義を強調する、具体的な期待成果（論文、データセット）、関連する採択済み研究の確認には KAKEN データベースを参照

NSF（米国）

項目	詳細
セクション	Project Summary（1ページ）、Project Description（最大15ページ）、References Cited、Biographical Sketch、Budget Justification、Data Management Plan
種別	Standard Grant、CAREER（若手研究者向け）、CRII（研究開始支援）、RAPID、EAGER
言語	英語
審査基準	Intellectual Merit、Broader Impacts
慣習	研究目的に基づく構成（Aim 1/2/3）、予備データが強く期待される、Broader Impacts は具体的かつ明確に記述する（一般的な「社会に貢献する」では不十分）、Results from Prior Support セクション

NSFC（中国 — 国家自然科学基金）

項目	詳細
セクション	立项依据（根拠と意義）、研究内容（内容）、研究目标（目標）、研究方案（計画と方法）、可行性分析（実現可能性）、创新性（独創性）、预期成果（期待される成果）、研究基础（研究代表者の基盤と実績）
サブタイプ	面上项目（一般プログラム）— 科学的課題と研究の蓄積を重視；青年基金（若手研究者基金）— 年齢35歳以下、独立性と成長の可能性を重視；优秀青年基金/优青（優秀若手研究者基金）— 年齢38歳以下、卓越した業績を重視；杰出青年基金/杰青（優れた若手研究者基金）— 年齢45歳以下、国際的に主導する水準を重視；海外优青（海外優秀若手研究者基金）— 海外経験と帰国後の貢献計画を重視；重点项目（重点プログラム）— 体系的で掘り下げた研究を重視
言語	中国語
審査基準	科学意义（科学的重要性）、创新性（独創性）、可行性（実現可能性）、研究队伍（研究チームの適格性）
文化的な慣例	国际前沿（国際的な最先端）における位置付けを重視し、詳細な実現可能性分析、申請者の過去の出版物の明示的な引用が求められます。研究基础セクションは、研究代表者の能力を示すうえで重要です。

ERC（EU — 欧州研究会議）

項目	詳細
セクション	Extended Synopsis（5ページ）、Scientific Proposal Part B2（15ページ）
サブタイプ	Starting Grant（博士号取得後2～7年）、Consolidator Grant（博士号取得後7～12年）、Advanced Grant（実績のある研究リーダー）
言語	英語
審査基準	画期的な性質、方法論、研究代表者の実績
文化的な慣例	「高リスク・高リターン」を重視し、WP／成果物／マイルストーンを含む方法論の表、ガントチャートが求められます。また、研究代表者の実績を伝える力強い記述が重要です。

DFG（ドイツ — ドイツ研究振興協会）

項目	詳細
セクション	研究の現状、目的、研究計画、参考文献、履歴書
言語	英語またはドイツ語
審査基準	科学的品質、独創性、実現可能性、研究代表者の適格性

SNSF（スイス — スイス国立科学財団）

項目	詳細
セクション	概要、研究計画、スケジュール、予算
言語	英語
審査基準	科学的関連性、独創性、実現可能性、実績

ARC（オーストラリア — オーストラリア研究会議）

項目	詳細
セクション	プロジェクトの説明、実現可能性、便益、予算
言語	英語
審査基準	研究の質、実現可能性、オーストラリアへの便益

NWO（オランダ — オランダ研究会議）

項目	詳細
セクション	概要、提案する研究、知識の活用
言語	英語
審査基準	科学的品質、革新性、知識の活用

GENERIC

上記に記載されていない助成金を対象とします。ユーザーは引数でセクション名、ページ数の上限、審査基準を指定します。

/grant-proposal "topic — GENERIC, sections: Background|Methods|Impact, language: English"

状態の永続化（簡潔な復旧）

助成金申請書の作成は長時間に及ぶタスクであり、コンテキストの圧縮が発生する場合があります。各フェーズの後に、状態を grant-proposal/GRANT_STATE.json に保存します。

{
  "phase": 2,
  "grant_type": "KAKENHI",
  "grant_subtype": "Start-up",
  "language": "Japanese",
  "codex_thread_id": "019cfcf4-...",
  "gap_statement": "...",
  "aims_count": 3,
  "status": "in_progress",
  "timestamp": "2026-03-18T15:00:00"
}

各フェーズの終了時にこのファイルを書き込んでください。 呼び出し時に、このファイルを確認してください。

• ファイルが存在しない場合、または status: "completed" の場合 → 新規に開始
• status: "in_progress" で、開始から24時間以内の場合 → 保存されたフェーズから再開（コンテキストを復元するため GRANT_PROPOSAL.md と GRANT_REVIEW.md を読み込みます）
• 24時間を超えている場合 → 新規に開始（古い状態）

完了時に "status": "completed" を設定します。

ワークフロー

フェーズ 0：入力の解析とコンテキストの収集

$ARGUMENTS を解析して、次の情報を抽出します。

1. 研究の方向性／アイデア — 既存のファイルを参照している場合と、自由記述の場合があります
2. 助成金の種類 — キーワードから判定します（例：「科研費」→KAKENHI、「NSF」→NSF、「国自然」→NSFC、「基金」→NSFC）
3. 助成金のサブタイプ — キーワードから判定します（例：「Start-up」、「若手」、「青年」、「CAREER」、「优青」、「海外优青」）
4. 上書き設定 — 出力形式、言語、レビュー回数

次に、プロジェクトディレクトリからコンテキストを収集します。

1. idea-stage/IDEA_REPORT.md が存在する場合は読み込みます（/idea-discovery によるもの）。見つからない場合は ./IDEA_REPORT.md を読み込みます
2. refine-logs/FINAL_PROPOSAL.md が存在する場合は読み込みます（/research-refine によるもの）
3. refine-logs/EXPERIMENT_PLAN.md が存在する場合は読み込みます（/experiment-plan によるもの）
4. review-stage/AUTO_REVIEW.md が存在する場合は読み込みます（/auto-review-loop によるもの。以前のレビューコメントは助成金申請において貴重です）。見つからない場合は ./AUTO_REVIEW.md を読み込みます
5. NARRATIVE_REPORT.md または STORY.md が存在する場合は読み込みます
6. 既存の文献メモやサーベイ文書を読み込みます
7. ユーザーの論文リストを探します（例：publications.md、cv.md、bio.md、CV.pdf）
8. grant-proposal/GRANT_STATE.json を確認します（以前の中断状態から再開するため）

コンテキストが不十分な場合：

• 研究アイデアがまったくない → まず /idea-discovery の実行を提案します
• 文献サーベイがない → フェーズ 1 で /research-lit をインライン実行します
• 論文リストがない → 研究代表者の適格性に関するセクションに [TODO: Add publications] のプレースホルダーを残します
• review-stage/AUTO_REVIEW.md がある → レビュアーのフィードバックを抽出し、実現可能性の説明を強化するために活用します

フェーズ 1：文献と研究動向における位置づけ

提案書の根拠となる実在の文献を調べるため /research-lit を実行し、次に競合する採択済みプロジェクトを検索します。

/research-lit "$ARGUMENTS"

この処理の内容：

• /research-lit をすでに実行済みでメモがある場合は、既存のサーベイを再利用します
• それ以外の場合は、複数の情報源（arXiv、Scholar、Zotero、ローカルの PDF）を対象に文献を検索するため、/research-lit を実行します
• WebSearch を使って、同じ分野の採択済みプロジェクトを検索します。
  • KAKENHI → KAKEN データベース（https://kaken.nii.ac.jp/）
  • NSF → NSF Award Search（https://www.nsf.gov/awardsearch/）
  • NSFC → NSFC の採択済みプロジェクト
  • その他の助成機関 → 一般的なウェブ検索
• 競合する研究グループと、その最近の論文を特定します
• 提案する研究の方向性に /novelty-check を実行し、研究上のギャップが実在することを確認します。

  /novelty-check "[proposed gap statement]"
  

• 提案書で最も重要な一文となるギャップの記述を作成します。

  "Despite progress in [X], [specific gap] remains unaddressed because [reason].
  This proposal addresses this by [approach], which will [expected impact]."
  

🚦 チェックポイント： 研究動向の概要とギャップの記述をユーザーに提示します。

📚 Literature & landscape analysis complete:
- [key findings from literature]
- [competing funded projects found]
- Gap statement: "[the gap statement]"

Does this accurately capture the positioning? Should I adjust before designing the proposal structure?

⛔ ここで停止し、ユーザーの応答を待ちます。 ユーザーが AUTO_PROCEED=true を明示的に設定していない限り、自動で次に進んではいけません。

ユーザーが選択できる内容：

• **「go」または「ok」**と返信 → 現在の位置づけのままフェーズ 2 に進みます
• 調整内容を返信（例：「X に重点を置いて」「ギャップでは Y を強調して」）→ 内容を調整して再提示します
• **「stop」**と返信 → スキルを終了し、現在の進捗を grant-proposal/DRAFT_NOTES.md に保存します

状態： ギャップの記述とともに、phase: 1 を含む GRANT_STATE.json を書き込みます。

フェーズ 2：ナラティブ構成と目標の設計

文章を書く前に、提案書の論理構成を設計します。

2.1 具体的目標を定義する（2～4 件）

各目標は次の条件を満たす必要があります。

• それぞれ独立した価値がある — 1 つの目標が失敗しても、ほかの目標から論文として発表可能な成果が得られます
• 論理的につながっている — 目標 1 が目標 2 を可能にし、目標 2 が目標 3 に情報を与えます
• 具体的な成果物がある — 各目標を具体的な成果（論文、データセット、ツール、ベンチマーク）に対応づけます
• 予算と期間内に実施可能である

2.2 主張・目標・根拠のマトリックスを作成する

| Aim | Key Claim | Preliminary Evidence | Proposed Validation | Risk Level | Deliverable |
|-----|-----------|---------------------|--------------------|-----------:|-------------|
| Aim 1 | [claim] | [pilot data, prior work] | [experiments] | LOW | [paper, dataset] |
| Aim 2 | [claim] | [theoretical basis] | [experiments] | MEDIUM | [paper, tool] |

2.3 ナラティブの流れを設計する

助成金申請書は、論文とは根本的に異なる流れで構成します。

Problem → Why Now → What We Propose → Why It Will Work → What We Will Deliver
         (not: Problem → Method → Results → Implications)

• 課題：どのようなギャップが存在し、なぜ重要なのか（科学的・社会的な観点）
• なぜ今なのか：どのような最近の進展によって、今が適切な時期となっているのか（新たなデータ、新たな手法、新たなニーズ）
• 提案内容：具体的な研究目標とアプローチ
• 成功の見込み：予備データ、PIの実績、チームの専門性、実現可能性の根拠
• 成果物：具体的な成果、スケジュール、予定される論文

2.4 スケジュールとマイルストーン

年単位（または四半期単位）の計画を設計します。

### Year 1
- Q1-Q2: [Aim 1 tasks]
- Q3-Q4: [Aim 1 completion + Aim 2 start]
- Expected outputs: [papers, datasets]

### Year 2
- Q1-Q2: [Aim 2 completion + Aim 3]
- Q3-Q4: [Aim 3 completion + synthesis]
- Expected outputs: [papers, tools, final report]

2.5 構成のレビュー

ドラフト作成前に、/research-review を実行して提案書の構成について批判的なフィードバックを得ます。

/research-review "[GRANT_TYPE] [GRANT_SUBTYPE] proposal structure:
Gap: [gap statement]
Aims: [aims list with claims-evidence matrix]
Timeline: [timeline]
— reviewer persona: [GRANT_TYPE] review panelist"

このステップの内容：

• GPT-6-Astra xhigh が論文査読者ではなく、助成金審査委員として評価します
• 研究目標の独立性、ナラティブの流れ、リスクの特定、スケジュールの現実性を評価します
• 審査員が最も懸念する点を1つ特定します
• 重要度の高い順に、実行可能な修正案を提示します

ドラフト作成に進む前に、構成に関するフィードバックを反映します。

🚦 チェックポイント： 提案書の構成をユーザーに提示します。

🏗️ Proposal structure designed:
- Gap: [gap statement]
- Aim 1: [title] — Risk: LOW
- Aim 2: [title] — Risk: MEDIUM
- Aim 3: [title] — Risk: LOW
- Timeline: [summary]
- Reviewer feedback: [key points from GPT-6-Astra]

Proceed to section drafting? Or adjust the structure?

⛔ ここで必ず停止してください。これが最も重要なチェックポイントです。提案書の構成が、その後のすべてを決定します。

ユーザーが選べる操作：

• 「go」 または 「ok」 と返信 → フェーズ3（セクションのドラフト作成）に進みます
• 構成の変更を返信（例：「Aim 2と3を統合」「Xに関する研究目標を追加」「研究目標を2つに減らす」）→ 構成を再設計して、再提示します
• 「back」 と返信 → フェーズ1に戻り、ギャップや位置付けを調整します
• 「stop」 と返信 → 現在の構成を grant-proposal/DRAFT_NOTES.md に保存します

状態：phase: 2、研究目標の概要、Codex の threadId を含む GRANT_STATE.json を作成します。

フェーズ3：セクションのドラフト作成

助成金の種類に応じたテンプレートに従って、各セクションを作成します。アウトラインやプレースホルダーではなく、完全な文章を作成してください。

このステップの内容：

• 必要なすべてのセクションを、助成機関固有の表現や文体で作成します
• アイデア段階の資料である IDEA_REPORT.md、FINAL_PROPOSAL.md、文献メモから内容を取り込みます
• ユーザーが希望した場合は、/paper-illustration を使って図を作成します
• [TODO] はPI固有の情報に限り、予算額には [AMOUNT] を使います
• grant-proposal/GRANT_PROPOSAL.md を出力します

ドラフト作成の順序（ナラティブの一貫性を最適化）

1. Specific Aims / Research Objective — 助成金申請書の「要旨」です。最初に作成し、最後に仕上げます。
2. Background / Significance / State of the Art — 課題とギャップを明確にします。
3. Research Plan / Methods — 実現可能性の根拠を含め、研究目標ごとに記述します。
4. 図 — 主要な図を作成します（下記参照）。
5. スケジュールとマイルストーン — 年ごとの成果物を示します。
6. PI Qualification / Preparation Status — 実績、チーム、インフラを記述します。
7. Budget Justification — 説明文のみを作成し、金額は [AMOUNT] のプレースホルダーのままにします。
8. Broader Impacts / Societal Significance — 助成金の種類で必要な場合に記述します。

図の作成

明確な図は助成金申請書に大いに役立ちます。以下の図をSVGまたはmatplotlibで作成し、grant-proposal/figures/ に保存します。

1. 全体構成図 / Overview Diagram — 研究目標（Aim 1 → Aim 2 → Aim 3）、共有リソース（参加者、刺激、パイプライン）、成果物の関係を示します。最も重要な図です。
2. 実験パラダイム図 / Experimental Paradigm — 各パラダイムを視覚的に示す図です（刺激のタイミング、条件、EEG記録）。
3. 年次計画 / Timeline Gantt Chart — 成果物を含む年単位（またはH1/H2）のマイルストーンを示します。

論文掲載に適した品質の図をAIで作成するには、/paper-illustration を実行します。

/paper-illustration "Overview diagram showing [aims relationship + shared resources] for grant proposal"

フローチャートやガントチャートなど、より簡単な図は、コードを使ってSVGまたはmatplotlibで直接作成します。

🚦 図のチェックポイント： 作成を始める前に、どの図が必要かユーザーに確認します。

🎨 The following figures would strengthen this proposal:
1. 全体構成図 / Overview — aims relationship + shared resources
2. 実験パラダイム図 / Paradigm — stimulus timing + conditions
3. 年次計画 / Gantt — timeline with milestones

Which should I generate? (e.g., "1 and 3", "all", "skip")

⛔ ユーザーの回答を待ってください。 希望された図のみを作成します。

Grant-Specific Drafting Guidelines

KAKENHI:

• Write in formal Japanese academic style (である調, not です/ます調)
• Use 「」for Japanese quotations, bold for emphasis
• Structure: 研究の学術的背景 → 研究期間内に何をどこまで明らかにするか → 本研究の学術的な特色・独創性
• Include explicit 年次計画 (yearly plan) with concrete milestones
• Emphasize 社会的意義 (societal significance)
• Reference related KAKEN-funded projects to show awareness of the field

NSF:

• Write in clear, direct English
• Use Aim-based structure with bold headings
• Preliminary data paragraphs for each Aim (with figure references)
• Broader Impacts must be concrete: specific outreach activities, broadening participation plans
• Include Results from Prior Support (if PI has prior NSF funding)

NSFC:

• Write in formal Chinese academic style
• 立项依据 must position work at 国际前沿 (international frontier)
• 创新性 section must list numbered innovation points (创新点)
• 研究基础 must cite PI's own publications (with IF and citations if possible)
• 可行性分析 must address: technical feasibility, team capability, time feasibility, equipment/conditions

ERC:

• Write a compelling "high-risk/high-gain" narrative
• Extended Synopsis must be self-contained and compelling
• Include Work Package table with deliverables and milestones
• Gantt chart (describe in text, or generate as figure)

For Each Section

1. Pull relevant content from idea-stage/IDEA_REPORT.md, FINAL_PROPOSAL.md, literature notes
2. Write complete prose — no [TODO] except for PI-specific information
3. Include figure/table placeholders where appropriate (e.g., [Figure 1: System architecture])
4. Cite references properly — use citation keys, will build bibliography later
5. Match the agency's tone and style — formal Japanese for KAKENHI, direct English for NSF, etc.

Phase 4: External Review

Invoke /research-review on the complete draft for grant-type-specific evaluation:

/research-review "Read the grant review bundle at grant-proposal/codex_panel_review_bundle_round_1.md and evaluate it as a [GRANT_TYPE] [GRANT_SUBTYPE] review panelist using the official criteria."

What this does:

• GPT-6-Astra xhigh acts as a grant review panelist
• Scores each section 1-5 using agency-specific criteria
• Identifies fatal flaws and recommends funding/revisions/rejection
• Provides ranked action items for improvement
• All feedback saved to grant-proposal/GRANT_REVIEW.md

If the selected reviewer is unavailable, record REVIEW_UNAVAILABLE in GRANT_REVIEW.md. The proposal remains an explicitly unreviewed draft; do not switch providers automatically.

If /research-review is invoked (preferred), it handles the Codex call internally. If calling Codex directly (e.g., to maintain thread context from Phase 2):

Round 1 (full draft review):

Write grant-proposal/codex_panel_review_bundle_round_1.md containing the criteria below plus the absolute path to grant-proposal/GRANT_PROPOSAL.md, then keep the Codex MCP prompt short:

Resolve this reviewer slot first; the following is the backend=codex example.

mcp__codex__codex-reply:
  threadId: [from Phase 2]
  # inherits the thread's model/effort — do not re-send
  prompt: |
    Read the grant review bundle at <absolute path to
    grant-proposal/codex_panel_review_bundle_round_1.md> and follow all
    instructions in it.

Bundle contents:

    Review this complete [GRANT_TYPE] [GRANT_SUBTYPE] proposal draft.

    Act as a [GRANT_TYPE] review panelist. Evaluate using the official criteria:

    [INSERT GRANT-TYPE-SPECIFIC CRITERIA — see Grant Type Specifications above]

    For each section:
    1. Score 1-5 (5 = excellent)
    2. Strongest aspect
    3. Most critical weakness
    4. Specific fix suggestion (actionable, not vague)

    Overall assessment:
    - Would you recommend funding? (Yes / Yes with revisions / No)
    - Single most impactful change to improve funding chances?
    - Any fatal flaws?

    Proposal draft path (read this file yourself): <absolute path to
    grant-proposal/GRANT_PROPOSAL.md>

Round 2+ (after revisions):

If MAX_REVIEW_ROUNDS > 1 and revisions were applied:

Write grant-proposal/codex_panel_review_bundle_round_N.md containing the change log, any raw diff / changed-file paths worth inspecting, and the absolute path to the current grant-proposal/GRANT_PROPOSAL.md, then reuse the same short MCP prompt pattern:

Resolve this reviewer slot first; the following is the backend=codex example.

mcp__codex__codex-reply:
  threadId: [saved from Round 1]
  # inherits the thread's model/effort — do not re-send
  prompt: |
    Read the grant review bundle at <absolute path to
    grant-proposal/codex_panel_review_bundle_round_N.md> and follow all
    instructions in it.

Bundle contents:

    [Round N review of revised [GRANT_TYPE] [GRANT_SUBTYPE] proposal]

    Since your last review, I have applied the following changes:
    1. [Change 1]: [what was done]
    2. [Change 2]: [what was done]
    3. [Change 3]: [what was done]

    Please re-evaluate. Same format: section scores, overall assessment, remaining weaknesses.
    Focus on whether the CRITICAL and MAJOR issues from Round 1 have been adequately addressed.

    Revised proposal path (read this file yourself): <absolute path to
    grant-proposal/GRANT_PROPOSAL.md>

Phase 5: Revision & Output

5.1 Apply Reviewer Feedback

Parse reviewer feedback into severity levels:

• CRITICAL — fatal flaws that would lead to rejection. Fix immediately.
• MAJOR — significant weaknesses. Fix before submission.
• MINOR — suggestions for improvement. Fix if time allows.

Implement CRITICAL and MAJOR fixes. If MAX_REVIEW_ROUNDS > 1, re-submit for another round via mcp__codex__codex-reply.

5.2 Generate Output

Markdown output (default):

grant-proposal/
├── GRANT_PROPOSAL.md          # Complete proposal, all sections
├── GRANT_REVIEW.md            # Review history and reviewer feedback
├── GRANT_STATE.json           # State persistence file
├── figures/                   # Generated diagrams (if any)
└── references.bib             # Bibliography (if citations were used)

LaTeX output (when OUTPUT_FORMAT = latex):

grant-proposal/
├── main.tex                   # Master file
├── sections/
│   ├── aims.tex               # Specific Aims / Research Objective
│   ├── background.tex         # Background / Significance
│   ├── research_plan.tex      # Research Plan / Methods
│   ├── timeline.tex           # Timeline & Milestones
│   ├── pi_qualification.tex   # PI Qualification / Track Record
│   └── budget.tex             # Budget Justification (if applicable)
├── references.bib
└── figures/                   # Any generated diagrams

5.3 最終確認

完了とする前に、次の点を確認してください。

• 助成金の種類で求められるすべてのセクションがそろっており、内容も完成している
• ギャップを示す記述が明確で、提案書の早い段階に記載されている
• 各目的がそれぞれ独自の価値を持ち、論理的につながっている
• 年ごとの具体的なマイルストーンと成果物がタイムラインに含まれている
• PI の資格に関するセクションに内容がある（または明確な [TODO] プレースホルダーがある）
• 予算の説明に [AMOUNT] プレースホルダーを使用している（架空の金額は記載しない）
• 助成金の種類に合った言語になっている（KAKENHI は日本語、NSFC は中国語など）
• PI 固有の情報を除き、未処理の [TODO] マーカーが残っていない
• 参考文献が実在する（幻覚による引用がない）
• レビューのフィードバックに対応している（CRITICAL と MAJOR の項目）

🚦 最終チェックポイント： 完成した提案書の要約を提示してください。

📝 Grant proposal draft complete:
- Type: [GRANT_TYPE] [GRANT_SUBTYPE]
- Language: [language]
- Aims: [N] aims covering [summary]
- Timeline: [N] years
- Review score: [summary from GPT-6-Astra]
- Output: grant-proposal/GRANT_PROPOSAL.md

Files saved to grant-proposal/. Please review and customize:
1. PI qualification section (add your publications and track record)
2. Budget amounts (replace [AMOUNT] placeholders)
3. Any [TODO] markers for personal information

What would you like to do next?
- "figures" → generate proposal diagrams
- "review again" → run another round of external review
- "latex" → convert to LaTeX format
- "done" → finalize

主なルール

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

• 予算額を捏造しないでください。 予算の説明文のみを作成します。具体的なドル／円／元／ユーロの金額は、ユーザーが記入できるよう [AMOUNT] プレースホルダーのままにしてください。

• PI の情報を捏造しないでください。 論文リストがない場合は、[TODO: Add publications] プレースホルダーを残してください。論文、助成金、資格を決して創作しないでください。

• 引用を幻覚で作り出さないでください。 文献調査で確認した参考文献を使用してください。確証のない引用には [VERIFY] を付けてください。

• 助成金申請書は論文とは異なります。 助成金申請書では今後の研究（実現可能性＋可能性）を主張します。論文では完了した研究（結果＋主張）を述べます。「何を発見したか」ではなく、「何を行うか」「なぜ実現できるか」を強調してください。

• 各目的はそれぞれ独立して価値を持つ必要があります。 目的 2 が失敗しても、目的 1 と目的 3 から論文として発表できる成果が得られるようにしてください。

• 予備データによってリスクを低減します。 実現可能性を示すパイロット結果、既存データセット、または過去の論文があれば含めてください。

• 審査者に配慮した構成にしてください。 重要な文を太字にしてください。分かりやすさのために番号付きリストを使い、審査者が容易に読めるようにしてください。

• 文化的規範も重要です。 KAKENHI では社会的意義、NSF では Broader Impacts、NSFC では国際的な最先端の研究領域における位置づけが求められます。これらが欠けていると、審査者に懸念を抱かせます。

• Feishu の通知は任意です。 ~/.claude/feishu.json が存在する場合は、各フェーズの切り替わりで checkpoint を、最終出力時に pipeline_done を送信してください。存在しない場合は、何もせずにスキップしてください。

パラメーターの引き継ぎ

パラメーターは — 区切りでインライン指定できます。呼び出し時にサブスキルへ引き継がれます。

/grant-proposal "topic — KAKENHI Start-up, sources: zotero, arxiv download: true"

パラメーター	デフォルト	説明	引き継ぎ先
grant type	KAKENHI	助成機関（KAKENHI/NSF/NSFC/ERC/DFG/SNSF/ARC/NWO/GENERIC）	—
grant subtype	auto	サブタイプ（Start-up/Wakate/CAREER/Youth など）	—
output format	markdown	markdown または latex	—
language	auto	出力言語の指定	—
max review rounds	2	外部レビューのサイクル数	—
sources	all	文献の情報源	→ /research-lit
arxiv download	false	arXiv の PDF をダウンロードする	→ /research-lit
reviewer model	gpt-6-astra	Codex のレビュー用モデル	→ Codex MCP
auto proceed	false	チェックポイントをスキップする	—

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

このスキルで使用するサブスキル

サブスキル	フェーズ	目的
/research-lit	1	文献調査（まだ実施されていない場合）
/novelty-check	1	ギャップが実在するか確認する
/research-review	2, 4	構成のレビュー＋草稿全体のレビュー
/paper-illustration	3	提案書の図を作成する（任意）

助成申請トラック（このスキルの主な用途）

/idea-discovery "direction"              ← Workflow 1: find validated ideas
/research-refine "idea"                  ← sharpen the method
/grant-proposal "idea — KAKENHI"         ← this skill: write the grant proposal
                                          ← [submit & get funded]
/experiment-bridge                       ← implement experiments with funding
/auto-review-loop "results"              ← Workflow 2: iterate until submission-ready
/paper-writing                           ← Workflow 3: write the paper

論文発表トラック（このスキルをスキップ）

/idea-discovery → /experiment-bridge → /auto-review-loop → /paper-writing → submit

出力プロトコル

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

• 出力バージョニングプロトコル — まずタイムスタンプ付きファイルを書き込み、その後、固定名のファイルにコピーします
• 出力マニフェストプロトコル — すべての出力を MANIFEST.md に記録します
• 出力言語プロトコル — プロジェクトの言語設定を尊重します