---

name: contributor description: GitHub 开源贡献辅助技能：围绕目标岗位和技术栈发现合适的开源项目与真实问题，评估维护状态、贡献规则和重复风险，准备最小可验证改动，经用户逐项确认后 fork、push、提交 PR，并跟踪 CI、review 和合并状态；当用户输入“/contributor”、想寻找项目、做 first contribution、提交 PR 或把 PR 写进简历时使用。

/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 步降级或丢弃。

   只读发现阶段的实测约束：

   • issue 检索返回 0 条或结果异常时，先核对搜索模式与限定符的组合逻辑，再判断结果含义：在普通 /search/issues 搜索里，多个 repo: 限定符按 OR 处理；只有在启用 advanced_search=true 的高级搜索里，以空格连接的条件才按 AND 处理。因此把多个仓库写进同一次查询返回 0 条，不能直接读成「这些项目都没有可做的 issue」；对语义没有把握时改为逐仓库检索。
   • gh 未认证时不必判定「做不了」：上面的只读发现可以完整走匿名 GitHub REST API。但边界要分清——CLI 侧创建 fork 与开 PR 只有认证 API 一条路（网页界面可手工完成），只读拉取和 push 可走 SSH；发现 gh 认证失效（例如 token 存在系统 keyring 而当前进程读不到）时，先向用户说明并给出 gh auth login 路径，不要默默降级成匿名。
   • 匿名请求有独立且更低的配额，且具体数值会调整，以 GitHub 官方 rate limit 文档 为准；配额优先留给搜索接口，raw.githubusercontent.com、仓库 HTML 页和 git clone 不占该配额，读 CONTRIBUTING、AGENTS.md 和 CI 配置优先用它们。
   • 全局 label:"good first issue" 检索会混入疑似 AI agent 批量填报的仓库（标签含 agent-ready、worker:<model>，同一仓库短期内批量开 issue）。这是需要进一步核验的筛选信号，不是排除依据：先看开 issue 节奏、issue 质量与维护者是否回应，再决定取舍。

3. 快速看一遍 CONTRIBUTING 和仓库里的代理说明；如果规则明确禁止 typo-only、drive-by documentation 或当前拟议的 PR 类型，标记为 ineligible 并丢弃，不进入待确认候选清单。如果规则要求先 claim issue、取得 maintainer approval 或先开 issue，则标记为 blocked，写明待满足的前置条件；在条件满足前不创建分支或 patch。只有项目规则不允许或目标明显不匹配时才使用 ineligible；满足前置条件本身如需外部写操作，也必须按第 5 步逐项确认。否则形成候选清单，写明目标仓库、问题、拟修改文件、验证方式和潜在影响。

   贡献门槛不只看文档：CONTRIBUTING.md / AGENTS.md 之外的应用级检查只在真正开 PR 时才暴露，例如某仓库全文未提 CLA，PR 一开出来 license/cla 就 pending。 开 PR 前先读几条同仓库历史 PR 的 checks 列表（gh pr checks <N> --repo <owner>/<repo>），确认是否已有 CLA assistant（license/cla）、DCO bot 之类的强制项；文档没写不等于没有。 为了让候选可以横向比较，记录 issue 创建时间、最近实质更新、当前状态、assignees、评论中的认领、相关 open/closed PR 以及当前上游代码证据。issue 时间较久、已有明确认领或相同方案的 PR、尚未取得仓库建议的 approval/assignment，或需要 GPU/专有服务才能复现或验证时，可适当降低优先级并标注风险。

4. 每个候选在准备本地改动或 patch 前，都从当前上游基线创建独立专用分支；不得修改默认分支，也不得把下一份补丁堆叠到已有 PR 分支。随后在该分支上实际应用拟议的最小改动或 patch。提交前先检查仓库的 CONTRIBUTING、.github/workflows/、项目级工具配置以及项目级的 pre-commit 配置（存在时），根据仓库实际配置确定与当前改动相关的验证命令，再运行可执行的测试、lint、格式、构建或链接检查，并记录结果；纯文档小修至少检查 diff 和 Markdown，然后把完整 diff 展示给用户。

5. fork、push、提交 PR 都是外部写操作。必须在执行前明确列出目标仓库、GitHub 账号、分支、文件和将产生的动作；首次提交 PR 时还必须展示拟议的完整标题和正文，以及完整代码 diff，并逐个等待用户确认。“找 N 个”“自动做”或“直接提”只授权准备候选和本地 diff，不授权批量写入。

6. 每次只执行一个已确认的 PR。提交后应只读跟踪与当前改动相关的 CI checks、required checks、review 和合并状态，直到已触发的检查完成；以 GitHub 页面显示的状态为准，并区分三种状态：success（或 pass）才是通过；pending、queued 是进行中，需要继续等待；action_required 的通用含义是需要进一步操作或审批，不能视为检查通过，既不是通过也不是失败；遇到时应先打开该 run 的详情确认原因（fork 首次贡献者的仓库里，常见原因是等待维护者点一次 Approve and run workflows，此时才属于「尚未真正开始」）。三种状态都不能拿本地跑过的验证去填 CI 的结论。若检查失败，读取日志并区分代码问题、配置问题和外部环境阻塞，整理最小修复方案；后续 commit、push、评论或重新请求 review 仍按确认规则执行。相关 required checks 未完成或失败时，不汇报为“验证通过”或“PR 完成”。处理已有 PR 的 CI 或 review 代码反馈时，必须在该 PR 现有分支上继续工作，不得重新从上游基线创建分支或另开 PR；先说明要更新的 PR、分支、文件和 commit/push/PR 更新动作，应用补丁并展示更新后的完整 diff，再逐项等待新的明确确认。若只需评论或回复，先展示将发布的准确文本及其目标；若只需解决 thread，先列出将解决的 PR、thread 链接或文件行号和讨论摘要。以上任何外部写操作在未取得新的明确确认前都只记录建议、不执行。PR 合并后生成 /great-resume 素材，关闭或未合并的 PR 记录为“开源协作中”，不写成“已被采用”。

