# eseckel/ai-for-grant-writing: a curated link list, not a grant writing tool > The repository is a Markdown reading list about using LLMs on grant applications, built into a MkDocs site. It ships no model, no prompts API and no submission pipeline, so judge it as a bibliography, not software. **eseckel/ai-for-grant-writing** — A curated list of resources for using LLMs to develop more competitive grant applications. - Repository: https://github.com/eseckel/ai-for-grant-writing - Website: https://eseckel.github.io/ai-for-grant-writing/ - Stars: 4,193 · Forks: 521 - Language: Python - License: CC-BY-4.0 - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/eseckel-ai-for-grant-writing ## What the repository actually is The README opens with one sentence: "A curated list of resources for using AI to develop more competitive grant applications." Everything below that sentence is links. There is no library to import, no command line entry point and no service. The Python in the repository is one file, mkindex.py, which sits next to mkdocs.yml and requirements.txt at the top level. The rest of the tree is documentation scaffolding: docs/, banner.png, CITATION.cff, CONTRIBUTING.md, LICENSE and .gitignore. The intended reader is a researcher or research administrator who is already writing a proposal and wants to know which assistants exist and what to type into them. The list is organised for that reader. Useful Services is a table comparing ten tools across spelling and grammar, text generation, translation, mock review, image generation and whether a free tier exists. Prompt Resources follows, split into collections, prompt engineering guidance and quick prompts. Grant Writing-Specific Resources closes with eleven links to funder guidance and writing advice. That structure is the whole product. If you want a program that ingests a Specific Aims page and returns a critique, this is the wrong repository, and no amount of reading it will change that. It tells you where to look and what to paste. It does not do the pasting. ## The service comparison table and what its columns mean The Useful Services table is the most opinionated artefact in the repository, and its columns are worth reading carefully. Five capabilities are tracked: spelling and grammar checking, text generation, translation, mock review and image generation. A sixth column records whether a free tier is available. ChatGPT, Gemini, Grok, Copilot, Grammarly, Grantable, Curie, DeepL, Midjourney, Firefly and Proposia appear, with marks placed in the cells that apply. The table is a capability map, not a ranking. Nothing in the README explains how a mark was assigned, when it was last checked, or what a mark in the mock review column is supposed to guarantee. Treat a mark as a pointer to go and test the tool on your own text. The free tier column is the one that ages fastest, because vendors change pricing without telling link curators. The mix is deliberate. General assistants sit beside single-purpose products: DeepL is listed for translation only, Midjourney and Firefly for image generation only, Grammarly for spelling, grammar and mock review but not generation or translation. Grantable and Proposia are the grant-specific entrants, both marked for text generation and mock review. If your institution restricts which vendors may process unpublished research text, the table gives you the candidate set but not the compliance answer. ## The quick prompts are the part you can use today Under Prompt Resources the README groups short prompts by intent rather than by tool. The headings are clarity, persuasiveness, structure and flow, alignment with a funding agency's mission, alignment with review criteria, title development, identifying challenges in proposed aims, and building a project timeline. Each heading holds one to three fenced prompt blocks. The prompts use placeholders rather than completed examples. The review criteria prompt asks the model to comment on "this review criteria: ", and the aims prompt takes "". The mission-alignment prompt names the American Heart Association and a postdoctoral fellowship, which makes it the most concrete of the set. Several prompts are written in the first person from the applicant's side, including one that opens "As a non-native English speaker, kindly help me revise the following text". This is the section to copy from. The prompts are short enough to paste into any assistant and specific enough to produce a usable first draft of feedback. What the README does not provide is any guidance on what to do with the output. There is no instruction to verify a suggested citation, no warning that a model may invent a funding mechanism, and no note about disclosing AI use in an application. Given that the list targets competitive applications, the absence of that last point is the most noticeable gap in the document. ## Building the MkDocs site locally The repository ships a MkDocs configuration and a pinned requirements file, so the published site at the project homepage can be rebuilt from the same Markdown. requirements.txt pins three packages: mkdocs 1.5.3, mkdocs-exclude 1.0.2 and mkdocs-material 9.5.4. mkindex.py sits alongside them, and the docs/ directory holds the content that mkdocs.yml points at. Install the pinned dependencies first. Running this in a virtual environment keeps the pinned versions away from anything else on the machine. ```bash python -m venv .venv source .venv/bin/activate pip install -r requirements.txt ``` With the dependencies in place, serve the site locally. The README does not document the port, so read the address MkDocs prints in the terminal rather than assuming one. ```bash mkdocs serve ``` To produce the static output instead, build it. The README does not document the output directory or the deployment target, so check mkdocs.yml for the site_dir value before you copy anything anywhere. ```bash mkdocs build ``` The three pins are from late 2023 and the last push to the repository was on 2026-06-06, so a fresh install may pull a MkDocs Material version that behaves differently from the one the site was last built with. If the build fails, the pinned versions in requirements.txt are the thing to check first, not the Markdown. ## Where the list format breaks down A curated list has a specific failure mode: link rot. The README links to vendor homepages, cloud documentation, journal articles, university writing centres and a WordPress blog. Nothing in the repository checks whether those targets still resolve, and there is no CI configuration visible at the top level that would run such a check. A reader who follows the list in a year is trusting that every curator since the last push kept the targets alive. The second limitation is coverage. The list is oriented toward biomedical and US federal funding. Specific Aims, Significance, R01, the American Heart Association and NIH tip sheets all appear. If you write for a European framework programme, a private foundation with its own template, or a humanities council, the prompt set transfers but the grant-specific resources largely do not. The README does link to the Social Science Research Council's proposal guidance, which is the one clearly non-biomedical entry in that section. The third is that a list cannot tell you what is allowed. Funders increasingly have policies on AI-generated text in applications. The README does not summarise any of them, and it would be a mistake to read the presence of a tool in the table as an endorsement of using it on a live submission. ## Alternatives and how they differ in approach The closest structural alternative is the awesome-list pattern itself, for example snwfdhmp/awesome-gpt-prompt-engineering, which the README links to under prompt engineering. That list collects general-purpose prompt material with no domain framing. The difference is scope rather than mechanism: this repository trades breadth for a grant-specific vocabulary, so its prompts mention Specific Aims and review criteria where a general list would talk about summarisation and role prompts. A different kind of alternative is a purpose-built grant assistant such as Grantable or Proposia, both of which appear in the table. Those are hosted products that take your draft and return feedback inside their own interface. This repository is the opposite arrangement: it hands you prompts and links and leaves the drafting environment, the data handling and the model choice to you. That is better if your institution forbids uploading text to third-party services, because you can run the prompts against whatever model you are permitted to use. It is worse if you want a repeatable workflow with an audit trail. A third option is to skip the list entirely and go straight to the funder. The NIH application guide and the NSF proposal writing guide are both linked here, and they are authoritative in a way no curated list can be. Use the repository to find them faster; use them to decide what goes in the application. ## Licence, maintenance and what to verify The repository is licensed CC-BY-4.0, a content licence rather than a software licence. That fits a Markdown list and it means reuse is permitted with attribution. It also means the usual software expectations do not apply: there is no warranty section to read, no dependency tree to audit, and no versioned API. If you copy prompt text into your own internal handbook, the licence condition that matters is attribution, and CITATION.cff in the repository root exists to make that straightforward. This is a description of the licence file, not legal advice. Maintenance is the practical question. The last push was on 2026-06-06, which is more than three months before today but inside six, so the repository is not stale by that measure. It is also not archived. There are no releases, and the three pinned packages in requirements.txt date from 2023, so the build tooling has not moved with the content. Contributions are invited through CONTRIBUTING.md, which means the list depends on readers submitting pull requests when a link dies or a tool changes. Before relying on it, check three things: that the tool you plan to use still exists at the URL in the table, that your funder permits AI assistance in the way you intend to use it, and that the MkDocs build still succeeds with the pinned requirements. The first two are the ones the repository cannot do for you. ## Conclusion Adopt it if you want a starting bibliography for LLM-assisted grant writing and are willing to check every link yourself, since the repository adds no verification of its own. Do not adopt it if you need a tool that drafts, scores or submits a proposal, or if you need a maintained dependency you can pin. Before citing it, open the raw README and confirm the entry you plan to use is still listed and still reachable. ## FAQ ### Which AI is best for writing grants? The repository does not rank the tools it lists. Its Useful Services table records which capabilities each one covers, such as spelling and grammar, text generation, translation, mock review and image generation, plus whether a free tier exists. Read a mark as a pointer to test the tool on your own text. ### Can I use ChatGPT for grant writing? ChatGPT appears in the Useful Services table with marks for spelling and grammar, text generation, translation, mock review, image generation and a free tier. The quick prompt section is written as plain prompt text that can be pasted into any assistant, and several prompts reference Specific Aims and review criteria. ### Do people use AI to write grants? The repository exists because its curator treats the practice as established enough to catalogue. It collects prompt collections, prompt engineering guidance and grant writing specific resources, and links to a PLOS Computational Biology article titled "Ten simple rules to leverage large language models for getting grants". ### Can AI help me apply for a grant? The list covers the parts of an application that text models can assist with: clarity, persuasiveness, structure and flow, alignment with a funder's mission, alignment with review criteria, title development, identifying challenges in proposed aims, and building a timeline. It does not cover submission mechanics. ### How do I use ai-for-grant-writing? Read the README or the published site, pick prompts from the Quick Prompts section and paste them into an assistant of your choice, filling in the placeholders such as the review criteria or the specific aims. The repository also builds into a MkDocs site with mkdocs serve after installing requirements.txt. ## Sources - [eseckel/ai-for-grant-writing on GitHub](https://github.com/eseckel/ai-for-grant-writing) - [Issues](https://github.com/eseckel/ai-for-grant-writing/issues) - [License: CC-BY-4.0](https://github.com/eseckel/ai-for-grant-writing/blob/main/LICENSE) - [Project website](https://eseckel.github.io/ai-for-grant-writing/) - [README](https://github.com/eseckel/ai-for-grant-writing/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/eseckel-ai-for-grant-writing