# Git Upstream Fix Check

> Check upstream HEAD before patching vendored, tarball-installed, or forked code. Use when patching a dependency, custom node, or fork you don't own.

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

---


# /git:upstream-fix-check

Fires when you are about to edit third-party code inside the project — a path
under `vendor/`, `site-packages/`, `node_modules/`, `custom_nodes/`,
`third_party/`, or a fork checkout. Every command below is GitHub-specific
(`gh`); vendored code from GitLab/Codeberg/sourcehut has no recipe here. See
`git-plugin:gh-cli-agentic` for the raw `gh api contents` command form,
`git-plugin:git-fork-workflow` once you have confirmed upstream carries the fix,
`git-plugin:git-upstream-pr` for the contribute-back handoff, and
`workflow-orchestration-plugin:workflow-verify-before-filing` for the different
case of a *backlog* of N accumulated bug candidates you are about to file.

Before patching third-party code that lives inside the project (a
custom ComfyUI node, a vendored library, a tarball-installed package,
a fork checkout), check whether the bug is already fixed upstream.
A 30-second `gh` lookup often replaces a 30-minute patch and a PR
the maintainer will close as duplicate.

## Quick checks

```sh
# Read one file at upstream HEAD without cloning
gh api repos/<owner>/<repo>/contents/<path> --jq '.content' | base64 -d

# See what changed since the local copy's version
gh api repos/<owner>/<repo>/contents/<path>?ref=<sha-or-tag> ...

# Default branch + last activity (catches dead repos)
gh api repos/<owner>/<repo> --jq '{default_branch, pushed_at, updated_at}'

# Issues / PRs about the same symptom
gh issue list -R <owner>/<repo> --state all --limit 30 --search "<keyword>"
gh issue view <n> -R <owner>/<repo> --json title,body,state,closedAt,comments
gh pr list   -R <owner>/<repo> --state all --limit 20
```

If the most recent push is months old and the issue tracker shows
similar bug reports closed-without-merge, the project is effectively
stale — patch locally and move on. If there's recent activity AND
the file at master no longer matches the local copy, prefer upgrading
the install over patching the snapshot.

## When this matters most

- **Tarball-installed packs without `.git`.** Common with package
  managers that snapshot rather than clone (ComfyUI-Manager,
  pip wheel installs, vendored deps, `npm pack`-style installs).
  Local version is pinned at install time and may be many releases
  behind, so the obvious bug may be obviously fixed upstream.
- **Forks with diverged history.** The bug may already be fixed on
  upstream `main` but never pulled into the fork. Check upstream
  before deciding whether to patch the fork or rebase it.
- **Linter / formatter / generator output checked into the repo.**
  Patching the output is usually wrong — find the generator's bug
  upstream instead.

## When to skip the check

- The bug is in a file the project clearly owns and authored (not
  a vendor / generated / installed path).
- You already know upstream's state from a recent session.
- The local install has explicit downstream patches you'd lose by
  upgrading. (In that case still skim upstream issues for context,
  but don't auto-upgrade.)

## Rationale

Patching a stale snapshot creates two debts: the patch itself, and a
hidden upgrade footgun (your patch silently reverts the next time
something re-fetches the snapshot). Verifying upstream first either
(a) confirms the patch is necessary AND surfaces it for an upstream
PR, or (b) reveals an upgrade is the actual fix.