lacquer

A Go CLI plus a set of profile templates that standardize how Claude Code works across every project in ~/Developer. The lacquer renders shared content — CLAUDE.md rules, skills, commands, CI workflows, git hooks, tool configs — into each project and tracks how far each project has drifted, so a lesson pinned once propagates everywhere instead of being copy-pasted and left to rot.

A project opts in per component (a subdirectory) via a .lacquer.toml manifest. Each component declares one or more profiles; core applies to every project regardless.

Commands

Command	Does
lacquer init	Detect components, write a .lacquer.toml stub (and a docs/brief.md stub).
lacquer onboard --org O [--no-repo]	init, then create a private GitHub repo under O when the repo has no origin.
lacquer sync [--force]	Render core + per-profile content into the project (managed regions + whole-file assets).
lacquer skills	Install [project].skills entries via the skills CLI.
lacquer plugins	Install core/bootstrap/plugins.toml (machine-level Claude Code plugins) via claude plugin.
lacquer status	Show each region's stamped version vs the lacquer's latest.
lacquer audit	Classify project drift; exit 3 if a sync would clobber a local change (usable as a CI gate).
lacquer version	Print the lacquer version.

lacquer --help prints usage.

LACQUER_ROOT

Every command that reads shipped content (sync, status, audit, version) resolves the lacquer checkout from the LACQUER_ROOT env var (default .):

LACQUER_ROOT=~/Developer/lacquer lacquer sync

If LACQUER_ROOT is unset and the current directory isn't a lacquer checkout (no VERSION file / profiles/ dir), those commands fail with an actionable message rather than an opaque missing-file error.

Profiles that ship

• core — universal rules/skills/commands applied to every project.
• ios — Swift/Xcode: SwiftLint/SwiftFormat, CI, TestFlight, Skills; git hooks via pre-commit.
• web — TypeScript + Biome + Vitest; CI + git hooks via lefthook.
• supabase — Deno Edge Functions + Postgres/RLS; CI + git hooks via lefthook.

A component detected as an unshipped stack (e.g. Rust/Go) is recorded in the manifest with an empty profile list and a notice — it doesn't break sync.

Updating a project

lacquer audit    # see what drifted; exit 3 means sync would overwrite a local edit
lacquer sync     # apply; refuses to clobber a locally-modified managed unit
lacquer sync --force   # adopt the lacquer version over a local change

Sync writes a .lacquer.lock baseline so audit can tell "the project edited this" from "the lacquer moved on" and only blocks on the former.

Third-party skills

lacquer sync distributes this repo's own skills (core/skills/, profiles/*/skills/) — that's a solved problem, versioned and drift-audited. Third-party skills are a different concern: one global install shared across every project, kept up to date by vercel-labs/skills, a real package manager for agent skills — not something lacquer reimplements. The packages this fleet actually pulls in (with source links, and which is suggested from which Swift import) are cataloged in Skills reference — currently dpearson2699/swift-ios-skills (Apple framework references) and HunterHillegas/mac-assed-mac-app-skill (AppKit/macOS conventions).

[project].skills in .lacquer.toml declares which packages this project needs, mixing lacquer's own skills and third-party ones uniformly:

skills = [
  "patrickserrano/lacquer@security-review",
  "dpearson2699/swift-ios-skills@healthkit",
  "dpearson2699/swift-ios-skills@storekit",
]

lacquer init seeds this list automatically by scanning the project's actual Swift imports (see internal/skillsuggest) — review and trim before running lacquer skills, which installs exactly what's declared, project-scoped, via npx skills add <source> -s <name> -p -y. Idempotent: re-running only adds what's missing. It also flags any installed skill no longer declared in the manifest (informational — nothing is auto-removed).

This is deliberately a separate command from sync: sync stays fully offline and deterministic (its whole test suite depends on that), while skills is the one command that reaches the network.

Plugins (machine-level bootstrap)

Claude Code plugins install once at user scope and are shared across every project on a machine — a different shape of problem than [project].skills, which is per-project. core/bootstrap/plugins.toml lists the marketplaces and six plugins this fleet relies on — superpowers, codex (adversarial review via a real Codex subprocess), context7, figma, security-guidance, and telemetrydeck-analytics — cataloged with source links in Plugins catalog. lacquer plugins applies the manifest via claude plugin marketplace add / claude plugin install, both confirmed idempotent (an already-configured marketplace or already-installed plugin is a clean no-op). Only plugins actually enabled on the reference machine are listed — one installed-but-disabled there is a deliberate choice, not silently re-enabled on a fresh machine.

lacquer plugins

This is how a fresh machine picks up the same plugin set an existing one already has, closing the same "bootstrap a machine with none of this preconfigured" gap that [project].skills closes for per-project skills.

Installing

go install github.com/patrickserrano/lacquer/cmd/lacquer@latest

Or build from a checkout:

go build ./cmd/lacquer

Tagged releases (with prebuilt darwin/amd64 and darwin/arm64 binaries and changelogs) are published automatically on GitHub Releases whenever VERSION changes on main.

Docs

docs/plans/ holds the design and build plans. The design doc (docs/plans/2026-06-15-lacquer-design.md) carries an "Implementation status" note distinguishing what's built from what's still aspirational.

About

Built by Patrick Serrano, an iOS engineer building apps under PixelFox Studio. lacquer is the internal tooling that keeps engineering practice consistent across the whole fleet.