How it works

The change loop, end to end.

Trunk has two modes: a one-time setup, and a change loop that repeats forever. This page walks both. If it feels long, that's the point — the workflow is what you're buying.

1

Onboarding · nine focused steps.

You land in Trunk after signup. Onboarding walks you through nine gated screens — most auto-detected from the connected repo. Nothing takes more than a minute per step.

  1. Product name. Name + subdomain.
  2. Lifecycle preset. Product-team · Startup · Enterprise. Pick one, edit later.
  3. Customize phases (optional). Reorder, drop, or add.
  4. Connect repo. GitHub · GitLab · Bitbucket. Skippable.
  5. Invite team. Auto-detected from repo collaborators. Roles map to gates.
  6. Device targets. Auto-detected from CSS breakpoints.
  7. Import source. Auto-detected — usually your live URL.
  8. Starting mode. Auto-decided: Capture · Blank · Import from Figma.
  9. Launch. Full summary. Create product. Open workspace.

Onboarding runs once per product. After launch, you never see it again for that product.

2

Foundations · in a strict order.

Every product has three foundational surfaces you build in order. Styles bind tokens. Components consume tokens. Pages compose components. Journey derives from pages.

1
Styles

Colors, spacing, type, radius, motion, icons, illustrations.

2
Components

Each component × every variant (default, hover, focus, disabled, loading, error, empty, populated).

3
Pages

Compositions of components + tokens. Real routes. Real links.

4
Journey

Auto-crawled. Health: shipped / in-flight / thin / missing / broken.

When foundations are ready, you publish main. From now on, every change is a delta off main.

3

Every change is a delta.

A delta is an epic-sized change on the running product. It owns its whole lifecycle — the motivating signal, the PRD, the design, the approval, the typed code slices, the PRs, the deploy, the post-ship metric. From that one object, Trunk derives the design view, the ticket board, the journey graph, the review chain.

Deltas have a type — Epic, Bug, Hotfix, Experiment (defaults), plus custom types your team adds. A type is a preset over the phase spine — Bugs skip Document + Approve, Hotfixes are Code + Deploy only, Experiments require A/B setup.

4

Six phases. One object.

Each phase has an owner, an artifact, and a gate. Not one big review chain — six focused ones.

1 · Analyze
Pin a motivating signal. Every delta starts with data.
Gate PM
2 · Document
PRD on the delta. Comments anchor to sections.
Gate PM · TL
3 · Design
Styles · Components · Pages · Journey · Assets.
Gate Des · PM
4 · Approve
Cost + team split before Code. EM signs on scope, not code.
Gate EM
5 · Code
Typed slices become real PRs. CI runs. Review happens.
Gate TL
6 · Deploy
Preview → staging → prod. Validating signal wires back to Phase 1.
Gate On-call

Order is configurable per product. Deltas can start in any phase — skip Analyze if the data's already clear, skip Document for hotfixes.

5

Gates & roles.

A gate is the role(s) that must sign a phase before the delta advances. Roles map to phases at onboarding — PM signs Analyze, Designer signs Design, Tech Lead signs Code, and so on. Every signature is timestamped, tied to SSO identity, and appended to the audit log.

Enterprise plan supports dual-signer gates — two roles must both sign before the phase unlocks.

6

Slices are typed sub-tasks under Code.

When a delta reaches Phase 5, it breaks into slices. Each slice is a typed sub-task — Frontend, Backend, CI/CD, Misc, Backlog. One slice = one real PR against your remote. When the PR merges, the slice is done. When all slices are done, Code unlocks Deploy.

Slice types are configurable. Add Docs, Localise, whatever fits your team.

7

Conflicts are visual.

When two deltas touch the same primitive, Trunk shows a 3-way visual diff — base, yours, theirs — with an auto-merged result you can tune. Same idea as Git, at the design layer. No text merge required.

Because comments anchor to primitives (not pixels), restructuring HTML doesn't orphan feedback.

8

Principles.

1
The running app is the master.
No proprietary file format. Trunk's output is real HTML/CSS/SVG that ships.
2
Every change is a delta.
No parallel ticket, no separate review deck. One object.
3
Comments anchor to primitives.
Restructuring HTML doesn't orphan feedback.
4
Journeys are derived.
The graph is a projection of real routes and links.
5
Conflict resolution is a design activity.
When branches collide, the resolver is a visual diff of primitives — not a text merge.
FAQ

Common questions.

Does Trunk replace my repo?

No. Trunk raises real PRs against your GitHub / GitLab / Bitbucket repo. Your code home stays where it is.

What if I already have a design system in Figma?

Import once at onboarding. Trunk pulls frames as pages, components as components, styles as tokens. After that Trunk is the source of truth.

What frameworks does Trunk support?

Anything that consumes HTML/CSS — React, Vue, Svelte, plain HTML, SSG. Trunk raises PRs as real diffs on your repo; your framework's build owns the compile step.

Do I have to use all six phases?

No — startups skip Document + Approve. Delta types further skip phases (Hotfixes are Code + Deploy only). Fully configurable.

Ready to walk it?

The Norrland example is a full workspace with real deltas mid-flight.