How do I install the Upstream Contribution skill?

Run npx skillmds@latest add jakeselby/upstream-contribution in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Upstream Contribution safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: makes network calls. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Upstream Contribution?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Upstream Contribution free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Upstream Contribution?

JakeSelby (@jakeselby) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Upstream Contribution by jakeselby — Agent Skill

Name: Upstream Contribution
Rating: 4.5 (4 reviews)
Author: JakeSelby

Upstream Contribution

Contribute to a repository you do not own — an open-source project, another team's codebase, a vendor's SDK — from a fork, without burning maintainer trust. Use when the working repo has an `upstream` remote, when the user says "open a PR against <someone else's repo>", or before the first commit in any repo the user is a guest in.

JakeSelby Updated Sep 22, 2026

File contents

Upstream contribution

This repo is not yours. It belongs to its maintainers, with their own queue, their own conventions and their own history of unmerged good intentions. Act like a guest.

Remotes

origin is your fork. upstream is the project, and its push URL is set to no_push:

git remote set-url --push upstream no_push
git remote -v          # origin = fork, upstream = project (no_push)

The remote you type by reflex is the one that is safe to push to. Never commit to local main — keep it a clean mirror of upstream so rebases stay trivial:

git fetch upstream && git checkout main && git reset --hard upstream/main

Issue before code

For anything larger than a bug fix or a doc correction, open an issue and wait for a maintainer response before writing the implementation. Most projects have a graveyard of large unsolicited PRs. Volume of code is not what gets merged; agreement beforehand is.

Use the repo's issue templates. If the work is speculative, say so.

Branch and PR scope

Branch names: <issue-number>-brief-description when an issue exists, otherwise <area>-brief-description.
One concern per PR. Every file in the diff traces to the declared issue. Split an oversized PR before requesting review, not after.
Never change a default silently. The project runs inside other people's production. New behaviour arrives as a new parameter whose default preserves today's behaviour exactly.
Never bundle a refactor with a fix. An open "make it DRY" issue is not a licence to tidy code you happened to be near.
A return-type change is a breaking change, including swapping a third-party type for your own. Say so honestly in the PR; getting it wrong is how trust is lost.
Sweeping changes (docs, type hints, lint) go one module family per PR. A fifty-file sweep is unreviewable and will sit.

Before opening the PR

Run the project's own gates exactly as CI runs them; the verification.md rule applies with extra force here. Fill in the PR template's sections and delete none. Use the labels the project's release tooling reads; do not fight auto-labels.

Where the contributing guide actually lives

CONTRIBUTING.md is often a stub. Treat the CI workflow file, the lint config, the PR template and an existing module of the same kind as the in-repo sources of truth. If the real guide is behind a site that blocks fetches, a human opens it; do not guess at its contents.

Community

If the project has a chat or a regular contributor call, asking there is cheaper than a rejected PR.

---name: upstream-contributiondescription: Contribute to a repository you do not own — an open-source project, another team's codebase, a vendor's SDK — from a fork, without burning maintainer trust. Use when the working repo has an `upstream` remote, when the user says "open a PR against <someone else's repo>", or before the first commit in any repo the user is a guest in.---# Upstream contribution**This repo is not yours.** It belongs to its maintainers, with their own queue, their ownconventions and their own history of unmerged good intentions. Act like a guest.## Remotes`origin` is **your fork**. `upstream` is the project, and its push URL is set to `no_push`:```bashgit remote set-url --push upstream no_pushgit remote -v # origin = fork, upstream = project (no_push)```The remote you type by reflex is the one that is safe to push to. **Never commit to local`main`** — keep it a clean mirror of upstream so rebases stay trivial:```bashgit fetch upstream && git checkout main && git reset --hard upstream/main```## Issue before codeFor anything larger than a bug fix or a doc correction, **open an issue and wait for amaintainer response before writing the implementation.** Most projects have a graveyard oflarge unsolicited PRs. Volume of code is not what gets merged; agreement beforehand is.Use the repo's issue templates. If the work is speculative, say so.## Branch and PR scope- Branch names: `<issue-number>-brief-description` when an issue exists, otherwise `<area>-brief-description`.- **One concern per PR.** Every file in the diff traces to the declared issue. Split an oversized PR before requesting review, not after.- **Never change a default silently.** The project runs inside other people's production. New behaviour arrives as a new parameter whose default preserves today's behaviour exactly.- **Never bundle a refactor with a fix.** An open "make it DRY" issue is not a licence to tidy code you happened to be near.- **A return-type change is a breaking change**, including swapping a third-party type for your own. Say so honestly in the PR; getting it wrong is how trust is lost.- Sweeping changes (docs, type hints, lint) go one module family per PR. A fifty-file sweep is unreviewable and will sit.## Before opening the PRRun the project's own gates exactly as CI runs them; the `verification.md` rule applies withextra force here. Fill in the PR template's sections and delete none. Use the labels theproject's release tooling reads; do not fight auto-labels.## Where the contributing guide actually lives`CONTRIBUTING.md` is often a stub. Treat the CI workflow file, the lint config, the PR templateand an existing module of the same kind as the in-repo sources of truth. If the real guide isbehind a site that blocks fetches, a human opens it; do not guess at its contents.## CommunityIf the project has a chat or a regular contributor call, asking there is cheaper than arejected PR.

Frequently asked questions