I. Issue № 01 · April 2026

Your grants, checked, then built, like a manuscript read by your agents.

GrantKit is the linter and compiler for grant proposals. It checks your markdown against versioned funder rule packs, then builds the submission — while Claude Code, Cursor, and any other agent do the writing.

Read the docs → How it works

pip install grantkit · MIT licensed · v0.1 · source at github.com/GrantKit

The medium

~/grants/
├── nsf-cssi/
│   ├── grant.yaml
│   ├── budget.yaml
│   ├── references.bib
│   └── responses/
│       ├── broader_impacts.md
│       ├── technical_approach.md
│       └── project_summary.md
└── .grantkit/rules.lock ← pinned pack

A grant is a set of markdown files, a budget, a bib file, and a lockfile pinning the funder rule pack version that checked it last.

II. Thesis

Why we wrote this

2023 was the year of the chatbot. 2024, RAG and finetuning. 2025, MCP and tool use. 2026 will be the year of the computer environment and filesystem.

— Alex Albert, Anthropic · see the post

Your coding agent is already world-class at reading a directory of files, proposing a surgical edit, explaining why, and handing you a reviewable diff. That is exactly how a proposal wants to be written. So we stopped trapping grants in a web UI and started treating them like what they are: writing, held in files, on a filesystem, where your tools live.

III. Why files

i. Context

The agent reads everything, not a snippet.

A web form hands the model a 2,000-token excerpt. A filesystem hands it the budget, last year's proposal, the solicitation, the reviewer's letter, and every response you've drafted — and lets it decide what to pull in.

ii. Provenance

Every edit is a reviewable diff.

Git remembers. An "undo" button forgets. When your broader impacts section drifts over three weeks of revisions, you want a line-level history you can bisect and blame, not a modal that asks if you're sure.

iii. Portability

The model is yours to choose.

Claude today, a local model tomorrow, a new frontier system next quarter. A grant stored as markdown outlives every LLM vendor and every SaaS company in the category.

IV. How it works

Edit with your agent. Check like CI. Build with confidence.

GrantKit runs entirely on your machine, against the same rules a reviewer would apply. No account, no server round trip, no state to reconcile. Fail a check, fix the file, run it again.

I. Init. grantkit init scaffolds ~/grants/ as markdown.

II. Edit. Open Claude Code, Cursor, Codex — any agent with file access.

III. Check. The funder's rule pack runs locally, offline, with citations.

IV. Build. One command compiles the review page, portal copy, and PDF.

~/grants — grantkit check

$ grantkit status

                 nsf-cssi · arnold-labor    
──────────────────────────────────────────
 check      1 error, 3 warnings   nsf-cssi
 check      clean                 arnold-labor
 build      stale                 nsf-cssi/build/review.pdf
──────────────────────────────────────────
1 error across 2 grants

$ claude "Tighten the broader impacts section to 2500 words and add a specific undergraduate outreach plan."
...editing nsf-cssi/responses/broader_impacts.md...
✓ 2,498 words. Draft updated.

$ grantkit check nsf-cssi
✓ 84/84 nsf-pappg-2025 rules passed
✗ budget.yaml — postdoc salary $148,000 exceeds BLS OEWS 90th
  percentile for this metro area
1 error, 0 warnings

$ grantkit build nsf-cssi
✓ review.pdf, portal/*.txt, review.html written
Build complete

Not a screenshot. Run the commands yourself with pip install grantkit.

V. What's inside

Check

Eighty-plus NSF PAPPG rules, with citations.

Word and page limits, font and margins, required sections, placeholder text left behind by a draft. Every failure names the rule it came from.

Build

One command compiles the submission.

grantkit build assembles the review page, the portal's copy-paste blocks, and a formatted PDF from the same markdown you edited.

Budget

BLS OEWS salary checks and GSA per-diem.

Catch a $350k postdoc before a program officer does. Automatic per-diem lookups by city and fiscal year, both inside grantkit check.

Bibliography

BibTeX in, rendered citations out.

One references.bib. [@key] inline. Auto-regen is opt-in and respects your manual edits.

Rule packs

Versioned funder rules, not hardcoded guesses.

NSF PAPPG, Nuffield, PBIF — each a pinned, open YAML pack. Contribute a fix or add a funder; every check cites the rule it enforced.

Review

A second pass, past the mechanical rules.

grantkit review reads a full proposal for argument, not just compliance — thin evidence, a broader impacts section that reads as an afterthought.

MCP server

Your agent calls the validators mid-draft.

Run grantkit mcp and any MCP-aware agent can check a section, a budget line, or a citation the moment it's written.

GitHub Action

CI for grants.

Add the action and every commit runs grantkit check. A failing rule blocks the merge the same way a failing test does.

Open source

MIT-licensed. Fork it, shape it to your lab.

The CLI, the rule packs, the plugin, the MCP server, the GitHub Action. Source at github.com/GrantKit.

Ship the next grant the way you ship code.

Two commands and a coding agent. Nothing to migrate, no new editor to learn, no lock-in. Just files.

View on GitHub → Read the docs

pip install grantkit && grantkit init