Open Source Contributions
The Golden Rule
Make it easy for maintainers to absorb your contribution. Maintainers are often under-resourced volunteers or small teams. Every friction point you remove — unclear reproduction steps, missing tests, bad commit messages, force-pushed history — is time they don't have to spend figuring out what you did and why. The whole point is to help them, not create more work.
When to Use This Skill
- Filing a bug report or feature request on a public repository
- Preparing a pull request for any open source project
- Working on a project without documented contributing guidelines (default posture)
- Reviewing your own PR before submission
- Setting up open source conventions for your own project
Load the relevant phase reference for detailed instructions.
Quick Phase Overview
| Phase |
What It Covers |
Reference |
| 0a — Maintainer Conventions |
README discipline, LICENSE, CONTRIBUTING.md, issue/PR templates, commit conventions, DCO, release workflow hygiene |
references/phase-0a-maintainer-conventions.md |
| 0 — Before You Start |
Reading CONTRIBUTING.md, checking existing issues/PRs, triaging bugfix candidates, large-change discussion etiquette |
references/phase-0-before-you-start.md |
| 1 — Filing Issues |
Bug report and feature request templates, agent disclosure, maintainer workflow ("issue first"), coordinated multi-issue roadmaps, multi-PR plan execution |
references/phase-1-filing-issues.md |
| 2 — Pull Requests |
Branching conventions, scope assessment, studying existing implementations, cross-repo comparison, commit messages, PR templates, documentation audits, CI setup |
references/phase-2-pull-requests.md |
| 3 — After Submitting |
CI monitoring, responding to review feedback, what to do if your PR goes stale or gets closed |
references/phase-3-after-submitting.md |
| 3.5 — Follow-up After Scope Feedback |
Systematic call-site audits, filing comprehensive issues, complementary PRs when maintainer scope notes identify gaps |
references/phase-35-followup.md |
| 4 — Release Process |
Version bumping, tagging, GitHub Releases vs tags, release workflow anatomy, handling failed releases |
references/phase-4-release-process.md |
Default Posture (No CONTRIBUTING.md)
When a project has no contributing guide, load references/default-posture.md for defensible defaults on issue filing, PRs, communication norms, and code of conduct.
Agent-Specific Checklist
If you are an AI agent filing or contributing on behalf of a human, load references/agent-checklist.md before submitting anything.
Pitfalls
Load references/pitfalls.md when you're about to submit an issue or PR, or when something goes wrong. Covers: backtick expansion, silent label failures, force-push etiquette, the "I'll just fix it quickly" trap, cross-fork PR issues, post-merge scope creep, the installed-code trap, CI debugging, and more.
The Agent-Specific Rule
When filing an issue on behalf of a human, always disclose the agentic nature. Add this line at the bottom of the issue body:
Filed by {{AGENT_NAME}} (AI agent on behalf of {{HUMAN_NAME}})
This is a transparency requirement, not a courtesy. Maintainers deserve to know who they're talking to.
Quick Reference Card
| Step |
Action |
Command / Check |
| 0 |
Read contributing guide |
cat CONTRIBUTING.md or .github/CONTRIBUTING.md |
| 0 |
Check existing issues |
gh issue list --search "topic" --state all |
| 1 |
File a bug/feature |
Use template if provided; include reproduction for bugs |
| 2 |
Issue first before coding |
File issue, wait for maintainer feedback, then branch |
| 3 |
Branch |
git checkout -b fix/description |
| 4 |
Commit |
git commit -s -m "fix: description" |
| 5 |
Run tests locally |
make test or npm test or pytest |
| 6 |
Push |
git push -u origin HEAD |
| 7 |
Open PR |
Fill out PR template completely. Use --body-file for complex bodies |
| 8 |
Monitor CI |
gh pr checks --watch |
| 9 |
Address review |
Respond to comments, push fixup commits. No force-push after review |
| 10 |
After merge |
git checkout main && git pull && git tag vX.Y.Z && git push origin main --tags |
| 11 |
Create Release |
gh release create vX.Y.Z --title "vX.Y.Z — Title" --notes-file /tmp/notes.md |
When NOT to Use This Skill
- You're the sole maintainer of a project with no external contributors and no public collaborators
- You're making a trivial single-line fix to your own code
- The contribution is internal (same organization, same team) with established workflow norms
- You already know the project's contributing guidelines by heart and this is routine
- The issue is a security vulnerability — follow the project's security disclosure policy instead
1---2name: opensource-contributions3description: Make good open source contributions — check CONTRIBUTING.md first, follow project norms, be a good citizen. Covers bug reports, feature requests, and pull requests with a defensible default posture when the project hasn't documented expectations. Do not use this skill for unrelated requests; route to the nearest named specialist.4license: MIT5---67# Open Source Contributions89## The Golden Rule1011**Make it easy for maintainers to absorb your contribution.** Maintainers are often under-resourced volunteers or small teams. Every friction point you remove — unclear reproduction steps, missing tests, bad commit messages, force-pushed history — is time they don't have to spend figuring out what you did and why. The whole point is to *help* them, not create more work.1213## When to Use This Skill1415- Filing a bug report or feature request on a public repository16- Preparing a pull request for any open source project17- Working on a project without documented contributing guidelines (default posture)18- Reviewing your own PR before submission19- Setting up open source conventions for your own project2021**Load the relevant phase reference for detailed instructions.**2223---2425## Quick Phase Overview2627| Phase | What It Covers | Reference |28|-------|----------------|-----------|29| **0a — Maintainer Conventions** | README discipline, LICENSE, CONTRIBUTING.md, issue/PR templates, commit conventions, DCO, release workflow hygiene | `references/phase-0a-maintainer-conventions.md` |30| **0 — Before You Start** | Reading CONTRIBUTING.md, checking existing issues/PRs, triaging bugfix candidates, large-change discussion etiquette | `references/phase-0-before-you-start.md` |31| **1 — Filing Issues** | Bug report and feature request templates, agent disclosure, maintainer workflow ("issue first"), coordinated multi-issue roadmaps, multi-PR plan execution | `references/phase-1-filing-issues.md` |32| **2 — Pull Requests** | Branching conventions, scope assessment, studying existing implementations, cross-repo comparison, commit messages, PR templates, documentation audits, CI setup | `references/phase-2-pull-requests.md` |33| **3 — After Submitting** | CI monitoring, responding to review feedback, what to do if your PR goes stale or gets closed | `references/phase-3-after-submitting.md` |34| **3.5 — Follow-up After Scope Feedback** | Systematic call-site audits, filing comprehensive issues, complementary PRs when maintainer scope notes identify gaps | `references/phase-35-followup.md` |35| **4 — Release Process** | Version bumping, tagging, GitHub Releases vs tags, release workflow anatomy, handling failed releases | `references/phase-4-release-process.md` |3637### Default Posture (No CONTRIBUTING.md)3839When a project has no contributing guide, load `references/default-posture.md` for defensible defaults on issue filing, PRs, communication norms, and code of conduct.4041### Agent-Specific Checklist4243If you are an AI agent filing or contributing on behalf of a human, load `references/agent-checklist.md` before submitting anything.4445### Pitfalls4647Load `references/pitfalls.md` when you're about to submit an issue or PR, or when something goes wrong. Covers: backtick expansion, silent label failures, force-push etiquette, the "I'll just fix it quickly" trap, cross-fork PR issues, post-merge scope creep, the installed-code trap, CI debugging, and more.4849---5051## The Agent-Specific Rule5253When filing an issue on behalf of a human, **always disclose the agentic nature.** Add this line at the bottom of the issue body:5455```56Filed by {{AGENT_NAME}} (AI agent on behalf of {{HUMAN_NAME}})57```5859This is a transparency requirement, not a courtesy. Maintainers deserve to know who they're talking to.6061---6263## Quick Reference Card6465| Step | Action | Command / Check |66|------|--------|-----------------|67| 0 | Read contributing guide | `cat CONTRIBUTING.md` or `.github/CONTRIBUTING.md` |68| 0 | Check existing issues | `gh issue list --search "topic" --state all` |69| 1 | File a bug/feature | Use template if provided; include reproduction for bugs |70| 2 | Issue first before coding | File issue, wait for maintainer feedback, then branch |71| 3 | Branch | `git checkout -b fix/description` |72| 4 | Commit | `git commit -s -m "fix: description"` |73| 5 | Run tests locally | `make test` or `npm test` or `pytest` |74| 6 | Push | `git push -u origin HEAD` |75| 7 | Open PR | Fill out PR template completely. Use `--body-file` for complex bodies |76| 8 | Monitor CI | `gh pr checks --watch` |77| 9 | Address review | Respond to comments, push fixup commits. No force-push after review |78| 10 | After merge | `git checkout main && git pull && git tag vX.Y.Z && git push origin main --tags` |79| 11 | Create Release | `gh release create vX.Y.Z --title "vX.Y.Z — Title" --notes-file /tmp/notes.md` |8081---8283## When NOT to Use This Skill8485- You're the sole maintainer of a project with no external contributors and no public collaborators86- You're making a trivial single-line fix to your own code87- The contribution is internal (same organization, same team) with established workflow norms88- You already know the project's contributing guidelines by heart and this is routine89- The issue is a security vulnerability — follow the project's security disclosure policy instead
magnus919