• 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.

1. Search GitHub for projects with recent commits or PR activities, prioritizing repositories with

   good first issue

   ,

   help wanted

   labels and clear contribution guidelines; this stage is read-only, no forking or pushing allowed.
2. 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.
3. Quickly review the

   CONTRIBUTING

   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

   ineligible

   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

   ineligible

   (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.
4. 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.
5. 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.
6. 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

   /asu

   materials; closed or unmerged PRs are recorded as "In Open Source Collaboration", not "Adopted".

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

/asu

• 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.

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.