contributor

/contributor: Make real open-source contributions

This pipeline can be connected as needed:

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

Starting with documentation fixes, broken links, examples, or small code changes that have a clear scope, controllable risk, and are verifiable is a low-risk way to participate in open source. Whether there is deeper technical contribution should be assessed based on project rules, change scope, and verification results.

Core goals and deliverables

The core of this Skill is to help users complete a real open-source contribution path:

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

Each run should deliver the following information as much as possible, rather than only giving general project recommendations:

• Project candidates: repository link, reasons for matching the target role or tech stack, observable maintenance signals, and license and contribution rules (when confirmable);
• Issue candidates: issue, file, or reproducible phenomenon, whether it has already been claimed, whether there is a duplicate PR, proposed change scope, and expected impact;
• Local results: independent branch, actual diff, verification commands, and results;
• PR results: target repository, target branch, PR title and body, PR link, and the status displayed on the GitHub page;
• Job-search handoff (optional): keep only real changes, personal contribution boundaries, evidence links, and merge status.

Contribution process explanation (What / Why / How)

Add explanations to the original direct contribution process to help users understand the completed analysis, changes, and verification. Read and apply the following at the following pointsContribution delivery and interview preparation, without adding a step that requires answering questions before continuing to contribute:

• After determining candidates (steps 1-3): explain what the repository does, what problem it solves, and why this repository and Issue were chosen; connect the basis for the choice to the role, technical direction, or specified project in the user's prompt.
• During analysis and modification (step 4): explain why the original behavior did not meet expectations, how to reproduce it, where the root cause is, how it is planned to be fixed, and the tradeoffs of the approach; after modification, explain the changes, the languages/frameworks/tools used, and the scope of impact based on the actual files and diff.
• After verification is complete (step 4): explain the commands actually run, what the results prove, and which scenarios are still not covered.
• After submission and tracking (steps 5-6): explain the PR, CI, review, and merge status separately, and keep the relevant links; indicate what the user actually confirmed or participated in, and what the Agent completed.
• At the end of this process: after the original results, add a contribution fact card, then provide several interview questions and explanations based on this PR. If only local modifications were completed, truthfully write "PR not yet submitted"; if only querying status or there are no contribution results, do not generate an empty card or unsupported interview questions.

The explanation is for the current user; the PR title and body should still be prepared according to the "How to write the PR" section below and the target repository's requirements. The original job-search handoff continues to be retained; the fact card is used to summarize process evidence, and the interview questions are used to consolidate understanding.

Default mode

First ask for the target company, role, and GitHub username; when the user has not given a tech stack, you can also start directly from documentation contributions. Choose one mode based on the goal:

• Quick start version: prioritize typos, punctuation, Markdown, formatting, broken links, and small README fixes;
• Role-matching version: prioritize the target company's projects, the tech stack commonly used for the target role, as well as tests, examples, and small bugs;
• Progressive version: first make a small fix with a clear scope, then evaluate feature or test changes that are relevant to the role and can be verified; do not assume it will definitely be merged or definitely be suitable to put on a resume.

When the user does not specify, default to the progressive version.

Contribution workflow

1. On GitHub, search for projects that match the target role, tech stack, or direction specified by the user, have signs of recent maintenance, and allow external contributions. Prioritize checking the project homepage, default branch activity, license,CONTRIBUTING, issue/PR status, and clear contribution entry points; at this stage it is read-only, do not fork and do not push.

