/contributor：做真实的开源贡献

可按需衔接这条流水线：

/contributor → /great-resume → /make-resume → /offer

从范围清晰、风险可控且能够验证的文档修复、坏链接、示例或小型代码改动开始，是一种低风险的开源参与方式。是否有更深的技术贡献，要根据项目规则、改动范围和验证结果评估。

核心目标与交付

这个 Skill 的核心是帮助用户完成一条真实的开源贡献路径：

发现合适项目 → 找到真实问题 → 准备最小改动 → 本地验证 → 经确认提交 PR → 跟踪结果

每次运行应尽量交付以下信息，而不是只给出泛泛的项目推荐：

• 项目候选：仓库链接、与目标岗位或技术栈的匹配理由、可观察到的维护迹象，以及许可证和贡献规则（能确认时）；
• 问题候选：issue、文件或可复现现象，是否已被认领、是否存在重复 PR，拟修改范围和预期影响；
• 本地结果：独立分支、实际 diff、验证命令和结果；
• PR 结果：目标仓库、目标分支、PR 标题与正文、PR 链接，以及 GitHub 页面显示的状态；
• 求职交接（可选）：只保留真实改动、个人贡献边界、证据链接和合并状态。

贡献过程讲解（What / Why / How）

在原有直接贡献流程中增加讲解，帮助用户理解已经完成的分析、改动和验证。按下列节点读取并应用贡献交付与面试准备，不增加必须先答题才能继续贡献的步骤：

• 确定候选后（第 1, 3 步）：说明仓库做什么、解决什么问题，以及为什么选择这个仓库和 Issue；把选择依据与用户提示中的岗位、技术方向或指定项目联系起来。
• 分析与修改时（第 4 步）：说明原来的行为为什么不符合预期、如何复现、根因在哪里、准备怎样修复及方案取舍；修改后结合实际文件和 diff 讲清改动、用到的语言/框架/工具及影响范围。
• 验证完成后（第 4 步）：解释实际运行的命令、结果证明了什么、还有哪些场景没有覆盖。
• 提交与跟踪后（第 5, 6 步）：分别说明 PR、CI、review 和合并状态，并保留相关链接；标明用户实际确认或参与的内容，以及 Agent 完成的内容。
• 本次流程结束时：在原有结果之后补充一张贡献事实卡，再给出数个基于本次 PR 的面试题与讲解。仅完成本地修改时如实写“尚未提交 PR”；仅查询状态或没有贡献结果时不生成空卡和无依据的面试题。

讲解面向当前用户，PR 标题和正文仍按下方“PR 怎么写”及目标仓库要求准备。原有求职交接继续保留；事实卡用于汇总过程证据，面试题用于巩固理解。

默认玩法

先问目标公司、岗位和 GitHub 用户名；用户没给技术栈时也可以直接从文档贡献开始。根据目标选择一种模式：

• 快速入门版：优先 typo、标点、Markdown、formatting、坏链接和 README 小修；
• 岗位匹配版：优先目标公司的项目、目标岗位常用技术栈，以及测试、示例和小 bug；
• 渐进版：先做一个范围清晰的小修，再评估与岗位相关、能够验证的功能或测试改动；不预设一定合并或一定适合写进简历。

用户不指定时默认渐进版。

贡献工作流

1. 在 GitHub 搜索与目标岗位、技术栈或用户指定方向匹配，且有近期维护迹象并允许外部贡献的项目。优先检查项目主页、默认分支活动、许可证、CONTRIBUTING、issue/PR 状态和明确的贡献入口；此阶段只读，不 fork、不 push。
2. 从 issue、讨论、README、docs、examples、tests 和代码注释中寻找真实、范围清晰且能够在本地验证的问题。优先处理用户可以复现、项目确实需要、又不会牵涉大范围设计的改动；同时搜索提交历史和必要的 blame，确认上游默认分支尚未修复。撞车判定以目标 issue 的 linked PR（gh api repos/<owner>/<repo>/issues/<N>/timeline）和 open PR 全量标题（gh pr list --state open）为准，关键词搜索仅作补充，候选较多或标题含糊时再按拟改文件路径过滤；发现相同问题或相同方案的 PR 即按第 3 步降级或丢弃。