yjh051108/mmkit/grant-proposal

Grant Proposal: From Research Ideas to Fundable Application

Draft a grant proposal based on: $ARGUMENTS

Overview

This skill turns validated research ideas into a structured, reviewer-ready grant proposal. It chains sub-skills into a grant-specific pipeline:

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

This is a parallel branch, not part of the linear Workflow 1→1.5→2→3 pipeline. After /idea-discovery produces validated ideas, the user can either:

• Go to /experiment-bridge → /auto-review-loop → /paper-writing (implement & publish)
• Go to /grant-proposal (write funding application first, then implement after funding)

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

Grant proposals argue for future work (feasibility + potential), not completed work (results + claims). This skill handles the unique requirements of grant writing: narrative arc design, reviewer-facing structure, budget justification, timeline planning, and agency-specific formatting.

Constants

• GRANT_TYPE = `KAKENHI` — Default grant type. Supported: KAKENHI, NSF, NSFC, ERC, DFG, SNSF, ARC, NWO, GENERIC. Override via argument (e.g., /grant-proposal "topic — NSF").
• GRANT_SUBTYPE = `auto` — Sub-type within the grant agency. Examples: KAKENHI Start-up/Wakate/Kiban-B; NSFC Youth/Excellent-Youth/Distinguished/Overseas/Key; NSF CAREER/CRII/Standard. Auto-detected from argument or defaults to the most common sub-type.
• REVIEWER_MODEL = `外部评审模型` — Model used via external reviewer for proposal review. Configured in reviewer_client.py settings.
• OUTPUT_FORMAT = `markdown` — Output format. Supported: markdown, latex. LaTeX uses grant-specific templates when available.
• MAX_REVIEW_ROUNDS = 2 — Maximum external review-revise cycles before finalizing.
• OUTPUT_DIR = `grant-proposal/` — Directory for generated proposal files.
• LANGUAGE = `auto` — Output language. Auto-detected from grant type: KAKENHI→Japanese, NSF→English, NSFC→Chinese, ERC→English, DFG→English (or German), SNSF→English, ARC→English, NWO→English. Override explicitly if needed.
• AUTO_PROCEED = false — At each checkpoint, always wait for explicit user confirmation before proceeding. Grant proposals require PI-specific judgment at every stage. Set true only if user explicitly requests fully autonomous mode. Note: In non-interactive mode (claude -p), AUTO_PROCEED is always treated as `true` regardless of this setting.

💡 These are defaults. Override by telling the skill, e.g., /grant-proposal "topic — NSF CAREER, latex output" or /grant-proposal "topic — NSFC Youth, language: English".

Grant Type Specifications

KAKENHI (Japan — JSPS)

NSF (US)

NSFC (China — 国家自然科学基金)

ERC (EU — European Research Council)

DFG (Germany — Deutsche Forschungsgemeinschaft)

SNSF (Switzerland — Swiss National Science Foundation)

ARC (Australia — Australian Research Council)

NWO (Netherlands — Dutch Research Council)

GENERIC

For any grant not listed above. User provides section names, page limits, and review criteria via argument:

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

State Persistence (Compact Recovery)

Grant proposal drafting is a long task that may trigger context compaction. Persist state to grant-proposal/GRANT_STATE.json after each phase:

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

Write this file at the end of every phase. On invocation, check for this file:

• If absent or status: "completed" → fresh start
• If status: "in_progress" and within 24h → resume from saved phase (read GRANT_PROPOSAL.md and GRANT_REVIEW.md to restore context)
• If older than 24h → fresh start (stale state)

On completion, set "status": "completed".

Workflow

Phase 0: Input Parsing & Context Gathering

Parse $ARGUMENTS to extract:

1. Research direction/idea — may reference existing files or be a freeform description
2. Grant type — detect from keywords (e.g., "科研費"→KAKENHI, "NSF"→NSF, "国自然"→NSFC, "基金"→NSFC)
3. Grant sub-type — detect from keywords (e.g., "Start-up", "若手", "青年", "CAREER", "优青", "海外优青")
4. Overrides — output format, language, review rounds

Then gather context from the project directory:

1. Read IDEA_REPORT.md if it exists (from /idea-discovery)
2. Read refine-logs/FINAL_PROPOSAL.md if it exists (from /research-refine)
3. Read refine-logs/EXPERIMENT_PLAN.md if it exists (from /experiment-plan)
4. Read AUTO_REVIEW.md if it exists (from /auto-review-loop — prior review feedback is gold for grants)
5. Read NARRATIVE_REPORT.md or STORY.md if they exist
6. Read any existing literature notes or survey documents
7. Scan for the user's publication list (e.g., publications.md, cv.md, bio.md, CV.pdf)
8. Check for grant-proposal/GRANT_STATE.json (resume from prior interrupted run)

If insufficient context exists:

• No research idea at all → suggest running /idea-discovery first
• No literature survey → will invoke /literature-review inline in Phase 1
• No publication list → leave PI qualification section with [TODO: Add publications] placeholders
• Has AUTO_REVIEW.md → extract reviewer feedback and use it to strengthen the feasibility narrative

Phase 1: Literature & Landscape Positioning

Invoke /literature-review to ground the proposal in real literature, then search for competing funded projects:

/literature-review "$ARGUMENTS"

What this does:

• Reuse existing surveys if /literature-review was already run and notes exist
• Otherwise invoke /literature-review for multi-source literature search (arXiv, Scholar, Zotero, local PDFs)
• Search for funded projects in the same area via WebSearch:
• KAKENHI → KAKEN database (https://kaken.nii.ac.jp/)
• NSF → NSF Award Search (https://www.nsf.gov/awardsearch/)
• NSFC → NSFC funded projects
• Other agencies → general web search
• Identify competing groups and their recent publications
• Run /novelty-check on the proposed research direction to verify the gap is real:

`` /novelty-check "[proposed gap statement]" ``

• Build the gap statement — the single most important sentence in the proposal:

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

🚦 Checkpoint: Present the landscape summary and gap statement to the user:

📚 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?

🚦 Checkpoint: If AUTO_PROCEED=false AND running interactively, present the landscape summary and gap statement to the user and wait for response. If AUTO_PROCEED=true or running in non-interactive mode (claude -p), proceed automatically with the current positioning. Log: "AUTO_PROCEED: proceeding with current gap statement."

Options for the user:

• Reply "go" or "ok" → proceed to Phase 2 with current positioning
• Reply with adjustments (e.g., "focus more on X", "the gap should emphasize Y") → refine and re-present
• Reply "stop" → end the skill, save current progress to grant-proposal/DRAFT_NOTES.md