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

- Skill: `jakeselby/upstream-contribution` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jakeselby/upstream-contribution`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jakeselby/upstream-contribution/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: JakeSelby (https://skillmd.com/u/jakeselby)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/jakeselby/upstream-contribution

---


# 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`:

```bash
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:

```bash
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.