技能介绍

要解决的问题

开源社群容易把增长当成唯一目标：Discord 人数上涨、GitHub Issues 变多，看起来热闹，但贡献者可能没留下，维护者精力被消耗，新成员找不到上手路径。另一个常见问题是过早搭建 Stage 3 的治理和自动化，却在 0-200 人的种子阶段缺少创始人与核心用户的稳定连接。结果就是社群既没有形成贡献者漏斗，也没有形成可持续的内容、支持和拉新循环。

它如何工作

这个技能把社区建设当作产品和运营问题：先判断社群所处阶段，再配置平台结构、贡献者路径和大使机制。

Step 0 社群阶段评估：区分 Seed、Momentum 与 Flywheel。种子期目标是找到最投入的少数成员；增长期要让成员互相帮助并出现 power users；飞轮期要观察社群是否创造多于消耗的价值。
Step 1 平台设计：为开发者社群设计 Discord 结构，并完善 GitHub 社区健康要素，包括 CONTRIBUTING.md、CODE_OF_CONDUCT.md、ISSUE_TEMPLATE/、PULL_REQUEST_TEMPLATE.md、good first issues 标签，以及 48 小时内回应 Issues。
Step 2 贡献者上手：把首次贡献拆成漏斗，逐层降低摩擦；任何一步流失明显，就修这一步。
Step 3 大使计划：启动前检查是否有 50+ 活跃成员、大使能获得的产品价值，以及团队能提供的内容、素材和关注。
Step 4 社群飞轮：针对具体产品设计飞轮，并定位当前最薄弱的环节。
Step 5 交付物：输出社群 playbook 和 GitHub 健康检查清单，每条都应可直接执行。

适用边界与注意点

它适合已经有真实开源项目、社区入口和负责人参与的场景，不是单纯生成口号或自动运营工具。种子阶段仍需要创始人深度参与；Stage 2/3 的机制不能替代持续回应和产品价值。生成结果应结合社区既有规则校对，尤其涉及 CONTRIBUTING.md、行为准则和 PR 检查清单时。超过 40 行 CLI 输出时，按 SKILL.md 交给 /atlas-report 处理。