contributor

/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 として扱われます。そのため、1 回のクエリに複数のリポジトリを指定して 0 件が返っても、「これらのプロジェクトには対応可能な issue がない」と即断してはいけません。検索の意味に確信が持てない場合は、リポジトリごとに検索します。
   • gh が未認証でも、「対応できない」と判断する必要はありません。上記の読み取り専用の調査は、匿名の GitHub REST API ですべて実行できます。ただし、境界を明確にします。CLI 側で fork を作成して PR を開くには、認証済み API を使う方法しかありません（ウェブインターフェースから手動で行うことは可能です）。読み取り専用の取得と push には SSH を使用できます。gh の認証が失効していることが分かった場合（たとえば、トークンがシステムの keyring に保存されているものの、現在のプロセスから読み取れない場合）は、まずユーザーに説明して gh auth login の手順を案内します。黙って匿名アクセスに切り替えてはいけません。
   • 匿名リクエストには独立した、より低いレート制限があり、具体的な値は変更されるため、GitHub 公式の rate limit ドキュメントを参照してください。検索 API にレート制限枠を優先的に割り当てます。raw.githubusercontent.com、リポジトリの HTML ページ、git clone はこのレート制限枠を消費しません。CONTRIBUTING、AGENTS.md、CI 設定の確認には、これらを優先して使用します。
   • 全体検索で label:"good first issue" を指定すると、AI エージェントが一括で登録した疑いのあるリポジトリ（ラベルに agent-ready、worker:<model> が含まれ、短期間に同じリポジトリで issue が一括作成されているもの）が混在します。これは追加確認が必要な判断材料であり、除外基準ではありません。まず、issue の作成頻度、issue の質、メンテナーが応答しているかを確認してから、候補にするか判断します。

3. CONTRIBUTING とリポジトリ内のエージェント向け説明をざっと確認します。typo のみの修正、突発的なドキュメント修正、または現在提案している種類の PR が明確に禁止されている場合は、ineligible として記録し、確認待ち候補リストには含めません。ルールに issue の事前 claim、メンテナーの承認取得、または issue の事前作成が必要とある場合は、blocked として記録し、満たすべき前提条件を明記します。条件が満たされるまで、ブランチやパッチは作成しません。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 がすでにある場合、リポジトリから推奨される承認または割り当てをまだ得ていない場合、あるいは再現や検証に GPU／専用サービスが必要な場合は、優先度を適宜下げ、リスクを記載します。

4. 各候補について、ローカルで変更またはパッチを準備する前に、現在の上流ベースラインから専用の独立ブランチを作成します。デフォルトブランチを変更してはいけません。また、次のパッチを既存の PR ブランチに積み重ねてはいけません。その後、そのブランチ上で提案する最小限の変更またはパッチを実際に適用します。コミット前に、リポジトリの CONTRIBUTING、.github/workflows/、プロジェクトレベルのツール設定、プロジェクトレベルの pre-commit 設定（存在する場合）を確認し、リポジトリの実際の設定に基づいて、今回の変更に関連する検証コマンドを決めます。実行可能なテスト、lint、フォーマット、ビルド、リンクチェックを実行し、結果を記録します。軽微なドキュメント修正であっても、少なくとも diff と Markdown を確認し、完全な diff をユーザーに提示します。

5. fork、push、PR の作成は、いずれも外部への書き込み操作です。実行前に、対象リポジトリ、GitHub アカウント、ブランチ、ファイル、および実行される操作を明確に列挙する必要があります。初めて PR を作成する際は、提案する完全なタイトルと本文、およびコードの完全な diff も提示し、項目ごとにユーザーの確認を待ちます。「N 件探して」「自動でやって」「そのまま提出して」という指示は、候補の準備とローカル diff の作成のみを許可するものであり、まとめて書き込みを行う許可ではありません。

6. 確認済みの PR は、一度に 1 件だけ実行します。提出後は、現在の変更に関連する CI checks、required checks、レビュー、マージの状態のみを読み取り専用で追跡し、開始済みのチェックが完了するまで待ちます。GitHub ページに表示される状態を基準とし、次の 3 種類の状態を区別します。success（または pass）のみが合格です。pending、queued は進行中のため、引き続き待つ必要があります。action_required は一般に追加の操作または承認が必要であることを意味し、チェック合格とは見なせません。合格でも失敗でもありません。この状態になった場合は、まず該当 run の詳細を開いて原因を確認します（初めてコントリビュートする人の fork では、メンテナーが「Approve and run workflows」をクリックするのを待っているケースがよくあります。この場合に限り、「まだ実際に開始されていない」状態に該当します）。いずれの状態についても、ローカルで検証済みであることを CI の結果の代わりにしてはいけません。チェックに失敗した場合はログを読み、コードの問題、設定の問題、外部環境による阻害を区別し、最小限の修正案をまとめます。後続の commit、push、コメント、レビューの再依頼についても、確認ルールに従います。関連する required checks が未完了または失敗している場合、「検証済み」または「PR 完了」と報告してはいけません。既存 PR の CI またはレビューのコードフィードバックに対応する場合は、その PR の既存ブランチ上で作業を続けます。上流ベースラインから新しいブランチを作成したり、別の PR を開いたりしてはいけません。まず更新対象の PR、ブランチ、ファイル、commit／push／PR 更新の操作を説明し、パッチを適用して更新後の完全な diff を提示し、新たに項目ごとの明示的な確認を待ちます。コメントまたは返信だけが必要な場合は、投稿する正確な文面と投稿先を先に提示します。thread の解決だけが必要な場合は、解決対象の PR、thread のリンクまたはファイル行番号、議論の要約を先に列挙します。上記のいずれの外部書き込み操作についても、新たな明示的な確認を得るまでは、提案を記録するにとどめ、実行しません。PR がマージされた後は /great-resume の素材を作成します。クローズされた PR や未マージの PR は「オープンソースで協業中」と記録し、「採用された」とは記載しません。

複数のプロジェクトの準備を連続して行うことはできますが、外部への書き込み操作については、1 件ずつ確認を得る必要があります。各 PR で解決するのは、明確で小さな問題 1 つだけとします。タイトルと本文は対象リポジトリの言語で作成し、同じテンプレートをそのまま複数のプロジェクトに一斉送信してはいけません。

候補の順位付けでは、少なくともプロジェクトとの適合度、問題の実在性、コントリビューション方針、重複または競合のリスク、変更範囲、検証の実現可能性、ユーザーが得られる実践的な学習価値を考慮します。また、変更が焦点を絞れているか、競合リスクを抑えられるか、メンテナーが理解・検証しやすいかにも適切に配慮し、マージの可能性が比較的高い候補を優先して準備します。根拠が不足している候補、メンテナーの意図を推測する必要がある候補、または合理的に検証できない候補は、数をそろえるために確認待ちリストに含めてはいけません。

持续运行模式

当用户要求每天、每周或定期执行开源贡献 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 页面显示的状态为准：未合并写“已提交”“协作中”或页面上的实际状态，已合并写“已合并”。除非项目明确说明采用范围，不要把合并默认解释为“被项目采用”。