开源贡献指南

要解决的具体问题

很多第一次参与开源的人会卡在同一个地方：不知道从哪个项目开始，分不清哪些 issue 值得尝试，也不确定 PR 该写什么、review 意见怎么回应。另一个常见场景是团队维护内部开源项目，希望吸引外部贡献，但没有清晰的外部贡献路径。已经提交 PR 的人也可能在被拒后不知道如何判断是技术问题、沟通问题，还是贡献方向不匹配。

这个技能如何工作

@kunlungrowth/open-source-contrib 的角色是开源贡献教练，覆盖从选项目、读规范、认领 Issue，到开发、提 PR、应对评审的完整流程。核心工作流如下：

• 选项目：优先找带有 good first issue 或 help wanted 标签、最近一个月有 commit，并且提供 CONTRIBUTING.md 的项目。
• 读规范：先阅读 CONTRIBUTING.md，确认提交规范、测试要求、CLA 等约束；同时看 CODE_OF_CONDUCT.md，判断社区协作边界。
• 认领 Issue：在目标 Issue 下留言 I'd like to work on this，等待维护者确认，避免重复劳动。
• 开发：Fork 后按 feat/xxx 或 fix/xxx 命名分支，补齐代码与测试，并确保本地测试全部通过。
• 提 PR：关联 Issue、描述改动内容、附测试结果；如果是 UI 变更，补充截图。标题采用 [类型] 简短描述 的格式。
• 应对评审：CI 失败先修复；review 意见逐条处理；如果 PR 被拒，感谢反馈并把经验用于下一次贡献。

输出规范包括 PR 模板、Issue 模板和首次贡献者检查清单，细节指向 references/template.md。技能还会生成 ContributionPlan 工件，可与 git-advanced 做 rebase、与 code-review 做自查串联。

适用边界与注意点

它适合想从零开始参与开源、维护者希望引入外部贡献，或 PR 被拒后需要复盘的人。它不适用于直接 fork 后做闭源二次开发的场景。使用时要注意：CLA、分支命名、测试要求和沟通礼仪因项目而异，不能把某一套模板当成所有仓库的通用答案；最终判断仍要以目标仓库的规范和评审意见为准。