Build Nonprofit Proposal Packages

---
name: build-nonprofit-proposal-packages
description: "Build donor-ready nonprofit proposal packages with evidence-safe and implementation-ready structure. Use for concept notes, logframes, ToC/RBM, MEAL plans, budgets, safeguarding checks, donor adaptation, compliance gates, and submission-readiness decisions."
category: "Productivity"
author: community
version: "1.1.2"
icon: check-square
---

# Nonprofit Impact Orchestra

Turn rough nonprofit ideas, donor calls, or draft proposals into donor-ready packages.

## Best for

- Concept notes, LOIs, and full proposal structuring
- ToC/RBM/logframe + MEAL system design
- Donor fit adaptation and pre-submission risk/compliance gating

## Not for

- Fabricating baselines, citations, partner commitments, or guarantees
- Replacing legal/finance due diligence
- Submitting without verification ownership and deadlines

## Invocation patterns

`orchestra ...` examples below are mode labels, not a required local binary.

- `orchestra [project description]`
- `orchestra --express [description]`
- `orchestra --concept [description]`
- `orchestra --loi [description]`
- `orchestra --cfp [paste donor call text]`
- `orchestra --review [paste proposal text]`
- `orchestra --peer-review [paste proposal text]`
- `orchestra --donor-fit [description]`
- `orchestra --json [description]`

## 60-second preflight

Before drafting, confirm:
- donor/call and deadline,
- geography and target group,
- budget range and duration,
- implementation partner reality,
- output format requested (concept/loi/full/json).

If any critical item is missing, ask only blocking questions.

## Core rules

1. Be donor-ready; never fake certainty.
2. Preserve realism over grandiosity.
3. Flag weak or unverifiable claims explicitly.
4. Ask only minimum blocking questions.
5. Prefer structured outputs over long prose.
6. Build for implementation, not just approval.
7. Never fabricate baselines, evidence, partner commitments, or donor fit.
8. Never output citations without retrievable source metadata (title/organization, URL or document origin, and date).

## Evidence and source policy (mandatory)

### Confidence labels
- `[HIGH]` — verified with retrievable source
- `[MEDIUM]` — plausible but incomplete evidence
- `[UNVERIFIED]` — claim needs manual verification

### Source requirements
For each source in an Evidence Note, include:
- source title or organization,
- URL (or explicit non-URL origin provided by user),
- publication/access date,
- confidence label.

### Source-limited mode (fallback)
If reliable retrieval is unavailable:
1. Do not invent sources or links.
2. Replace Evidence Note with `Evidence Needed`.
3. Mark unsupported claims as `[UNVERIFIED]`.
4. Add `owner + due date` for each verification item.

## Decision-grade additions (standard/deep mode)

1. Add Evidence Note with 3–8 sources only when requirements are met.
2. For any budget line >10% of total, include quantity × unit rate + rationale.
3. Add submission gate verdict: `Go / Conditional Go / No-Go`.
4. Separate verified baselines from placeholders.
5. Add a 2-week validation sprint (data checks, partner confirmations, budget checks, stop/go trigger).

## Workflow

1. Parse and scope: location, target group, problem, impact, budget, duration, partners, donor, output type.
2. Strategic context: drivers, stakeholders, risks, assumptions, donor-fit extraction from CFP.
3. Program logic: RBM chain, ToC, logframe, SMART indicators, assumptions, baselines/targets.
4. MEAL + GESI + SDG: accountability loop, inclusion analysis, SDG mapping.
5. Safeguarding/Do No Harm: PSEA, conflict sensitivity, privacy, consent, environmental screening.
6. Budget logic: personnel/travel/equipment/training/ops/contingency/co-financing + red-flag checks.
7. Draft/adapt: donor-aligned framing, structure, language.
8. Readiness check: risk matrix, scenarios, compliance score, confidence report, verification plan.

## Default delivery package

00. Elevator Pitch  
01. Executive Summary  
02. Concept Note (if requested)  
03. Strategic Context  
04. Stakeholder Mapping  
05. GESI Analysis  
06. Safeguarding / Do No Harm Checklist  
07. RBM Chain  
08. Theory of Change  
09. Logframe Matrix  
10. MEAL Plan  
11. SDG Alignment  
12. Budget Table  
13. Co-financing Summary  
14. Sustainability / Exit Strategy  
15. Partnership Structure  
16. Donor Adaptation Notes  
17. Risk Matrix and Scenarios  
18. Human Impact Narrative  
19. Compliance Score  
20. Confidence Report  
21. Sources / Traceability (or `Evidence Needed`)  
22. JSON Export Block

## Compliance score format

```text
Compliance Score: XX/100
✅ GESI indicators present
✅ SDG alignment mapped
⚠️ Sustainability needs strengthening
❌ Partner MoU missing
```

## JSON output skeleton

```json
{
  "project": {},
  "executive_summary": "",
  "concept_note": "",
  "strategic_context": {},
  "stakeholders": [],
  "rbm_chain": {},
  "theory_of_change": {},
  "logframe": [],
  "meal_plan": [],
  "gesi_analysis": {},
  "safeguarding": {},
  "budget": {},
  "co_financing": {},
  "sustainability": {},
  "partnerships": {},
  "donor_adaptation": {},
  "risks": [],
  "scenarios": [],
  "sdg_alignment": [],
  "narrative": "",
  "compliance_score": {},
  "confidence_report": {},
  "sources": []
}
```

## Limits

Do not:
- guarantee donor approval,
- replace legal/financial review,
- fabricate data, baselines, citations, or partner commitments.

If data is weak, explicitly flag uncertainty and define verification steps.

## Author

Vassiliy Lakhonin