upstream-sync
Skill1 starsChanged 51 days agoMITView on GitHub
Review canonical-kit commits since this fork's baseline and produce a classified punch-list (must-pull / should-pull / optional / skip). Works for true git forks AND scaffolded copies with no shared history. Cadence 14 days; the canonical kit repo detects itself and exits.
9 other projects use a version of this.
Adopted by
Most recently taken up by
- ilien-dev/quirontheir own version, first seen Nov 8, 2026
- Blueforce-Tech-Inc/BlueCortexCEtheir own version, first seen Nov 8, 2026
- lrstanley/skillstheir own version, first seen Nov 1, 2026
- shruthis4/claude-skillstheir own version, first seen Oct 20, 2026
- halo-box/strix-llama.cpptheir own version, first seen Oct 17, 2026
- bradcstevens/git-loopy-skillstheir own version, first seen Oct 15, 2026
Other versions9 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 9
- microsoft/intelligent-terminal★ 2.2ksame name
- halo-box/strix-llama.cpp★ 259same name
- ilien-dev/quiron★ 65same name
- Blueforce-Tech-Inc/BlueCortexCE★ 4same name
- dris1153/upstream-sync★ 1same name
- lrstanley/skills★ 1same name
- steven-pribilinskiy/tabby-claude-status★ 1same name
- bradcstevens/git-loopy-skills★ 0same name
- shruthis4/claude-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository13 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- add-permissionSkill
- downstream-syncSkill
- merge-prSkill
- neon-postgresSkill
- new-featureSkill
- personalizeSkill
- pre-pushSkill
- process-feedbackSkill
- release-notesSkill
- testSkill
- trivialSkill
The file
We split this skill into the rules it gives an agent
8 rules. 0 are common, 1 is distinctive, and 7 are very specific to this project.
0
Common
Most of the 9 edited versions we read keep these.
1
Distinctive
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 34
Self-detection: Run pnpm kit:check --why. If it reports the canonical kit repository, print upstream-sync: canonical kit repo — skipping …
- Very specific: line 39
State: Read kit.json → sync.upstream.
- Distinctive: line 49
User-supplied SHA: ask what canonical commit the project was scaffolded from.
- Very specific: line 50
Date-based: ask for an approximate scaffold date (err earlier), then gh api "repos/<owner>/<repo>/commits" -X GET -f sha=main -f …
- Very specific: line 61
If lastSyncedSha is missing from upstream/main (rebase/force-push), ask for a new baseline and stop.
- Very specific: line 73
Conflict flagging: if commit.files ∩ kit.json.paths.personalized is non-empty, add conflictLikely with the intersecting paths (additive.
- Very specific: line 83
If N > 0, write the full table to docs/reviews/YYYY-MM-DD-upstream-sync.md.
- Very specific: line 84
Update kit.json.sync.upstream: lastSyncedSha = newest processed (full SHA), lastSyncedDate = today.
“Common” is measured: kept by at least 6 in 10 of the 9 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Upstream Sync
Surface which commits have landed on the canonical kit's main since this fork's last
sync, classify each, and log the result. This skill never applies commits — it
produces a punch-list the fork owner reviews before any git operation.
Two supported repo kinds:
- True git fork — shared history exists; the baseline comes from
git merge-base. - Scaffolded copy (GitHub "Use this template", clone-then-detach) — no shared
history; the GitHub-API path (
MODE=gh) queries the canonical commit list directly and needs only a baseline SHA or date.
"Baseline" = the canonical commit this project last matched. State lives in
kit.json → sync.upstream (baselineSha, lastSyncedSha, lastSyncedDate).
The canonical URL comes from kit.json → kit.canonicalUrl — never hardcode it.
Known Untested Paths (read this first)
Developed inside the canonical repo, where pre-flight short-circuits to N/A. Everything
below is structurally verified but has never run against a live fork↔kit pair: the
gh api commit+files fetches, the git fallback, classification on real subjects, the
punch-list rendering, conflict flagging against paths.personalized, and the
module-removed skip rule. If you are the first fork owner running this, you are the
first real test — report failures as issues on the canonical repo.
Pre-flight (all three; exit cleanly on failure, write nothing)
- Self-detection. Run
pnpm kit:check --why. If it reports the canonical kit repository, printupstream-sync: canonical kit repo — skipping (N/A).and stop. - Tooling.
gh auth statusOK →MODE=gh. Else anupstreamgit remote →MODE=git. Neither → tell the user to installghorgit remote add upstream <kit.canonicalUrl>and stop. - State. Read
kit.json→sync.upstream. EmptybaselineSha→ first-run bootstrap (below). Populated → fetch step.
First-run bootstrap (empty baselineSha)
Resolve a baseline with the first strategy that applies, then write it to
kit.json.sync.upstream (lastSyncedSha = baseline; lastSyncedDate = fork/scaffold
date if known, else today — it seeds the since= window, so prefer the real date):
- Shared history (
MODE=git):git fetch upstream && git merge-base HEAD upstream/main. - User-supplied SHA: ask what canonical commit the project was scaffolded from.
- Date-based: ask for an approximate scaffold date (err earlier), then
gh api "repos/<owner>/<repo>/commits" -X GET -f sha=main -f until=<date>T23:59:59Z --jq '.[0].sha'. - Latest canonical (last resort, with an explicit warning that only future commits
will surface):
gh api repos/<owner>/<repo>/commits/main --jq '.sha'.
Fetch (max 50 commits per run, oldest first)
MODE=gh:gh api "repos/<owner>/<repo>/commits" --paginate -X GET -f sha=main -f since=<lastSyncedDate>for the list, thengh api "repos/<owner>/<repo>/commits/<sha>" --jq '[.files[]?.filename]'per commit for files. Filter outlastSyncedShaitself.MODE=git:git fetch upstream && git log <lastSyncedSha>..upstream/main --format="%H|%ai|%an|%s" --name-only. IflastSyncedShais missing from upstream/main (rebase/force-push), ask for a new baseline and stop.
Classify (first match wins; unmatched → optional)
| Class | Signals |
must-pull | subject/body mentions security/CVE/vulnerability/exploit; OR fix: touching packages/auth/, packages/db/, packages/permissions/, or any apps/*/src/proxy.ts |
should-pull | fix: or "defect"; files under apps/, packages/, or scripts/ |
optional | feat: or chore: deps; new files under apps/ or packages/ |
skip | docs:/style:/ci:/non-deps chore:; or every file falls under kit.json.paths.kitInternal; or every file falls under some kit.json.paths.removed[].paths — render as skip (module removed: <name>) |
Conflict flagging: if commit.files ∩ kit.json.paths.personalized is non-empty,
add conflictLikely with the intersecting paths (additive; classification unchanged).
Punch-list, then log
Render a Markdown table (# | SHA(7) | Date | Subject | Classification | Conflict? | Files)
and show it before writing anything. Empty list → say so. Then:
- Append
YYYY-MM-DD | upstream-sync | N commits reviewed (X must, Y should, Z optional, W skip)(ornothing new since last sync) todocs/reviews/log.md. - If N > 0, write the full table to
docs/reviews/YYYY-MM-DD-upstream-sync.md. - Update
kit.json.sync.upstream:lastSyncedSha= newest processed (full SHA),lastSyncedDate= today. - Any failure before the fetch completed: write NOTHING.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

