Skills / Contribute to open source
Contribute to open source
Make the person's first open source contribution. A real issue in a project they use, from fork to submitted change. Use when they say "I want to contribute to open source", "how do I make my first PR", or want public proof of work.
Use this skill. Nothing to install.
Don't have an agent? · Raw file: skills/contribute-to-open-source.md
Watch the first two minutes
This is how a session goes when someone is sure they don't belong in open source yet. Click through it.
Scripted example of a real session.
Feel like an imposter in open source?
The bar for a first contribution is lower and more useful than the imposter feeling suggests. Docs fixes, confusing error messages, and small reproducible bugs are all legitimate first issues, and nothing is beneath a first PR. The skill also skips the "good first issue" aggregators full of abandoned repos and starts from software you already use, because a typo you noticed or a setup step that failed for you is an issue you are uniquely qualified to fix. Projects on this site that practice the same muscles:
What you end up with
Every command runs in the sitting, so the session ends with the change submitted and the expectations set. End state of the session above:
Issue filed: #214 "Setup docs don't mention the bot token"
Claim comment: "Hit this setting up the bot for my server.
Happy to send a docs fix if that's welcome."
Fork: cloned, upstream remote added, bot running
locally by following the project's own docs
Branch: docs-token-setup
The change: 6 lines in README setup, including the exact
error you see when the token is missing
PR opened: links #214, states what changed, plain words
Expectations set: review may take days · requested changes
are the normal path to merge · reply within a day
Anatomy of a good first PR
The skill shapes the submission to this standard:
- A A title that says the change plainly. No "various improvements".
- B The linked issue, so reviewers see the why in one click.
- C What changed, in your words. Small and complete beats broad and half-done.
- D Proof you ran the project's own tests or checks first.
Questions people actually ask
Is a typo or docs fix a real contribution?
Yes. Docs fixes, error-message improvements, and small reproducible bugs all count, and nothing is beneath a first PR. A doc step that failed for you is a legitimate issue you can file and then fix.
What if the maintainers ignore me?
The skill checks the project's pulse before you invest: commits in the last month, maintainers responding to issues, a CONTRIBUTING file. A friendly small project beats a famous one, because first PRs to huge repos often sit unreviewed for months.
Do I ask before writing code?
Yes. You comment on the issue asking to take it, one or two sentences in your own words. That is the norm in open source, and it is also your first public interaction with the project.
What if they request changes on my PR?
Requested changes are the usual road to a merge, and the skill sets that expectation before you submit. Respond within a day when the review comes and keep the changes small.
How does this help my resume?
A merged PR on a project other people use is public, verifiable proof of work, exactly what a thin resume lacks. Once merged, the contribution goes on the resume with the PR link, and the build-resume skill shapes that line.
Where to go from here
PR submitted? Turn the momentum toward your own work:
Curious? Read the full skill — the exact instructions your agent gets
--- name: contribute-to-open-source category: start description: Make the person's first open source contribution. A real issue in a project they use, from fork to submitted change. Use when they say "I want to contribute to open source", "how do I make my first PR", or want public proof of work. --- # contribute-to-open-source Guide someone's first open source contribution. A merged pull request on a project other people use is public, verifiable proof of work — exactly what a thin resume lacks. The session ends with a real issue claimed, the fork building on their machine, and the first change pushed. Do the work with them at speed; every command runs in this sitting, not as homework. ## Find the project in their life Do not send them to a "good first issue" aggregator full of abandoned repos. Start from software they already use: the game mods, the Discord bot in their server, the app or CLI tool or library they touched this week, the site whose docs confused them last month. A contributor who uses the project writes better fixes and cares whether they land. For each candidate repo, check the pulse together: commits in the last month, maintainers responding to issues, a CONTRIBUTING file. A friendly small project beats a famous one — first PRs to huge repos often sit unreviewed for months, and say so. ## Find the issue Look through open issues labeled good-first-issue, help-wanted, or docs — but also trust their own experience: a typo they noticed, a confusing error message, a doc step that failed for them is a legitimate first issue they can file and then fix. Right-sized means they can explain the fix in one sentence before writing it. Docs fixes, error-message improvements, and small reproducible bugs all count; nothing is beneath a first PR. Before writing code, read `CONTRIBUTING.md`, the issue thread, and recent pull requests for the project's coordination norm. Comment to ask or state intent only when the project requests it; some projects do not assign issues. Check that no one is already doing the same work before starting. ## Fork, fix, submit All in this session, them at the keyboard where possible: 1. Fork on GitHub, clone the fork, add the upstream remote. 2. Get it building or running locally, following the project's own docs. If the docs fail, that failure is a contribution too — note exactly where. 3. Branch, make the change small and complete, run the project's tests or checks. 4. Commit with a message that says what and why, push, open the PR. The PR description links the issue and states what changed — their words, plain. 5. Set the expectation: review may take days, requested changes are normal and not rejection, and they should respond within a day when it comes. Once merged, the contribution goes on the resume with the PR link — https://sphinxstack.com/skills/build-resume/ shapes that line. If they liked the workflow, https://sphinxstack.com/skills/ship-on-github/ turns it toward projects of their own. ## Done - Active project and right-sized issue selected under its published contribution rules - Fork builds locally; focused change and relevant checks pass - Pull request submitted in the person's words with issue link and proof, or a documented maintainer-specific next step if submission is intentionally later