contributor

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

# /contributor：做真实的开源贡献

可按需衔接这条流水线：

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

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

## 核心目标与交付

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

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

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

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

## 默认玩法

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

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

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

## 贡献工作流

1. 在 GitHub 搜索与目标岗位、技术栈或用户指定方向匹配，且有近期维护迹象并允许外部贡献的项目。优先检查项目主页、默认分支活动、许可证、`CONTRIBUTING`、issue/PR 状态和明确的贡献入口；此阶段只读，不 fork、不 push。
2. 从 issue、讨论、README、docs、examples、tests 和代码注释中寻找真实、范围清晰且能够在本地验证的问题。优先处理用户可以复现、项目确实需要、又不会牵涉大范围设计的改动；同时搜索 open/closed issue、PR、提交历史和必要的 blame，避免撞车。
3. 快速看一遍 `CONTRIBUTING` 和仓库里的代理说明；如果规则明确禁止 typo-only、drive-by documentation 或当前拟议的 PR 类型，标记为 `ineligible` 并丢弃，不进入待确认候选清单。如果规则要求先 claim issue、取得 maintainer approval 或先开 issue，则标记为 `blocked`，写明待满足的前置条件；在条件满足前不创建分支或 patch。只有项目规则不允许或目标明显不匹配时才使用 `ineligible`；满足前置条件本身如需外部写操作，也必须按第 5 步逐项确认。否则形成候选清单，写明目标仓库、问题、拟修改文件、验证方式和潜在影响。
   为了让候选可以横向比较，记录 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 页面显示的状态为准。若检查失败，读取日志并区分代码问题、配置问题和外部环境阻塞，整理最小修复方案；后续 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 示例](references/daily-routine.md)，按用户目标替换其中的岗位、赛道、数量和时间；不要声称 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` 时，同时按 [主张—证据账本](../great-resume/references/claim-evidence-ledger.md) 新增一条记录：原始事实保存实际修改，证据保存 PR 链接、review/CI 和合并状态，个人边界写明文档、测试、代码或其他真实贡献范围。未合并 PR 的状态保持“待确认”或候选表述“协作中”。

## 最后一道边界

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