grant_writing_basics v1.0.0

name: grant_writing_basics description: "Draft fundable grant proposals: funder fit research, letters of intent, narrative structure (problem, approach, impact), budget basics, and common rejection reasons. Use when someone needs help writing a grant proposal or LOI."

Grant Writing Basics

Purpose

This skill helps draft grant proposals at the narrative craft layer: checking fit with a funder, writing letters of intent (LOIs), structuring the core narrative (problem, approach, impact), building a basic line-item budget with justification, and avoiding the common reasons proposals get rejected. It stays at the craft of the proposal itself, not fundraising strategy, donor cultivation, or nonprofit management.

Cousin check against the catalog: cold-email-drafting covers short outreach emails to strangers; resume-craft covers job applications about a person; essay-writing covers personal and academic essays. None of them address funder alignment, LOIs, evaluation plans, or budget narratives, which is what lives here. If the user wants grant strategy (which funders to court, donor pipelines, campaign planning), this skill is not the right tool; send them to a fundraising resource instead.

Workflow

1. Gather inputs

Before drafting anything, collect:

• The funder's guidelines or RFP text (page limits, required sections, deadlines, eligible costs). If not provided, ask for it. Never write against a guessed template when a real one exists.
• The organization's facts: mission, past results in this program area, staff who will do the work, current data on the problem.
• Real numbers for the need statement and objectives. If numbers are missing, mark those spots instead of inventing them (see Operating Rules).

2. Check funder fit

Research the funder before writing a word. This step kills most rejections early.

• Read the funder's stated priorities and recent awards. Confirm the project topic matches what they actually fund, not what the organization wishes they funded.
• Check the typical award range and request an amount inside it.
• Check eligibility: geography, organization type, project type, and whether they accept unsolicited proposals. If they do not, do not draft a full proposal; draft an LOI or find another funder.
• Record the fit as explicit, borderline, or no fit. Borderline and no fit get said out loud to the user, not buried.

3. Draft the letter of intent (LOI), if required

Many foundations ask for an LOI before inviting a full proposal. Keep it to one or two pages:

• Who you are, in two sentences.
• The need, with one or two hard numbers.
• What you propose to do, in one paragraph.
• The amount requested and the project period.
• Why this funder: one sentence tying the project to their stated priorities. An LOI is a test of fit, not a mini-proposal. Short and specific beats long and general.

4. Draft the narrative

Use the funder's section order when one is given. Otherwise use the standard set below, which matches what funders across foundations and government programs commonly ask for. Generate a checklist first with the inline script in this skill, then draft section by section.

Executive summary. One page, written last. Organization intro, project summary, amount requested, expected outcomes.

Statement of need. Open with the affected population, not the organization. The problem in this community with specific, verifiable numbers: how many people, what the gap is, what happens if nothing changes. Cite evidence the user supplied. A citywide statistic proves nothing about the specific neighborhood served, so keep data local.

Goals and objectives. Goals state the change; objectives make it measurable: how much change, for whom, by when. Include a baseline for every target. "Serve more youth" is not an objective; "enroll 120 youth, with 80 completing the program by month 12" is.

Project description (approach). What you will do, who is involved, where, when. Methods, activities, timeline, staffing. Explain why this approach fits the problem's causes. Reviewers fund plans that respond to the problem, not intentions.

Evaluation plan. How you will know it worked: indicators tied to the objectives, data sources, collection methods, who analyzes, and the reporting schedule. Concrete indicators, not "we will assess outcomes."

Organizational capacity. Mission, history, relevant past results, key staff. Prove capacity with past outcomes; claims without evidence read as puffery. Understated and documented beats loud and vague.

Sustainability plan. What continues after the grant period, and how. Include only if the funder asks; a weak placeholder line ("we will seek more grants") hurts more than it helps.

5. Build the budget and justification

• Build line items for direct costs: personnel, fringe, materials, equipment, travel, contractors, other.
• Add indirect/administrative costs only at the rate the funder allows. If the funder caps admin at a percentage, compute it exactly and stay inside it. Confirm the current cap from the guidelines before quoting it.
• Write a budget narrative that justifies each line in plain terms: what the cost is, why the project needs it, how the amount was estimated.
• Two-way check: every line in the budget must appear somewhere in the narrative, and every activity in the narrative must have its costs in the budget. Mismatches are one of the fastest routes to rejection.
• Recheck the math. Errors in budget arithmetic signal sloppy planning to reviewers.

