vendkit

VendKit

Vendor curated slices of files across repos — with provenance, integrity gates, and governed upgrades.

Some files have to be identical in every repo that uses them — agent instructions, CI workflow templates, lint configs, design tokens. Copy-pasted, they drift silently until the one repo nobody updated breaks. VendKit vendors them instead: plain files in your tree, reviewed and greppable.

  • CI status
  • Latest release
  • License: Apache-2.0
  • Go Reference
go install github.com/jameswbaxter/vendkit/cmd/vendkit@latest
view on GitHub →

owned like first-party code · faithful to upstream

The two-lane model

Two lanes keep a vendored copy honest

A publisher repo declares which of its files form a distributable slice. Consumer repos vendor a pinned copy — and two lanes keep that copy honest.

Sync laneWatches the publisher for releases; each upgrade arrives as one reviewed PR. Adds, updates, removals — never silent.
Gate laneRuns on every consumer PR; a hand-edit or delete of a vendored file cannot merge.
Composition invariantThe sync lane's output always passes the gate lane. Upgrades flow; drift can't.

Quickstart

From zero to governed upgrades

One static Go binary, scaffolds embedded. Publisher declares a slice, consumer onboards in one command, PRs start flowing.

01

Publish a slice

In the repo that owns the canonical files, vendkit-export.yml declares what's distributable. Then cut a release — the tag is the release, and it's immutable.

schema_version: 1
slice:
  name: agent-docs
  title: "Agent instructions"
publisher:
  scm: github               # github | azure-repos
  repo: your-org/agent-docs
include:
  - "CLAUDE.md"
  - "agent-rules/**/*.md"
02

Cut a release

Generate the checksum manifest, then tag. Releases are immutable SemVer tags and can carry migration payloads.

vendkit generate              # writes the checksum manifest
vendkit release --bump minor  # tags the next minor, e.g. v1.4.0
03

Onboard a consumer

From a checkout of the publisher at the release you're pinning. One command vendors the slice, writes the manifest, and scaffolds the sync, gate, and watch pipelines. --ci azure-pipelines is a peer, not a port — same machinery, same guarantees. --ci none scaffolds no pipelines; you run the same commands by hand or on cron.

vendkit init --ci github-actions --version v1.4.0
04

The machinery takes over

Curious where you stand? vendkit status — pinned vs latest, drift findings, per slice. vendkit conformance tells you when you're fully wired.

Next publisher release: an upgrade PR appears in your repo. Review, merge, done.
Someone hand-edits a vendored file: the gate fails their PR with the exact finding.

What people vendor with it

One canonical copy, everywhere it counts

Hero use case

AI instructions across a fleet

One canonical set of agent instructions — CLAUDE.md, agent rules, prompt libraries, coding-standard docs, MCP config — vendored into dozens of product repos. Every repo pins a release, hand-edits can't merge, and the next revision of your instructions lands everywhere as a reviewed PR instead of as forty stale copies.

Shared CI/pipeline templates

Golden GitHub Actions and Azure Pipelines workflows, upgraded by PR rather than by hope.

Org-wide config & policy

Linter configs, .editorconfig, security policies, license headers — byte-faithful across the fleet.

Design-system tokens & schemas

Source-of-truth files that must stay byte-identical downstream, reviewed like first-party code.

Why not…

You've tried the alternatives

a package managerDistributes built artifacts into opaque stores.VendKit puts source files in your tree — reviewed, greppable, owned like first-party code, kept faithful to upstream by a checksum manifest.
git submodule / subtreePins whole repositories.Not curated slices; no drift gate, no per-file provenance, no migration lifecycle.
CopybaraContinuous code-motion across a repo boundary.VendKit is release-oriented — immutable SemVer tags, migration payloads — and the consumer controls every change via PR.
Renovate / DependabotUpdate dependency manifests.They don't vendor file trees or carry migrations.

How it holds together

Built so you don't have to take its word for anything

A checksum manifest records exactly what was vendored, from which release and commit; the gate verifies against it.
Releases that reshape content carry migration payloads, and migrations are verified deterministically — same inputs, same verdict.
Conformance checks tell a consumer whether it's correctly wired, against rules the publisher ships with each release.
The composition invariant holds by construction: the sync lane's output always passes the gate lane.
The core engine is vendor-service-free — git and the filesystem only — and the consumer-side integrity path is dependency-free, Go stdlib only.
It's self-hosting: the VendKit repository vendors its own slice and freshness-checks its own manifest in CI.

Where next

Go deeper

Rendered docs for the latest release — browse all docs, or pick a version from the selector on any page. Older releases stay published under their own version paths.

architectureHow the pieces fit together specs/export-declarationPublisher side: declaring a slice specs/onboardingConsumer side: init and the slice config specs/migrationsAuthoring and verifying migrations specs/platform-integrationCI setup: GitHub Actions & Azure Pipelines specs/cliThe full vendkit CLI GLOSSARY.mdPrecise terms CONTRIBUTING.mdHow to contribute