grant-proposal skill

Override for Codex users who want Gemini, not a second Codex agent, to act as the reviewer. Install this package after skills/skills-codex/*.

Grant Proposal: From Research Ideas to Fundable Application

Gemini overlay assurance: reviewindependence: cross-family and acceptancestatus: accepted.

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:

/research-lit → /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

• GRANTTYPE = KAKENHI** — Default grant type. Supported: KAKENHI, NSF, NSFC, ERC, DFG, SNSF, ARC, NWO, GENERIC. Override via argument (e.g., /grant-proposal "topic — NSF").
• GRANTSUBTYPE = 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.
• REVIEWERMODEL = gemini-review — Gemini reviewer invoked through the local gemini-review MCP bridge for proposal review. Set GEMINIREVIEW_MODEL if you need a specific Gemini model override.
• OUTPUTFORMAT = markdown** — Output format. Supported: markdown, latex. LaTeX uses grant-specific templates when available.
• MAXREVIEWROUNDS = 2 — Maximum external review-revise cycles before finalizing.
• OUTPUTDIR = 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.
• AUTOPROCEED = 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.

💡 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",
  "thread_id": "019cfcf4-...",
  "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: "inprogress" and within 24h → resume from saved phase (read GRANTPROPOSAL.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-stage/IDEAREPORT.md if it exists (from /idea-discovery); fall back to ./IDEAREPORT.md if not found
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 review-stage/AUTOREVIEW.md if it exists (from /auto-review-loop — prior review feedback is gold for grants); fall back to ./AUTOREVIEW.md if not found
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 /research-lit inline in Phase 1
• No publication list → leave PI qualification section with [TODO: Add publications] placeholders
• Has review-stage/AUTO_REVIEW.md → extract reviewer feedback and use it to strengthen the feasibility narrative

Phase 1: Literature & Landscape Positioning

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

/research-lit "$ARGUMENTS"

What this does:

• Reuse existing surveys if /research-lit was already run and notes exist
• Otherwise invoke /research-lit 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?

⛔ STOP HERE and wait for user response. Do NOT auto-proceed unless AUTO_PROCEED=true was explicitly set by the user.

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

State: Write GRANT_STATE.json with phase: 1 and the gap statement.

Phase 2: Narrative Structure & Aims Design

Design the proposal's logical architecture before writing any prose.

2.1 Define Specific Aims (2-4)

Each aim must satisfy:

• Independently valuable — if one aim fails, others still produce publishable results
• Logically connected — Aim 1 enables Aim 2, Aim 2 informs Aim 3
• Concrete deliverables — each aim maps to specific outputs (papers, datasets, tools, benchmarks)
• Feasible within budget and timeline

2.2 Build Claims-Aims-Evidence Matrix