opensource-guide-coach

Overview of opensource-guide-coach skill

What opensource-guide-coach actually does

opensource-guide-coach is a coaching skill that routes open source questions through the official Open Source Guides and turns them into practical next steps. It is not mainly a summarizer. Its real value is diagnosis: figuring out whether the user is dealing with launch readiness, contributor onboarding, governance, funding, metrics, legal basics, maintainer burnout, security, or community growth, then pointing to the smallest useful set of guides.

Best fit users and jobs to be done

This skill is best for maintainers, team leads, developer advocates, and consultants who need structured advice without inventing policy from scratch. It is especially useful when the problem is fuzzy, such as “our project has users but no contributors” or “we need healthier governance before growth.”

Why this skill is different from a generic prompt

A generic prompt may give plausible open source advice, but opensource-guide-coach skill has a clearer source of truth and routing workflow:

• it uses the official site at https://opensource.guide/
• it maps questions to specific guide topics via references/guide-map.md
• it infers audience fit via references/persona-router.md
• it keeps attribution and license boundaries visible via references/attribution.md

That makes it more reliable for advisory work, especially when you need source-backed recommendations rather than improvised best practices.

What it does not try to do

opensource-guide-coach is advisory by default. It does not automatically draft contributor docs, governance charters, or code of conduct text unless you explicitly ask for those artifacts. If you want final documents, use this skill first for diagnosis and plan-making, then ask for deliverables.

Strongest use cases

The skill is strongest when the user asks:

• whether a project is ready to open source
• why contributors are not sticking
• how to improve onboarding or community health
• what governance model fits the current stage
• how maintainers can reduce burnout
• which metrics matter for project health
• how to think about funding, legal basics, or security practices

Fit for consulting work

opensource-guide-coach for Consulting is a good fit when you need a repeatable framework for client discovery. It helps consultants turn ambiguous stakeholder concerns into a structured assessment, a prioritized action plan, and source-linked recommendations that are easier to defend in workshops or audits.

How to Use opensource-guide-coach skill

opensource-guide-coach install context

The repository does not publish a custom install command inside SKILL.md, so use your normal Skills workflow for the xixu-me/skills repository and target the opensource-guide-coach folder. A common pattern is:

npx skills add https://github.com/xixu-me/skills --skill opensource-guide-coach

After installation, verify the local skill includes:

• SKILL.md
• references/guide-map.md
• references/persona-router.md
• references/attribution.md

Files to read before first use

If you want to understand the skill quickly, read in this order:

1. skills/opensource-guide-coach/SKILL.md
2. skills/opensource-guide-coach/references/guide-map.md
3. skills/opensource-guide-coach/references/persona-router.md
4. skills/opensource-guide-coach/references/attribution.md

This path gives you the workflow first, then topic routing, then persona inference, then source and license constraints.

The minimum input this skill needs

For good opensource-guide-coach usage, provide:

• project stage
• who the maintainers are
• current pain point
• desired outcome
• constraints like time, budget, team size, or compliance needs

Weak input:

• “Help with my open source project.”

Strong input:

• “We maintain a 2-person infrastructure tool with growing usage but almost no outside contributions. Issues are unanswered for days, onboarding is unclear, and maintainers are burning out. Give us a 30-day action plan.”

How the skill thinks about your request

The skill works best when it can do three things in sequence:

1. infer the closest persona from references/persona-router.md
2. route to the smallest relevant set of official guides using references/guide-map.md
3. convert those guides into an action plan instead of a reading list

If your prompt omits persona or stage, the model has to guess, which lowers output quality.

A prompt pattern that works well

Use this structure for opensource-guide-coach guide quality results:

• context: what the project is and who runs it
• stage: pre-launch, early growth, mature, struggling, or governance transition
• pain: what is going wrong
• goal: what success looks like
• constraints: legal, staffing, budget, timeline
• output format: diagnosis, priorities, 30/60/90-day plan, guide links

Example:
“Use opensource-guide-coach. Diagnose our open source project as if you were advising maintainers. Identify likely persona, map us to the most relevant Open Source Guides, explain why those guides fit, and give a practical 60-day plan. Context: ...”

How to turn a rough question into a better one

If your first instinct is “How do we build community?”, expand it into specifics:

• what community exists now
• where people gather
• whether contributors drop off after first contact
• whether docs, triage, roadmap, or governance are the bottleneck

The skill is much better at choosing between building-community, how-to-contribute, best-practices, and leadership-and-governance when you describe the actual failure point.

Best workflow for real projects

A high-signal workflow is:

1. ask for diagnosis and guide routing
2. review the recommended guide URLs
3. ask for a prioritized plan tailored to your team
4. only then ask for artifacts like issue templates, onboarding checklists, or policy drafts

This preserves the main strength of opensource-guide-coach: choosing the right intervention before generating documents.

Using opensource-guide-coach for Consulting

For client work, ask the skill to produce:

