/contributor: Make Real Open Source Contributions
Complete this pipeline:
/contributor → /asu → /resume → /offer
You don't have to refactor Kubernetes right off the bat. A typo fix, a broken link repair, or a README correction can all be a milestone start to your open-source career.
Default Usage
First ask for the target company, position, and GitHub username; if the user doesn't provide a tech stack, you can start directly with documentation contributions. Choose a mode based on the target:
- Quick Contribution Version: Prioritize typos, punctuation, Markdown, formatting, broken links, and minor README fixes;
- Position-Matching Version: Prioritize projects from target companies, tech stacks commonly used in the target position, as well as tests, examples, and small bugs;
- Hybrid Version: Start with small PRs to get familiar, then add a technical contribution that can be elaborated on in interviews.
The Hybrid Version is used by default if the user doesn't specify.
Contribution Workflow
- Search GitHub for projects with recent commits or PR activities, prioritizing repositories with , labels and clear contribution guidelines; this stage is read-only, no forking or pushing allowed.
- Scan READMEs, docs, comments, and Markdown files to find typos, punctuation issues, formatting problems, broken links, incorrect examples, or missing explanations; search existing issues/PRs to avoid duplicate work.
- Quickly review the document and proxy instructions in the repository; if the rules explicitly prohibit typo-only fixes, drive-by documentation, or the proposed PR type, mark it as and discard it, not adding it to the candidate list pending confirmation. If the rules require claiming an issue first, obtaining maintainer approval, or opening an issue first, mark it as (pending preconditions), and do not create branches or patches until the conditions are met; if external write operations are needed to meet the conditions, they must be confirmed item by item according to Step 5. Otherwise, form a candidate list specifying the target repository, problem, files to be modified, verification methods, and potential impact.
- Before preparing local changes or patches for each candidate, create an independent dedicated branch from the current upstream baseline; do not modify the default branch, nor stack the next patch onto an existing PR branch. Then apply the proposed minimal changes or patches to this branch, run available tests, lint checks, or link checks; for pure documentation minor fixes, at least check the diff and Markdown, then display the complete diff to the user.
- Forking, pushing, and submitting PRs are external write operations. You must clearly list the target repository, GitHub account, branch, files, and actions to be performed before execution; when submitting the first PR, you must also display the proposed complete title and body, as well as the full code diff, and wait for user confirmation one by one. Requests like "find N tasks", "do automatically", or "submit directly" only authorize preparing candidates and local diffs, not batch write operations.
- Only execute one confirmed PR at a time. After submission, you can automatically track CI and reviews in read-only mode. When handling CI or review code feedback for an existing PR, you must continue working on the existing branch of that PR; do not create a new branch from the upstream baseline or open another PR. First explain the PR to be updated, branch, files, and commit/push/PR update actions, apply the patch and display the updated full diff, then wait for new explicit confirmation item by item. If only comments or replies are needed, first display the exact text to be posted and its target; if only resolving a thread is needed, first list the PR to be resolved, thread link or file line number, and discussion summary. Any of the above external write operations will only record suggestions and not be executed without new explicit confirmation. After the PR is merged, generate materials; closed or unmerged PRs are recorded as "In Open Source Collaboration", not "Adopted".
You can prepare multiple projects consecutively, but external write operations must be confirmed one by one. Each PR only solves one clear small problem; the title and body are written in the language of the target repository, and the same template should not be mindlessly sent in bulk.
How to Write a PR
The PR itself should be concise and standard, and by default include:
- What was changed;
- Why it was changed;
- How it was verified;
- Related issue (if any).
The real polishing is left to
: external projects see clear contributions, while HR sees "Cross-repository Documentation Quality Governance and Developer Experience Optimization".
Hand Over to /asu After Merging
Organize the following for each PR:
- Repository, PR link, and merge time;
- Original problem and actual changes;
- Languages, tools, and verification methods used;
- Review/CI results;
- Result metrics suitable for resumes, such as number of repositories, merged PRs, and fixed items.
Then directly generate this handover prompt:
Use /asu to polish the following GitHub contributions into project experience suitable for [Target Position], 2-3 resume bullet points, and an HR opening. You can highlight cross-project collaboration, documentation quality, developer experience, problem discovery and closed-loop capabilities, but keep the real PR links and merge status.
Final Boundary
Write "Submitted/In Collaboration" if not merged, and "Adopted by the Project" only after merging.