2. From issues, discussions, README, docs, examples, tests, and code comments, look for problems that are real, have a clear scope, and can be verified locally. Prioritize changes that the user can reproduce, that the project actually needs, and that do not involve large-scale design; at the same time, search the commit history and, when necessary, blame to confirm that the upstream default branch has not already fixed it. Collision判定 is based on the target issue's linked PR (gh api repos/<owner>/<repo>/issues/<N>/timeline) and the full set of open PR titles (gh pr list --state open); keyword search is only supplementary, and when there are many candidates or the titles are vague, filter by the planned file paths; if a PR for the same problem or the same solution is found, downgrade or discard it according to step 3.

   Practical constraints for the read-only discovery stage:

   • When issue retrieval returns 0 results or the results are abnormal, first check the combination logic of the search mode and qualifiers, then judge the meaning of the results: in ordinary /search/issues search, multiple repo: qualifiers are treated as OR ; only in advanced search with advanced_search=true enabled are conditions joined by spaces treated as AND . Therefore, putting multiple repositories into the same query and returning 0 results cannot be directly read as "none of these projects have any issue worth doing"; when unsure about the semantics, switch to searching repository by repository.
   • gh When unauthenticated, there is no need to conclude "it cannot be done": the read-only discovery above can be completed entirely through the anonymous GitHub REST API. But the boundary must be clear—on the CLI side, creating a fork and opening a PR has only one path: the authenticated API(the web interface can do it manually), read-only fetching and push can go through SSH; when discovering that gh authentication has failed (for example, the token exists in the system keyring but the current process cannot read it), first explain to the user and give the gh auth login path, do not silently downgrade to anonymous.
   • Anonymous requests have a separate and lower quota, and the specific values will be adjusted, based on GitHub's official rate limit documentation ; quotas should be reserved first for the search API,raw.githubusercontent.com, repository HTML pages and git clone do not consume that quota, so when reading CONTRIBUTING、AGENTS.md and CI configuration, prioritize using them.
   • Global label:"good first issue" retrieval will be mixed with repositories suspected to be bulk-filled by AI agents (labels include agent-ready、worker:<model>, opening issues in bulk on the same repository within a short period). This isa filtering signal that requires further verification, it is not a basis for exclusion: first look at the issue-opening pace, issue quality, and whether the maintainers respond, then decide whether to keep or drop it.

3. Quickly review CONTRIBUTING and the agent instructions in the repository; if the rules explicitly prohibit typo-only, drive-by documentation, or the currently proposed PR type, mark it as ineligible and discard it, without adding it to the candidate list pending confirmation. If the rules require claiming the issue first, obtaining maintainer approval, or opening an issue first, mark it as blocked, and state the prerequisites to be met; do not create a branch or patch until the conditions are met. Use ineligibleonly when the project rules do not allow it or the target clearly does not match; if satisfying the prerequisites themselves requires an external write operation, each item must also be confirmed step by step according to step 5. Otherwise, form a candidate list stating the target repository, problem, files to be modified, verification method, and potential impact.

   Contribution thresholds are not only about documentation:CONTRIBUTING.md / AGENTS.md outside ofapplication-level checksare only exposed when a PR is actually opened, for example if a repository never mentions a CLA anywhere, and as soon as a PR is opened license/cla it is pending. Before opening a PR, first read severalchecks lists of historical PRs（gh pr checks <N> --repo <owner>/<repo>in the same repository), to confirm whether mandatory items such as a CLA assistant (license/cla), DCO bot, etc. already exist; the absence of documentation does not mean they do not exist. To allow candidates to be compared horizontally, record the issue creation time, most recent substantive update, current status, assignees, claims in comments, related open/closed PRs, and current upstream code evidence. If an issue is old, already has a clear claim or a PR with the same approach, has not yet obtained the repository-recommended approval/assignment, or requires a GPU/proprietary service to reproduce or verify, its priority may be appropriately lowered and the risk noted.

4. Before preparing local changes or a patch for each candidate, create an independent dedicated branch from the current upstream baseline; do not modify the default branch, and do not stack the next patch onto an existing PR branch. Then actually apply the proposed minimal change or patch on that branch. Before committing, first check the repository's CONTRIBUTING、.github/workflows/, project-level tool configuration, and project-level pre-commit configuration (if present), determine the verification commands relevant to the current change according to the repository's actual configuration, then run the executable tests, lint, formatting, build, or link checks and record the results; for purely documentation minor fixes, at least check the diff and Markdown, then show the complete diff to the user.

