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-update to find it, gh issue view <n> for the body — repo inferred from git 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 the VENDOR_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).
Installs
1
First Seen
Sep 26, 2026