Start with a useful contribution
You do not need to write a whole skill. A corrected instruction, a better example, or a clear report of an overlap can be just as useful.
If you have hands-on nonprofit experience, look for a repeatable task where a colleague would benefit from a concrete method. Before drafting, browse the library and decide whether to improve an existing skill or propose a new one.
The quality bar
Aim for usable working knowledge rather than generic advice:
- Name the deliverable and the inputs needed to produce it.
- Explain the framework or decision rule precisely.
- Give a numbered process, not just a list of aspirations.
- Include realistic examples and common failure modes.
- Distinguish small-team, larger-organization, practitioner, and advisor needs where useful.
- State what the skill does not cover and name the neighboring skill that does.
- Cite authoritative URLs for factual, technical, or regulatory claims that readers need to verify.
Do not include confidential donor, staff, participant, or client information. Use fictional examples or material you have permission to share.
Put the file in the right place
The repository organizes skills at nonprofit-skills-library/skills/<category>/<skill-name>/SKILL.md; choose an existing category unless your proposal explains why a new one is necessary. Library on GitHub
For example:
nonprofit-skills-library/
skills/
fundraising-development/
nonprofit-your-skill-name/
SKILL.md
Use a lowercase, hyphenated name beginning with nonprofit-, and make the frontmatter name match its folder. Library conventions
Include the metadata
The Agent Skills standard requires name and description; put the library's supervision and date fields inside the standard metadata mapping as strings. Keep license at the top level. Agent Skills specification Library contribution guidance
---
name: nonprofit-your-skill-name
description: "Produces a specific deliverable. Use when a user asks for these concrete tasks. Does not cover the neighboring job owned by nonprofit-related-skill."
license: MIT
metadata:
supervision: "review"
supervision_note: "A knowledgeable staff member must check the output before it is used."
# date_added: "YYYY-MM-DD" # Evidenced date first added to this repository.
# date_added_source: "git:<full-commit-sha>"
# last_reviewed: "YYYY-MM-DD" # Only after a documented whole-skill review.
---
Replace every example value and omit unknown dates. metadata.date_added records repository addition, not original creation or review; retain its evidence in metadata.date_added_source. Do not list a sibling skill that does not exist.
Set or advance metadata.last_reviewed only after a substantive review of the whole skill, with a durable record of the reviewer, scope, sources/tests, and limitations. A targeted fix, metadata edit, or release does not qualify; never copy the addition date into the review field.
Choose unsupervised, review, or expert-required based on the consequences of a wrong output, and write a specific supervision_note explaining the choice. Library supervision guidance
These review and supervision fields are library conventions, not proof that an AI product enforces approval before use.
Write a focused body
A useful draft includes:
- When to use it: the task, audience, required inputs, and boundaries.
- Working method: named frameworks and concrete decision rules.
- Deliverables: what the output should contain and what good looks like.
- Steps: a sequence the agent can follow, including when to ask for missing facts.
- Failure modes: likely mistakes and checks that catch them.
- Review and handoff: who checks the output and when specialist help is needed.
Keep the main instructions short enough to use. Prefer one coherent job over a collection of unrelated topics.
Test before submitting
Try at least three prompts: a normal task, a task with missing inputs, and a nearby task that belongs to another skill. Check that the output marks assumptions, avoids invented facts, respects boundaries, and gives a useful next step.
From the repository's top-level folder, the existing checks can report supervision metadata and review dates. Library maintenance tools
python3 -m pip install -r nonprofit-skills-library/scripts/requirements.txt
python3 nonprofit-skills-library/scripts/check_supervision.py --all
python3 nonprofit-skills-library/scripts/check_review_status.py --all
These are metadata checks, not tests of factual accuracy. The supervision script reports missing labels without failing; the review-date script distinguishes no recorded review date (NOT_REVIEWED) from an elapsed review interval (REVIEW_OVERDUE) and invalid metadata, exiting nonzero for any of those conditions. Addition dates help prioritize initial reviews but never make a skill count as reviewed. Library maintenance tools
Review the rows for your changes, and report unrelated existing warnings rather than silently changing other skills.
Open a pull request or issue
For a new skill or correction:
- Fork the GitHub repository.
- Add or edit the relevant
SKILL.md. - Open a pull request explaining the problem, your practitioner experience, the scope boundary, the supervision choice, and the tests you ran.
- Include supporting URLs and call out anything that still needs expert review.
If you are not ready to draft a fix, open an issue with the skill name, the specific problem, and a reproducible example or correction.
Respect the license
Contributions are shared under the repository's MIT license, which permits reuse and redistribution, including commercially, subject to preserving the copyright and permission notice. Repository license
Submit only material you have the right to share on those terms.