5. Forking, pushing, and submitting a PR are all external write operations. Before executing, you must explicitly list the target repository, GitHub account, branch, files, and actions to be produced; when submitting a PR for the first time, you must also show the proposed complete title and body, as well as the complete code diff, and wait for user confirmation one by one. "Find N" "do it automatically" or "submit directly" only authorizes preparing candidates and local diffs, not batch writes.

6. Execute only one confirmed PR at a time. After submission, track read-only the CI checks, required checks, review, and merge status related to the current change until the triggered checks are complete; use the status shown on the GitHub page as authoritative, and distinguish three states:success(or pass) is the only pass;pending、queued is in progress and requires continued waiting;action_required the general meaning of isfurther action or approval is required and cannot be regarded as the check passing, it is neither passing nor failing; when this occurs, first open the details of that run to confirm the reason (in a fork's first-time contributor's repository, a common reason is waiting for a maintainer to click Approve and run workflows once, and only then does it count as 'not yet truly started'). None of the three states allows filling in the CI conclusion with a local verification result. If the check fails, read the logs and distinguish between code issues, configuration issues, and external environment blockers, and put together a minimal fix plan; subsequent commit, push, comment, or re-request for review actions are still performed according to the confirmation rules. When the relevant required checks are incomplete or failing, do not report it as 'verification passed' or 'PR complete'. When handling CI or review code feedback on an existing PR, you must continue working on that PR's existing branch, and must not recreate a branch from the upstream baseline or open another PR; first explain the PR, branch, files, and commit/push/PR update actions to be updated, apply the patch and show the complete updated diff, then wait item by item for new explicit confirmation. If only a comment or reply is needed, first show the exact text to be published and its target; if only threads need to be resolved, first list the PRs to be resolved, thread links or file line numbers, and a discussion summary. Any of the above external write operations are only recorded as suggestions and not executed until new explicit confirmation is obtained. After a PR is merged, generate /great-resume material, and record closed or unmerged PRs as 'in open-source collaboration', not as 'has been adopted'.

Multiple projects can be prepared consecutively, but external write operations must be confirmed one by one. Each PR addresses only one clear small problem, and the title and body are written in the target repository's language, without blindly mass-sending the same template.

Candidate ranking should consider at least: the match between the project and the goal, the authenticity of the problem, contribution policies, duplication or collision risk, scope of changes, feasibility of verification, and the practical learning value the user can gain from it; and appropriately pay attention to whether the changes are focused, whether conflict risk is controllable, and whether it is easy for maintainers to understand and verify, so as to prioritize preparing candidates with higher potential merge feasibility. Candidates that lack evidence, require guessing the maintainer's intent, or cannot be reasonably verified should not enter the pending-confirmation list just to make up the numbers.

Continuous operation mode

When the user requests daily, weekly, or periodic execution of an open-source contribution routine, treat /contributor as a workflow that can be repeatedly invoked by a host scheduler, rather than implementing a timer within the skill. Codex Automation, cron, or another agent scheduler is responsible for waking it up; this skill only defines the behavior and handoff format for each run.

Each run is executed in the following order:

1. First perform a read-only check of the CI, review, comments, and merge status of existing PRs. Simple feedback can be organized into a fix plan, but external write operations such as comments, commits, pushes, and resolving threads are still confirmed item by item according to steps 5-6 of the contribution workflow.
2. Existing PRs that have not yet been merged do not block exploring new opportunities. Rotate candidates according to the user's target position, tech stack, and repository track, to avoid long-term concentration on the same organization or the same type of small fix.
3. By default, prepare at most 2 mutually independent, verifiable candidates and local diffs. Quantity is not a KPI; when candidates are vague, already claimed, have duplicate PRs, require large-scale design, or cannot be reasonably verified, it is acceptable to prepare only 1 or 0.
4. In addition to CONTRIBUTING and agent instructions, proactively check AGENTS.md、AI_POLICY.md, issue claim status, open/closed PRs, and the recent main branch, and record applicable manual approval or disclosure requirements.
5. For each candidate, separately provide the repository, problem, branch, files, complete diff, verification results, PR title, and body, and wait for the user to confirm each one before performing any external write operation.
6. At the end, output a daily report: existing PR status, repositories and candidates checked, PRs prepared or submitted, verification results, reasons for not continuing, and optional estimates of time or context consumed.