• probable persona
• current maturity stage
• top 3 operating risks
• relevant official guide URLs
• recommended actions by effort and impact
• questions to validate in a stakeholder interview

That turns the skill into a lightweight assessment framework rather than a generic advice engine.

Source and attribution constraints

The skill is built on Open Source Guides content and explicitly points to CC-BY-4.0 notes in references/attribution.md. In practice, that means:

• summarize advice in your own words
• keep links to canonical guide URLs
• preserve attribution when quoting closely
• avoid copying large sections as if they were your own framework

This matters most for consultants, trainers, and anyone packaging outputs for clients.

Where the skill is strongest and weakest

Strong:

• advisory planning
• topic routing
• maintainer and community health questions
• structured next-step recommendations

Weaker:

• repo-specific implementation details without context
• legal review beyond guide-level basics
• security engineering decisions that need project internals
• auto-generating polished governance docs without explicit request

opensource-guide-coach skill FAQ

Is opensource-guide-coach good for beginners?

Yes. It is one of the better fits for beginners because the official guides are written for common open source situations, and the skill adds routing so the user does not have to know which topic to read first.

When should I use opensource-guide-coach instead of a normal prompt?

Use opensource-guide-coach when you want source-backed recommendations, persona-aware guidance, and a realistic action plan. If you only want a quick brainstorming list, a normal prompt may be enough.

Is this only for maintainers?

No. It also fits contributors, community managers, developer relations teams, foundation staff, and consultants. The persona router suggests that the skill is designed to adapt to different audiences rather than assuming every user is a senior maintainer.

Can opensource-guide-coach write policies or repo docs?

Not by default. The skill is intentionally advisory first. It is better at telling you which documents or decisions matter now than blindly drafting everything upfront.

Does it replace reading the Open Source Guides?

No. It shortens the path to the right pages. The main gain is faster diagnosis and better prioritization, not replacing the original guides.

Is opensource-guide-coach useful for mature projects?

Yes, especially for governance, sustainability, maintainer balance, contributor experience, metrics, and security practice questions. It is not only a launch-stage skill.

When is this skill a poor fit?

Skip it if you need:

• detailed legal counsel
• security incident response specifics
• project-specific technical architecture review
• direct moderation or HR handling for sensitive conflicts

In those cases, opensource-guide-coach skill can frame the problem, but it should not be the final authority.

How to Improve opensource-guide-coach skill

Start with diagnosis, not deliverables

The biggest mistake is asking for outputs like “write a code of conduct” before establishing whether conduct, onboarding, governance, or maintainer workload is the real bottleneck. Ask opensource-guide-coach to diagnose first.

Give stage, signals, and constraints

Better outputs come from concrete operational signals:

• number of maintainers
• issue backlog
• contributor drop-off points
• release cadence
• communication channels
• funding pressure
• governance confusion

These details help the skill route to the right official guides instead of mixing unrelated advice.

Ask for guide mapping explicitly

If you want trustable results, request:

• the inferred persona
• the chosen official guide titles
• the canonical URLs
• why each guide applies
• what to do first

That makes the reasoning inspectable and reduces generic filler.

Common failure modes to avoid

Typical weak-output causes:

• asking a broad question with no project context
• mixing too many goals into one request
• requesting final documents before strategy
• treating guide content as binding policy
• forgetting that the source is advisory community practice

Improve outputs with better prompt framing

A stronger prompt often includes a time horizon and decision pressure.

Example:
“Use opensource-guide-coach to help us decide what to do in the next 45 days, not long-term theory. We can only spend 4 maintainer-hours per week, and our main issue is contributor confusion during onboarding.”

This forces practical prioritization.

Iterate after the first answer

After the first response, do not just ask for “more detail.” Ask for one refinement:

• a narrower plan for one guide area
• tradeoffs between two interventions
• actions sorted by effort
• a version tailored to solo maintainers or enterprise-backed teams

That keeps the skill focused and increases usefulness.

Cross-check the cited sources

If the answer references a guide, open the matching URL from references/guide-map.md. This is especially important if you plan to share recommendations externally. The skill is more valuable when its advice stays traceable to the official source.

Adapt advice to your operating model

The official guides are broadly applicable, but your project may have unusual constraints: internal corporate approval, foundation governance, regulated industries, or a tiny maintainer pool. Tell the skill what cannot change so it can adapt recommendations instead of assuming a standard community playbook.

Use consulting-style outputs when stakes are high

For audits, client reports, or community strategy reviews, ask the opensource-guide-coach skill for:

• findings
• evidence signals
• guide mapping
• recommended actions
• open questions
• risks if no action is taken

This format is easier to review with stakeholders than a long narrative.

Know when to switch from coach to builder

Once opensource-guide-coach has identified the right next steps, switch to drafting mode only for the selected artifacts. That division of labor usually produces better final outputs than asking one prompt to diagnose, prioritize, and fully author every document at once.