upstream-pr

Source forks may change core freely. This skill applies only when an upstream contribution is requested; maintaining a local change does not require contributing it. Keep private deployment material in deploy/layers/<org>/ in a private source fork or in a separate private deployment repository for public source. Core means the runtime, plugins, CLI, docs, and CI, and may also contain private details that must be scrubbed.

Upstream qm is shared with organizations other than yours, and anything pushed there is permanent: it stays reachable by SHA in every clone and fork even after a deleted branch or a force-push. Treat a leak as unrecoverable and spend the effort before the push.

See deploy/layers/README.md for the boundary, and the update-qm skill for syncing the other direction.

Where the branch will go

git remote -v, the source tree, and repository metadata identify the situation. This decides the push target only; the scrub steps below run in every case.

• origin is yc-software/qm: you are in upstream qm. Push the branch to origin and open the PR there.
• origin is a GitHub fork of qm, meaning a repository created with GitHub's fork feature and living inside qm's fork network: push to origin and open a normal cross-repo PR.
• A standalone source fork: assume it may hold private material even if deploy/layers/ looks empty, and read "Pushing from a private fork" below.
• A package deployment or unrelated repository: prepare the contribution in a separate clean upstream checkout; never push its history to upstream.

Judge by where origin points, not by the repository's name. A repository named <org>/qm-<something> in the same GitHub organization as the source may still be a separate downstream repository.

Decide whether the change belongs upstream