There is no server, and no separate database — git is the database
This surprises people, so it’s worth stating plainly: Synclair has no backend and no database of its own. Every fact it shows — a token, a component’s docs, a knowledge digest, the system map — is a plain file committed to your repo.The rule of thumb: if a change deserves a commit message, it’s a file in git.
Tokens, the component registry, docs, knowledge digests — all versioned files. Sync
between teammates is just
git pull / git push.- It’s what keeps humans and agents reading the same bytes. One source, two renderings (a page and machine context) only holds if there’s a single canonical copy — and a file in git is that copy.
- Changes get history and review. A token change is a diff you can review, not a silent row update.
- Agents already read files. No API to teach them; the knowledge is the repo.
It piggybacks on the AI tools you already use
Synclair doesn’t ship its own AI. Its “intelligence” is packaged know-how that your existing agent (Claude Code, Cursor, Copilot, Codex, Gemini, …) loads on demand. Two mechanisms make this cheap:1
Skills — progressive disclosure
A skill is a plain-markdown guide at
.claude/skills/<name>/SKILL.md with a
one-line description of when it applies. Only that one line sits in context
(cheap); the full body loads only when a task matches; the files it points to
load only when the body needs them. A 5,000-line knowledge base costs ~15 words
until it’s relevant.2
Digger agents — context isolation
A digger is a narrow sub-agent with its own context window. It reads the whole
40-page PRD (or the host codebase, or a Figma file), distills it, and returns
one tight paragraph. The expensive read happens in a context you throw away —
only the answer comes back to the main thread.
SKILL.md when a task matches its
when. That’s why the router file is AGENTS.md — every agent reads the same map.
See the full capability set
What skills and agents ship, and how any agent invokes them.
It rides on GitHub for the “live” parts
Because git is the database, GitHub (or any git host) does double duty:- Repo activity — recent commits and diffs surface in the hub. Git is the shared log; Synclair just reads it.
- Foundation freshness — an opt-in “call home” check compares your clone against the upstream foundation via the GitHub compare API, so you can see if you’re behind before deciding to pull.
- CI as the enforcement gate — the same
verify-uichecks that run locally run on every push/PR, so the design-system rules aren’t advisory.
Rules ship as machine checks, not just prose
A rule written only as prose (“no raw hex”, “register components on creation”) works only while every agent remembers it. Synclair’s convention is: whenever a rule can be machine-checked, it ships with its check.
One command —
npm run verify-ui — runs them, and CI runs the same. Crucially, the
error messages are fix instructions (“use a semantic token from tokens.ts”),
so when an agent trips a guardrail, the message is a perfectly-timed re-prompt.
The flywheel
The payoff compounds. The first time an agent digs into an area (reads the PRD, surveys the host code), it’s expensive. But diggers write the durable part back into a skill — so the next agent loads it as a cheap one-line description instead of re-reading the source. Over time the distilled brain converges on “what a builder routinely needs,” and raw sources get consulted only for genuinely new detail.Next: install it
Two topologies — embed it in one repo, or watch it from a separate one.