6. Run the rejection self-audit before submission

Check the draft against the most common rejection reasons, verified against funder-published guidance:

• Fit mismatch: the project is not actually what this funder funds.
• Guidelines ignored: page limits exceeded, formatting wrong, attachments missing, deadline missed.
• Need undocumented: assertions without data.
• Vague plan: activities listed but no timeline, milestones, or methods.
• Weak or missing evaluation plan.
• Unrealistic or unjustified budget; budget and narrative disagree.
• Wrong request amount: outside the funder's typical range.
• Organization-centric instead of people-centric: the proposal talks about the org, not the need.
• Unsolicited proposal sent where none are accepted.
• Typos and sloppy proofreading.

Fix every flagged item or mark it clearly as needing the user's input before the proposal can go out.

Output Contract

Every run produces:

1. A fit note (explicit, borderline, or no fit) with the evidence behind it.
2. An LOI draft when the funder requires one, or a full narrative draft otherwise, in the funder's section order or the default order above.
3. A line-item budget table with a justification narrative for each line, plus the two-way budget/narrative check.
4. A pre-submit audit listing each rejection reason checked, its status, and any items blocked on user input.
5. Any claim lacking real data is marked [EVIDENCE NEEDED: ...], never filled with invented statistics.

Operating Rules

1. Never fabricate statistics, needs data, or prior results. Use [EVIDENCE NEEDED: ...] for any claim requiring real data the user has not supplied.
2. Never invent funder priorities. Base alignment only on the actual guidelines or RFP text provided.
3. Never estimate budget figures on the user's behalf. All costs come from the user or are flagged as missing.
4. Keep time-sensitive process claims conservative and generic. Federal portals such as Grants.gov and foundation LOI norms change; describe them in general terms and label anything specific "confirm before quoting."
5. The user owns accuracy, compliance, and final submission. This skill drafts; it does not verify eligibility or guarantee funding.
6. Stay at the proposal craft layer. Do not drift into fundraising strategy, donor pipelines, or nonprofit management advice.
7. Voice: direct, confident, plain. No nonprofit jargon for its own sake. Active voice. Short paragraphs. The funder is a peer making a bet, not a savior being begged.

Helper script (verified)

Save the following as outline_checklist.py, then run python3 outline_checklist.py. It prints a section-by-section checklist with prompts and a pre-submit audit block. The code below was run locally and produces the output shown in testing.

python
#!/usr/bin/env python3
"""Print a grant proposal outline checklist with section prompts.

Usage: save as outline_checklist.py, then run: python3 outline_checklist.py
Outputs a plain-text checklist of standard proposal sections. Customize word
limits to match the funder's guidelines before drafting.
"""
SECTIONS = [
    ("Executive summary", "One page. Org intro, project summary, amount requested, expected outcomes."),
    ("Statement of need", "The problem in this community, with specific numbers. Who is affected, what gap this closes."),
    ("Goals and objectives", "Measurable results with baselines and targets. SMART where possible."),
    ("Project description / approach", "What you will do, who is involved, where, when. Methods, activities, timeline, staffing."),
    ("Evaluation plan", "Indicators, data sources, collection methods, who analyzes, reporting schedule."),
    ("Organizational capacity", "Mission, history, relevant past results, key staff. Proof, not claims."),
    ("Sustainability plan", "What continues after the grant period ends. Only include if the funder asks."),
    ("Budget and justification", "Line-item budget with a narrative explaining each cost. Every budget line must appear in the narrative, and vice versa."),
    ("Attachments checklist", "501(c)(3) letter, board list, financials, letters of support, anything the funder requires."),
]

def main():
    print("GRANT PROPOSAL OUTLINE CHECKLIST")
    print("=" * 40)
    for i, (name, prompt) in enumerate(SECTIONS, 1):
        print(f"\n{i}. {name}")
        print(f"   Prompt: {prompt}")
        print(f"   [ ] Drafted  [ ] Within page/word limit  [ ] Evidence attached")
    print("\nPre-submit audit:")
    print("  [ ] Matches funder's stated priorities")
    print("  [ ] No generic filler; all claims have evidence or are flagged")
    print("  [ ] Budget math checked; narrative and budget agree")

if __name__ == "__main__":
    main()