vendor-sync
Installation
SKILL.md
Vendor-sync maintenance
The upstream leg of the aggregation repo (CONTEXT.md: vendor sync): bring every source's consolidated copies back to current — matching upstream except the documented patches, with the patch manifest pins recording the true base — and get the pending-update issue closed. The freshness check detects; this skill maintains.
Two invariants (ADR-0002) shape every step: patched files are never overwritten — upstream changes enter a patched file only through a merge that preserves the local patch — and files upstream removed are never deleted without an explicit call.
1. Read the pending-update issue and dry-run
Confirm you are at the aggregation repo root (the git root owning scripts/vendor-sync.mjs); ask the user if it has moved.
- If a pending-update issue is open, read it (
gh issue list --state open --label pending-updateto find it,gh issue view <n>for the body — repo inferred fromgit remote -v). Its pending list is the freshness check's dry-run output; treat it as the plan, not the ground truth. - Run
node scripts/vendor-sync.mjs --dry-run; read the human block and theVENDOR_SYNC_SUMMARY=line.
Classify every pending item:
- added / updated — unpatched files the sync will copy;
- removed upstream (kept local) — unpatched files upstream deleted; the sync never deletes, the keep-or-drop call is the user's (step 3);
- patched, upstream modified — a patched file whose upstream moved since the pinned base: merge it (step 3);
- patched, upstream removed — upstream dropped a patched file: keep-or-drop call (step 3).