# A grant boilerplate library — reusable sections for every application Recipe No. 42, Research and civic life. From The know.sh Cookbook: https://know.sh/cookbook/grant-library - For: the development director of a small nonprofit who writes twenty applications a year alone - You bring: last year’s strongest applications, the annual report, the audited budget, the evaluation data, a folder of signed letters of support, and the AI assistant you already use - You get: a private library of approved, dated sections — mission, programmes, outcomes, budget narratives, letters on file — and a first draft for each new funder assembled from it - Time: an evening for your assistant to take the old applications apart, two days of your review, then an hour for each new application and a morning for the annual refresh - Keep it: private; never on a public link A development director at a small nonprofit answers the same questions twenty times a year, in twenty different word limits. Describe your organisation in 150 words. Describe the need. How do you measure outcomes? Last year's answers are scattered across portal submissions and Word files named *FINAL v3*, and each one has a slightly different number of learners served. This recipe keeps the approved language in one place. The shelf has five documents: **Organisation**, **Programmes**, **Outcomes and data**, **Budget narratives** and **Letters of support**. Each finding is one reusable block, in the length funders ask for, with the date it was last checked on its first line. Your assistant — Claude, ChatGPT or a local model — takes last year's applications apart into those blocks; you approve each one in the editor. When a new funder's guidelines arrive, it assembles a first draft from blocks you have already approved and says which ones are out of date. The draft is where your work begins, not where it ends. You edit it, you check every number, and the application goes out under your name. ## What you will use - **Shelf**: One shelf, *Grant library*, with a line naming the fiscal year the numbers are current to. - **Research document**: Five standing documents, plus one document per application that is assembled from them. - **Finding**: One block per finding, titled with its subject and length; descriptive blocks as *Observation*, numbers as *Evidence*, known gaps as *Problem*. - **Your AI assistant**: Takes past applications apart into blocks, drafts shorter versions, files a first draft for each new funder from the approved blocks, and checks the library for figures that disagree. - **The editor**: Where you choose the better answer, cut to length, check each figure and change the date line when a block is approved. - **Revisions**: Keeps last year’s version of every block through the annual refresh, and shows which lines an assistant wrote and which you changed. - **Look up**: Finds a block by the phrase a funder uses: *capacity*, *sustainability*, *theory of change*. ## Method ### 1. Have your assistant take last year’s applications apart Connect your assistant to know.sh once, following the support page. Give it the four or five applications that were funded and the annual report, and ask it to make a shelf called *Grant library* with five documents — **Organisation**, **Programmes**, **Outcomes and data**, **Budget narratives**, **Letters of support** — and to file every answer that recurs as a block: the mission, the history, the need, each programme, the evaluation method, the staffing, the budget narrative. Where two applications answer the same question differently, tell it to file both, side by side, and say which application each came from. Choosing is your job. ### 2. Approve each block in the editor, at the lengths funders ask for Go through the shelf in **Edit**. Keep the better of each pair, merge where both have something, and delete the rest. Every finding is one block, titled with its subject and length: "Mission — 50 words", "Mission — 150 words", "Adult literacy programme — 250 words", "Evaluation method — 500 words". Portals count words and characters; ask your assistant to draft the 50- and 150-word versions from the one you approved, then cut them yourself. Put the date and the source on the first line of every approved block: "Last updated 14 August 2026, from the FY2026 evaluation report." File descriptive blocks as *Observation* and blocks built on numbers as *Evidence*, with a link to the published annual report or evaluation in their sources where one exists. ### 3. Keep the numbers in one place Put every figure a funder might ask for in **Outcomes and data**, one finding each: learners served, sessions held, reading-level gains, the waitlist, the cost per learner. Other blocks refer to these numbers rather than repeating them, so when a figure changes you change it once. Where you know the data is weak — no follow-up after learners leave, a small sample — say so in a *Problem* finding. Funders ask, and an honest answer written calmly in advance is better than one written at midnight before a deadline. ### 4. Record where the letters of support are Letters of support are signed documents, and they belong in the shared drive where the signed copies live. Give your assistant the scanned letters and ask for a finding per letter in **Letters of support**, titled date first: "2026-04-02 — Lowbridge Public Library director". The body says who wrote it and in what role, the application it was written for, what it says in two lines, and the folder where the signed copy is kept; add the folder yourself if it did not know. When a funder wants letters dated within the last year, a glance down the finding titles tells you whose to ask for again. ### 5. Have your assistant assemble the first draft Paste the new funder's questions and word limits into your assistant and ask it to draft an application from the library: a new document on the shelf, one finding per question, each built from existing blocks and naming the blocks it used. Ask it to flag any block last updated more than a year ago, any question the library cannot answer, and any place where it went beyond the blocks. Those flags are your to-do list. ### 6. Edit the draft into your application Read the draft as you would a new staff member's. Cut what does not fit this funder, add what only you know about why this programme suits their priorities, and check every number against **Outcomes and data**. The revisions of each finding show the assistant's draft and your changes, one after the other. When it is right, copy each answer into the funder's portal. Then look at what you rewrote: if a better answer to a common question emerged, save it back into the library as a new block, dated. ### 7. Refresh the library once a year When the audit and the annual evaluation are done, give the library a morning. Update every figure in **Outcomes and data**, then ask your assistant to list blocks that still mention last year's numbers or have not been updated in twelve months. Change the date line on each block you check, even when the words stay the same. Revisions keep last year's version of every block. When a funder asks how this year compares with last, open a block's revisions and read last year's figures; there is no need to restore them. ## Prompts to try Your assistant, connected to know.sh (Claude, ChatGPT or a local model): > I am attaching our five funded applications from 2025–26 and the FY2026 annual report. Using know.sh, make a shelf called “Grant library” with five documents: Organisation, Programmes, Outcomes and data, Budget narratives, Letters of support. File each recurring answer as a finding in the right document, titled with its subject and word count. Where applications answer the same question differently, file both versions and name the application each came from. Take every figure exactly as written; do not update or round anything. Your assistant, connected to know.sh (Claude, ChatGPT or a local model): > Using my shelf “Grant library” in know.sh, answer these funder questions as a new document on the shelf, one finding per question, within each word limit: [paste questions and limits]. Use only existing blocks, name the blocks you used, and flag any block last updated more than twelve months ago. Where the library has no answer, write “Needs an answer” rather than drafting one. Your assistant, connected to know.sh (Claude, ChatGPT or a local model): > Using know.sh, read every finding on my shelf “Grant library” and list any figure (learners served, cost per learner, budget totals, staff numbers) that appears with different values in different findings, quoting both and naming the findings. Then list every block whose “Last updated” line is before 1 September 2025, oldest first. Do not change anything. ## Variations - Keep a *Funders* document with one finding per foundation you apply to: its priorities, deadlines, word limits, its rules on AI use, and what the programme officer said on the last call. - Use the same library for the annual report: the programme and outcomes blocks are most of what it needs. - Pair it with the [onboarding handbook](/cookbook/onboarding-handbook) so a new development assistant learns the organisation from the same approved language. ## Where it falls short - No funder portal connects to know.sh. Answers are copied into each portal by hand. - Budgets are spreadsheets, and know.sh has no spreadsheet or calculation. Keep the budget in your accounting system or a spreadsheet; the library holds the narrative that explains it. - Signed letters, audits and IRS determination letters cannot be stored as files. Record where each one is kept. - Your assistant can only draft from what is in the library. If the library is stale, the draft is stale, however fluent it reads. - Smaller local models call tools less reliably and lose track of word limits more often. Check what they file; Revisions shows every change. ## A note on accuracy and funders’ rules on AI know.sh helps you organise and draft; you are responsible for accuracy. When you submit an application you are usually certifying that what it says is true, so check every figure against its source and every claim about a programme against what the programme actually does. Assistants make mistakes, and a fluent paragraph can carry a wrong number. Some funders now have their own rules on AI: some ask you to disclose it, and a few restrict it. Read each funder's guidelines before you use an assistant on their application, and record the rule in your *Funders* notes. Keep donor records, learners' personal details and anything under a confidentiality agreement out of the library. A library of approved language does not need them. Indexed under: Grant applications, Boilerplate, Letters of support, Outcomes data, Word limits, Nonprofits, Annual refresh.