Continuous running mode must not lower the quality threshold because a target quantity has been set, nor may it evolve into bulk scanning, automated mass messaging, or circumventing repository contribution policies. When a host scheduler needs to be configured, read Daily routine example, and replace the roles, tracks, quantities, and times in it according to the user's goals; do not claim that the skill itself will run in the background.

How to write a PR

Before submitting a PR, first verify the upstream repository, target branch, user fork, working branch, and files to be committed; confirm that the diff only addresses the current issue and does not mix in unrelated files, secrets, personal information, or large amounts of automatically generated content. If the repository requires claiming an issue first, obtaining permission, or using a specific template, satisfy those conditions first.

The PR itself should stay short and normal, and must be based on actual changes that have already been completed. By default it includes:

• What was changed;
• Why it was changed;
• How it was checked;
• Related issue (if any).

After submission, record the PR link and the page status at that time; if CI fails or the maintainer requests changes, first organize the reasons and fix plan in read-only mode, then handle it according to step 6 of the contribution workflow. Leave the factual organization until /great-resume: generate job-seeking statements only based on actual changes, personal contribution boundaries, verification results, PR links, review/CI, and merge status, without presupposing job value or HR talking points.

After merging, hand it over to /great-resume

For each PR, organize:

• Repository, PR link, and merge time;
• Original issue and actual changes;
• Languages, tools, and verification methods used;
• Review/CI results;
• Result numbers that can be written into a resume, such as number of repositories, number of merged PRs, and number of fixes.

Then directly produce this handoff prompt:

Use /great-resume to organize, based on the GitHub contribution record below, project experience suitable for [target role], 2-3 resume bullet points, and an HR opening statement, strictly according to the actual changes, personal contribution boundaries, verification results, real PR links, and current merge status; do not write unmerged PRs as already adopted.

When the user is preparing to continue using /great-resume or /make-resume , also follow claim-evidence ledger to add a record: the original facts store the actual modifications, the evidence stores the PR link, review/CI, and merge status, and the personal boundary states the scope of documentation, testing, code, or other real contributions. Keep the status of unmerged PRs as "pending confirmation" or the candidate wording "in collaboration".

Contribution fact card and interview preparation

At the end of this contribution process, followContribution delivery and interview preparationOutput:

1. Contribution fact card: summarize the repository purpose, reasons for selection, Issue/PR links, problem and root cause, actual modifications and technologies used, verification commands and results, the respective scope of participation of the user/Agent, and the current PR, CI, review, and merge status.
2. Interview preparation: Generate several specific questions around this actual change, along with factual evidence, key points for answering, and follow-up questions, to help the user understand the project, the localization process, trade-off decisions, scope of impact, and the basis for verification. When the user has not yet answered, record it as "not practiced"; after an actual answer, record the understanding and items to be reinforced, without presuming mastery.

When public interview experience is needed for reference, retain it and read it as neededOpen-source contribution interview experience cases. The practice questions for this PR are based on the actual contribution, not on the premise of finding public cases; public cases and generated practice questions are labeled separately.

The final boundary

Base it on the status shown on the GitHub page: if not merged, write "submitted", "in collaboration", or the actual status on the page; if merged, write "merged". Unless the project explicitly states the scope of adoption, do not interpret merging by default as "adopted by the project".