Build a change on its own branch, open a change request, have the team review it in the browser, and land it on main only when it's approved. Live sync keeps working exactly as before, inside a branch, while the branch-to-main boundary becomes the place where review happens. Available on Pro and Enterprise.
Branches: Isolated Workspaces, Same Live Sync
Every project has a protected main branch. Create a branch from the branch switcher in the desktop app's header and you get an isolated line of work: your token edits and component versions live on the branch until you merge them. Everything you know from live collaboration still applies, teammates on the same branch co-edit in real time, tokens merge automatically, component conflicts resolve with a click or an AI rebase.
main ────●────●──────────────────●──── (protected)
\ ↑ merge via change request
feature-buttons ●──●──●
(live-sync with teammates here, like always)Switching branches works like a checkout: the app flushes what you were doing, then re-materialises your tokens and components to exactly the branch's state. Switch back and you resume where you left off.
Change Requests
When the branch is ready, open a change request from the desktop, it proposes merging your branch into main. Spektral computes the diff for you: every token added, changed, or removed (with before/after values), and every component whose version moved.
Review in the browser
Reviewers don't need the desktop app. The web dashboard opens with a plain-English summary of the change, then the full diff, token values with colour swatches, component version changes, with approve, request-changes, and comment actions.
Real attribution
Every edit, change request, review, and merge is attributed to the person who did it, the desktop session knows who you are.
"What's Changed", in Plain English
A raw diff tells you a token moved from #2F7FD6 to #1F5FA6. It doesn't tell you that the primary action colour just got darker across every surface that uses it. So every change request gets an AI-written What's changed panel at the top of its review page, generated from the actual diff, the thing a reviewer reads first.
Overview
A few sentences on what this change request does overall, leading with the intent, and calling out anything risky, like a removed token or a colour change that ripples through many components.
For developers
Affected components and files, version bumps, and renamed or removed tokens that code may still reference, anything that could break a build or a usage.
For designers
The visual and semantic effects: colours, spacing, typography, which surfaces change appearance, and what it means for consistency across the system.
The summary is grounded in the diff, it describes only what actually changed and never invents an effect. It's a derived artifact tied to the exact diff it describes, so if either branch moves while the change request is open, it regenerates automatically rather than going stale. The full token and component diff is right underneath; the summary tells you where to look.
This is what makes browser review work for people who don't read diffs. A product stakeholder or an accessibility reviewer can open a change request, read four sentences, expand the section written for their role, and approve, without anyone having to translate the diff for them first. Self-hosted deployments that haven't configured an upstream model simply don't show the panel; everything else about review works unchanged.
Require Review When You Need It
Governance is a policy, not a rewrite of how you work. It's off by default: small teams keep editing main live, exactly as today, and branches are just an option. Turn require review on for a project and main becomes protected, direct pushes are refused, every change flows through a branch and an approved change request, and merging without an approval is blocked.
require review: off → live-sync straight to main (today's behaviour) require review: on → main is read-only; branch → change request → approve → merge
Merging, with AI on the Conflicts
Merging a change request applies your branch's token changes to main the same conflict-free way live sync merges them, and fast-forwards each component to your branch's version. If main moved while you worked and a component changed on both sides, Spektral doesn't guess: the desktop rebases it with AI, re-applying your change on top of main's current version as one coherent, compiling component, and then completes the merge. The same semantic merge that powers live collaboration, applied at the review boundary.
Getting Started
On Pro or Enterprise, open the branch switcher in the desktop header: create a branch, do your work, and choose "Open change request" when it's ready. Reviewers approve it from the project's Change Requests page in the web dashboard, and you merge from either surface. Cut a release when main is where you want it, see Releases & Distribution.