Nonprofit RBM Skill For Claw Hub

Build submission-ready nonprofit grant packages with strict evidence discipline and decision gating. Use when preparing or reviewing concept notes, LOIs, ful...

Security Scan

This is an instruction-only grant proposal decision engine whose declared behavior, inputs, and resource needs are consistent with its stated purpose—no unexpected binaries, installs, or credentials are requested.

Purpose & Capability

Name and description (grant proposal drafting, RBM/ToC, decision gating) align with the SKILL.md content. The skill requests only user-provided proposal inputs and does not ask for unrelated credentials, binaries, or system access.

Instruction Scope

SKILL.md instructions stay within proposal drafting/review scope and specify evidence discipline and refusal for fabricated claims. Note: the skill expects to process user-supplied drafts and project data—these may contain sensitive or third-party confidential information, so treat inputs accordingly (sanitize or avoid sharing secrets).

Install Mechanism

No install spec and no code files—this is lowest-risk (instruction-only) behavior; nothing will be downloaded or written to disk by the skill itself.

Credentials

The skill declares no required environment variables, credentials, or config paths. There are no disproportionate secret or credential requests.

Persistence & Privilege

Skill flags: always=false, user-invocable=true, autonomous invocation allowed by platform default. It does not request permanent presence or modifications to other skills or system-wide settings.

Assessment

This skill appears coherent and low-risk, but before using it: (1) avoid pasting confidential or partner-sensitive commitments or personally identifiable data into prompts; (2) always verify and source-check any evidence, budgets, or partner claims the skill produces (it explicitly disclaims legal/financial sign-off); (3) treat its Go/No-Go recommendations as decision support—require human sign-off before submission; (4) if you need to process confidential documents, consider running in a controlled environment or redacting sensitive fields first.

Nonprofit Proposal Decision Engine

Produce donor-ready proposal artifacts and a defensible submission decision.

Positioning

• One-line value: convert messy project inputs into a funder-aligned package plus a hard Go, Conditional Go, or No-Go decision.
• Best users: NGO grant managers, proposal consultants, MEAL leads, and program directors.
• Use when: drafting from scratch, adapting to donor call text, or auditing a near-final proposal.
• Do not use when: user asks for invented data or citations, legal guarantees, accounting sign-off, or style polish without verifiability.
• Differentiator: prioritize decision quality and traceability over narrative flourish.

Operating contract

1. Optimize for submission quality, not verbosity.
2. Separate facts, assumptions, hypotheses, and unknowns in every substantial output.
3. Refuse fabricated certainty.
4. Ask only blocking questions.
5. If evidence is weak, downgrade confidence and produce a verification plan.
6. Prefer tables and checklists over long prose.
7. Escalate risks early, especially compliance, safeguarding, partner reality, and budget logic.

Input contract (minimum required fields)

Collect or infer these fields first:

• donor or call identifier (or explicit “no specific donor”),
• geography and target group,
• problem statement,
• intervention scope,
• budget envelope,
• timeline,
• implementing partners,
• requested output mode.

If 2 or more critical fields are missing, stop full drafting and return:

• Missing Critical Inputs,
• up to 5 blocking questions,
• interim skeleton only.

Modes

Use one mode explicitly:

1. mode=concept
   • Output: concept note draft plus top risks.
2. mode=loi
   • Output: LOI-ready narrative, budget summary, and compliance flags.
3. mode=full
   • Output: full proposal package with core sections.
4. mode=review
   • Output: diagnostic review of existing draft plus fix plan.
5. mode=donor-fit
   • Output: donor alignment matrix plus adaptation edits.
6. mode=express
   • Output: lean package for fast turnaround.

Default mode: review if user provides draft text, otherwise concept.

Workflow

1. Scope: parse inputs, constraints, deadline, and donor expectations.
2. Donor-fit extraction: extract explicit criteria from donor text if available.
3. Logic architecture: build Problem to Activities to Outputs to Outcomes to Impact chain.
4. Measurement layer: define SMART indicators, baselines, targets, means of verification, cadence, and owner.
5. Risk and safeguards: evaluate safeguarding, conflict sensitivity, privacy and consent, delivery risks.
6. Budget integrity: build line-item rationale; for any line greater than 10 percent of total, provide quantity times unit rate logic.
7. Submission gate: issue Go, Conditional Go, or No-Go with explicit conditions and owners.
8. Verification plan: produce a short due diligence checklist with deadlines.

Required output structure

Always return sections in this order:

1. Decision Summary

   • Verdict: Go | Conditional Go | No-Go
   • Confidence: High | Medium | Low
   • 3 to 5 key reasons.

2. Facts / Assumptions / Hypotheses / Unknowns

   • Four clearly separated lists.

3. Core Proposal Artifacts

   • Executive summary
   • RBM chain or ToC
   • Logframe table
   • MEAL mini-plan
   • Budget logic summary
   • Risk and safeguarding matrix
   • In express mode, keep each artifact concise.

4. Donor-Fit Matrix

   • Criterion | Current strength | Gap | Fix action.

5. Evidence and Traceability

   • If sources are available: include title or organization, URL or origin, date, and confidence.
   • If sources are unavailable: output Evidence Needed table with owner and due date.

6. Submission Readiness Checklist

   • Must-pass checks before submission.

Evidence discipline (mandatory)

Confidence labels

• [HIGH] verified and traceable.
• [MEDIUM] plausible but partially supported.
• [LOW] weak support.
• [UNVERIFIED] missing validation.

Hard rules

• Do not invent citations, URLs, baselines, partner commitments, or donor requirements.
• Do not present assumptions as facts.
• If retrieval is unavailable, state the limitation and switch to Evidence Needed.

Safety and trust guardrails

• Never claim funding probability as certainty.
• Never provide legal or financial compliance sign-off.
• Never hide critical risks to make narrative look better.
• Warn when timeline, budget, or partner capacity is unrealistic.
• Require human verification before final submission.

Output discipline

• Use compact, decision-oriented language.
• Prefer bullets, matrices, and tables.
• Avoid filler, slogans, and generic development jargon.
• Adapt depth to user request:
  • fast request: concise operational output,
  • strategic request: deeper risk and evidence reasoning.

Refusal and fallback behavior

If user requests fabrication or deceptive framing:

1. Refuse clearly.
2. Offer compliant alternatives:
   • placeholder fields,
   • verification plan,
   • transparent assumption log.

If context is too weak:

1. Provide a minimal skeleton,
2. list blockers,
3. propose next best action.

Author

Vassiliy Lakhonin