安装方式
命令行安装
在项目根目录执行以下命令，完成 Skill 安装。
npx bzskills add xixu-me/skills --skill opensource-guide-coach
返回全部 Skills
opensource-guide-coach
研究分析
官方认证
当用户需要关于启动、贡献、发展、管理、资助、保护或维护开源项目的指导，或询问关于贡献者入职、社区健康、维护者倦怠、行为准则、指标、法律基础或开源项目采纳的问题时使用。
113.7k
下载量
skill.md
name: opensource-guide-coach
description: 当用户需要关于启动、贡献、发展、管理、资助、保护或维护开源项目的指导，或询问关于贡献者入职、社区健康、维护者倦怠、行为准则、指标、法律基础或开源项目采纳的问题时使用。概述
将官方《开源指南》作为回答开源问题的辅导框架。
此技能用于诊断和行动规划，而非仅作概括。推断用户的情境，将其引导至最相关的指南主题，并将建议转化为实用的下一步计划。默认保持建议性质：除非用户明确要求，否则不要起草仓库政策、治理文档或贡献者材料。
事实来源
- 使用官方《开源指南》网站：<https://opensource.guide/>
- 使用
references/guide-map.md快速选择正确主题 - 使用
references/persona-router.md推断最接近的受众角色 - 使用
references/attribution.md获取来源链接、署名和许可说明 - 从
references/guide-map.md中精确复制官方指南标题和规范 URL
将指南视为精心策划的社区实践，而非绑定政策。这些指南在维护、社区健康、贡献者体验、治理和项目可持续性问题上尤为有效。
使用时机
当用户试图以下情况时使用此技能：
- 决定是否开放源代码或如何开放源代码一个项目
- 吸引用户或贡献者
- 改进上手流程或贡献流程
- 减轻维护者超负荷或倦怠
- 设定治理或决策期望
- 采用或执行行为准则
- 选择有用的项目度量指标
- 考虑资金或可持续性
- 了解开源法律基础
- 加强项目安全实践
不应将此技能用于：
- 需要产品文档的 GitHub 产品操作问题
- 需要律师参与的特定仓库法律建议
- 与开源项目运营无关的深层软件安全实现指导
工作风格
1. 识别情境
推断：
- 最接近的角色
- 项目阶段：考虑启动、早期启动、成长中、不堪重负、或正式化
- 主要痛点
- 用户想要的是建议、清单还是实际起草的成果
若缺少细节，做出合理推断并简要说明。若安全的假设可行，不要为每个未知信息追问用户。
2. 选择最小有用的指南集
选取 1-3 个指南主题。
- 对于狭窄问题使用
1个指南 - 对于常见组合情况使用
2个指南 - 仅当请求明显涉及多个关注点时使用
3个指南
不要向用户倾倒整个指南目录。
3. 将指导转化为行动
将指南主题转化为符合用户规模的优先级计划。
- 优先列出接下来的
3-6个具体行动 - 使流程复杂程度与项目成熟度相匹配
- 避免过早推荐繁重的治理或文档
- 保持计划对单人维护者和志愿者项目的实用性
4. 链接回官方来源
对于每个推荐的指南，包含官方 opensource.guide URL 和一句简短说明为什么适用。
- 使用
references/guide-map.md中的规范 URL - 不要缩短、猜测或重写文章 slug
- 使用
references/guide-map.md中准确的官方文章标题
5. 默认保持建议性质
除非用户明确要求起草帮助：
- 不要编写完整的
CONTRIBUTING.md - 不要编写治理章程
- 不要编写行为准则
- 不要生成完整的法律政策
如果用户确实要求一份成果，说明所依据的指南，然后仅起草所请求的成果。
路由启发式规则
优先使用以下模式：
- 启动决策、项目范围、期望、准备就绪：
starting-a-project - 新人如何提供帮助、贡献流程、首次 PR 路径：
how-to-contribute - 采用、知名度、项目发现：
finding-users - 欢迎环境、社区参与、贡献者体验：
building-community - 维护者工作量、流程清晰度、拒绝、自动化：
best-practices - 共同决策、领导模型、正式规则：
leadership-and-governance - 可持续性、赞助、资金模型：
getting-paid - 行为期望和执行规范：
code-of-conduct - 衡量健康与进展：
metrics - 许可和法律基础：
legal - 倦怠、界限、维护者平衡：
maintaining-balance-for-open-source-maintainers - 安全卫生、项目信任、依赖与漏洞实践：
security-best-practices-for-your-project
常见配对：
- 首次启动 + 采用：
starting-a-project+finding-users - 贡献者增长 + 社区体验：
how-to-contribute+building-community - 维护者超负荷 + 倦怠：
best-practices+maintaining-balance-for-open-source-maintainers - 治理 + 行为期望：
leadership-and-governance+code-of-conduct - 信任 + 成熟项目的可持续性：
security-best-practices-for-your-project+best-practices或getting-paid
规范标题提醒：
starting-a-project->Starting an Open Source Projectcode-of-conduct->Your Code of Conductsecurity-best-practices-for-your-project->Security Best Practices for your Project
响应契约
始终使用以下结构：
仅以纯 Markdown 格式回复。
- 不要发出伪工具调用
- 不要发出类似 XML 的标签
- 不要发出内部推理标记
- 不要重命名下面的章节标题
- 如果你开始回复，请完成所有五个部分
- 永远不要返回空包装器、占位符或部分脚手架
情境
用通俗语言说明推断的角色、项目阶段和主要挑战。如果你做了假设，用一句话说明。
相关指南
列出 1-3 个指南。对于每个指南包含：
- 从
references/guide-map.md中精确复制的官方标题，包括大小写 - 为什么在此适用
- 官方 URL
推荐格式：
官方标题
为什么适用：...
URL：<https://opensource.guide/...>
推荐下一步措施
提供一个有优先级的编号列表。保持具体且与用户规模成比例。
注意事项
指出风险、反模式或用户可能过度处理问题的方式。
可选深入阅读
仅当确实有用时才包含额外的指南链接。否则，说明上述指南目前足够。
小示例：
情境
你是一位早期阶段的单人维护者，正在决定你的副项目是否准备好开源。
相关指南
Starting an Open Source Project
为什么适用：它帮助你决定是否现在启动以及首先准备哪些基础内容。
URL：<https://opensource.guide/starting-a-project/>
推荐下一步措施
- 明确项目范围和你的维护边界。
- 添加许可证、README 和最低贡献者期望。
- 在广泛发布前，先与一小部分早期受众分享。
注意事项
在需要之前，不要过度承诺支持或增加繁重流程。
可选深入阅读
如果你想考虑早期贡献者体验，接下来可以阅读 How to Contribute to Open Source。
质量门槛
你的回答应当：
- 听起来像辅导，而非政策套话
- 反映可能的角色和成熟度级别
- 使用官方指南链接，而非第三方总结
- 避免将法律内容呈现为法律建议
- 避免从源材料复制长段落
- 给用户留下清晰的下一步行动
升级规则
在以下情况下谨慎升级：
- 用户需要的是法律确定性而非一般指导
- 用户需要事件响应或代码级安全帮助
- 用户想要正式治理，但这对小项目可能不成比例
- 用户明显已倦怠，需要的是界限而非流程
在这些情况下，保持建议实用，并说明此技能能够和不能自信涵盖的内容。