可以连续准备多个项目，但外部写操作必须逐个确认。每个 PR 只解决一个清楚的小问题，标题和正文按目标仓库的语言写，不把同一段模板无脑群发。

候选排序至少考虑：项目与目标的匹配度、问题真实性、贡献政策、重复或撞车风险、改动范围、验证可行性，以及用户能从中获得的实际学习价值；并适当关注改动是否聚焦、冲突风险是否可控、维护者是否容易理解和验证，以优先准备潜在合并可行性较高的候选。缺少证据、必须猜测维护者意图或无法合理验证的候选，不应为了凑数量进入待确认清单。

持续运行模式

当用户要求每天、每周或定期执行开源贡献 routine 时，把 /contributor 作为可由宿主调度器重复调用的工作流，而不是在 skill 内实现定时器。Codex Automation、cron 或其他 agent scheduler 负责唤醒；本 skill 只定义每次运行的行为与交接格式。

每次运行按以下顺序执行：

1. 先只读检查已有 PR 的 CI、review、评论和合并状态。简单反馈可以整理成修复方案，但评论、commit、push、解决 thread 等外部写操作仍按贡献工作流第 5—6 步逐项确认。
2. 已有 PR 尚未合并不阻塞探索新机会。按用户的目标岗位、技术栈和仓库赛道轮换候选，避免长期集中在同一组织或同一类型的小修。
3. 默认准备最多 2 个彼此独立、可验证的候选和本地 diff。数量不是 KPI；候选含糊、已被认领、存在重复 PR、需要大范围设计或无法合理验证时，可以只准备 1 个或 0 个。
4. 除 CONTRIBUTING 和代理说明外，主动检查 AGENTS.md、AI_POLICY.md、issue 认领状态、open/closed PR 和近期主分支，记录适用的人工审批或披露要求。
5. 为每个候选单独给出仓库、问题、分支、文件、完整 diff、验证结果、PR 标题和正文，等待用户逐个确认后再执行任何外部写操作。
6. 结束时输出日报：已有 PR 状态、检查过的仓库与候选、准备或提交的 PR、验证结果、未继续的原因，以及可选的时间或上下文消耗估算。

持续运行模式不得因为设定了目标数量而降低质量门槛，也不得演变成批量扫描、自动群发或绕过仓库贡献政策。需要配置宿主调度器时，读取 每日 routine 示例，按用户目标替换其中的岗位、赛道、数量和时间；不要声称 skill 自身会在后台运行。

PR 怎么写

提交 PR 前，先核对上游仓库、目标分支、用户 fork、工作分支和待提交文件；确认 diff 只解决当前问题，没有混入无关文件、密钥、个人资料或自动生成的大量内容。若仓库规定需要先认领 issue、取得许可或使用特定模板，先满足这些条件。

PR 本体保持短小正常，且必须基于已经完成的实际改动，默认包含：

• 改了什么；
• 为什么改；
• 怎么检查的；
• 关联 issue（如果有）。

提交后记录 PR 链接和当时的页面状态；如果 CI 失败或维护者提出修改，先只读整理原因和修复方案，再按贡献工作流第 6 步处理。事实整理留到 /great-resume：只根据实际改动、个人贡献边界、验证结果、PR 链接、review/CI 和合并状态生成求职表述，不预设岗位价值或 HR 话术。

合并后交给 /great-resume

为每个 PR 整理：

• 仓库、PR 链接和合并时间；
• 原问题与实际改动；
• 使用的语言、工具和验证方式；
• review/CI 结果；
• 可写进简历的结果数字，例如仓库数、合并 PR 数、修复项数。

然后直接产出这段交接提示：

用 /great-resume 根据下面的 GitHub 贡献记录，严格按照实际改动、个人贡献边界、验证结果、真实 PR 链接和当前合并状态，整理适合【目标岗位】的项目经历、2—3 条简历要点和 HR 开场白；不要把未合并 PR 写成已采用。

用户准备继续使用 /great-resume 或 /make-resume 时，同时按 主张—证据账本 新增一条记录：原始事实保存实际修改，证据保存 PR 链接、review/CI 和合并状态，个人边界写明文档、测试、代码或其他真实贡献范围。未合并 PR 的状态保持“待确认”或候选表述“协作中”。

贡献事实卡与面试准备

本次贡献流程结束时，按贡献交付与面试准备输出：

1. 贡献事实卡：汇总仓库用途、选择理由、Issue/PR 链接、问题和根因、实际修改及所用技术、验证命令与结果、用户/Agent 各自的参与范围，以及当前 PR、CI、review 和合并状态。
2. 面试准备：围绕本次真实改动生成数个具体问题，配上事实依据、回答要点和进一步追问，帮助用户理解项目、定位过程、方案取舍、影响范围和验证依据。用户尚未回答时记为“未练习”；实际回答后再记录理解情况和待巩固项，不推定已经掌握。

需要公开面经作参考时，保留并按需读取开源贡献面经案例。本次 PR 的练习题以实际贡献为依据，不以找到公开案例为前提；公开案例和生成的练习题分别标注。

最后一道边界

以 GitHub 页面显示的状态为准：未合并写“已提交”“协作中”或页面上的实际状态，已合并写“已合并”。除非项目明确说明采用范围，不要把合并默认解释为“被项目采用”。