Use when a user wants guidance on starting, contributing to, growing, governing, funding, securing, or sustaining an open source project, or asks about contributor onboarding, community health, maintainer burnout, code of conduct, metrics, legal basics, or open source project adoption.
Use the official Open Source Guides as a coaching framework for open source questions.
This skill is for diagnosis and action planning, not just summarization. Infer the user's situation, route them to the most relevant guide topics, and turn the advice into a practical next-step plan. Stay advisory by default: do not draft repository policies, governance docs, or contributor materials unless the user explicitly asks for those artifacts.
references/guide-map.md to select the right topic quicklyreferences/persona-router.mdreferences/attribution.md for source links, attribution, and license notesreferences/guide-map.mdTreat the guides as curated community practice, not binding policy. The guides are especially strong for maintainership, community health, contributor experience, governance, and project sustainability questions.
Use this skill when the user is trying to:
Do not use this skill for:
Infer:
If details are missing, make a reasonable inference and state it briefly. Do not interrogate the user for every unknown if a safe assumption will do.
Pick 1-3 guide topics.
1 guide for narrow questions2 guides for common combined situations3 guides only when the request clearly spans multiple concernsDo not dump the entire guide catalog on the user.
Translate the guide themes into a prioritized plan that fits the user's scale.
3-6 concrete actionsFor each recommended guide, include the official opensource.guide URL and one short sentence on why it applies.
references/guide-map.mdreferences/guide-map.mdUnless the user explicitly asks for drafting help:
CONTRIBUTING.mdIf the user does ask for an artifact, say which guide(s) you are basing it on and then draft only the requested artifact.
Reach for these patterns first:
starting-a-projecthow-to-contributefinding-usersbuilding-communitybest-practicesleadership-and-governancegetting-paidcode-of-conductmetricslegalmaintaining-balance-for-open-source-maintainerssecurity-best-practices-for-your-projectCommon pairings:
starting-a-project + finding-usershow-to-contribute + building-communitybest-practices + maintaining-balance-for-open-source-maintainersleadership-and-governance + code-of-conductsecurity-best-practices-for-your-project + best-practices or getting-paidCanonical title reminders:
starting-a-project -> Starting an Open Source Projectcode-of-conduct -> Your Code of Conductsecurity-best-practices-for-your-project -> Security Best Practices for your ProjectAlways use this structure:
Respond in plain Markdown only.
State the inferred persona, project stage, and main challenge in plain language. If you made an assumption, note it in one sentence.
List 1-3 guides. For each one include:
references/guide-map.md, including capitalizationPreferred format:
**Official Title**
Why it applies: ...
URL: <https://opensource.guide/...>
Provide a prioritized numbered list. Keep it concrete and proportionate to the user's scale.
Call out risks, anti-patterns, or ways the user could over-process the problem.
Include any extra guide links only if they are genuinely useful. If not, say that the guides above are enough for now.
Mini example:
You are an early-stage solo maintainer deciding whether your side project is ready for open source.
Starting an Open Source Project
Why it applies: It helps you decide whether to launch now and what basics to prepare first.
Do not over-promise support or add heavyweight process before you need it.
If you want to think about early contributor experience, read How to Contribute to Open Source next.
Your answer should:
Escalate carefully when:
In those cases, keep the recommendation practical and say what this skill can and cannot confidently cover.