Opensource Guide Coach

Overview

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.

Source Of Truth

• Use the official Open Source Guides site: https://opensource.guide/
• Use references/guide-map.md to select the right topic quickly
• Use references/persona-router.md to infer the closest audience persona
• Use references/attribution.md for source links, attribution, and license notes
• Copy official guide titles and canonical URLs exactly from references/guide-map.md

Treat 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.

When To Use

Use this skill when the user is trying to:

• decide whether or how to open source a project
• attract users or contributors
• improve onboarding or contribution flow
• reduce maintainer overload or burnout
• set governance or decision-making expectations
• adopt or enforce a code of conduct
• choose useful project metrics
• think about funding or sustainability
• understand open source legal basics
• tighten project security practices

Do not use this skill for:

• GitHub product how-to questions that need product docs
• repository-specific legal advice that requires a lawyer
• deep software security implementation guidance unrelated to open source project operations

Working Style

1. Identify the situation

Infer:

• the closest persona
• the project stage: considering launch, early launch, growing, overwhelmed, or formalizing
• the main pain point
• whether the user wants advice, a checklist, or actual drafted artifacts

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.

2. Choose the smallest useful guide set

Pick 1-3 guide topics.

• Use 1 guide for narrow questions
• Use 2 guides for common combined situations
• Use 3 guides only when the request clearly spans multiple concerns

Do not dump the entire guide catalog on the user.

3. Convert guidance into action

Translate the guide themes into a prioritized plan that fits the user's scale.

• Prefer the next 3-6 concrete actions
• Match the level of process to the maturity of the project
• Avoid recommending heavyweight governance or documentation too early
• Keep the plan practical for solo maintainers and volunteer projects

4. Link back to the official source

For each recommended guide, include the official opensource.guide URL and one short sentence on why it applies.

• Use the canonical URL from references/guide-map.md
• Do not shorten, guess, or rewrite article slugs
• Use the official article title exactly as written in references/guide-map.md

5. Stay advisory by default

Unless the user explicitly asks for drafting help:

• do not write a full CONTRIBUTING.md
• do not write a governance charter
• do not write a code of conduct
• do not generate a full legal policy

If the user does ask for an artifact, say which guide(s) you are basing it on and then draft only the requested artifact.

Routing Heuristics

Reach for these patterns first:

• Launch decision, project scope, expectations, readiness: starting-a-project
• How newcomers can help, contribution flow, first PR path: how-to-contribute
• Adoption, awareness, project discovery: finding-users
• Welcoming environment, community participation, contributor experience: building-community
• Maintainer workload, process clarity, saying no, automation: best-practices
• Shared decision-making, leadership models, formal rules: leadership-and-governance
• Sustainability, sponsorship, funding models: getting-paid
• Behavior expectations and enforcement norms: code-of-conduct
• Measuring health and progress: metrics
• Licensing and legal basics: legal
• Burnout, boundaries, maintainership balance: maintaining-balance-for-open-source-maintainers
• Security hygiene, project trust, dependency and vulnerability practices: security-best-practices-for-your-project

Common pairings:

• First launch + adoption: starting-a-project + finding-users
• Contributor growth + community experience: how-to-contribute + building-community
• Maintainer overload + burnout: best-practices + maintaining-balance-for-open-source-maintainers
• Governance + conduct expectations: leadership-and-governance + code-of-conduct
• Trust + sustainability for mature projects: security-best-practices-for-your-project + best-practices or getting-paid

Canonical title reminders:

• starting-a-project -> Starting an Open Source Project
• code-of-conduct -> Your Code of Conduct
• security-best-practices-for-your-project -> Security Best Practices for your Project