---
title: "One system, from design to delivery"
description: "Soul gives TYPO3 community projects a shared visual language for product pages, documentation and interface code — so every hand-off starts from the same decisions."
canonical: index.html
navigation-title: "Soul"
---

<a id="one-system-from-design-to-delivery"></a>

# One system, from design to delivery

Soul gives TYPO3 community projects a shared visual language for product
pages, documentation and interface code — so every hand-off starts from the
same decisions.

![](_images/design-system-workbench.png)

**[Design with Claude](design-system/design-with-claude.md)**

Give Claude the written guidelines, rendered components and finished
screens it needs to design with the same system developers ship.

**[Publish documentation as part of the product](guides-theme/quickstart.md)**

Turn reStructuredText or Markdown into a site whose navigation, search
and content components already belong to the interface around it.

**[Ship the interface without a framework](frontend/quickstart.md)**

Link the class layer directly, then add the custom elements where a
surface needs behaviour. Server-rendered markup remains the contract.

## Built for community projects

Soul serves the extensions, tools, services and documentation sites that
the TYPO3 community builds around the CMS.

Soul covers the surfaces those projects use to present themselves,
explain their work and give an interface. Product pages, guides and
application UI belong to the same system.

Soul does not define the TYPO3 backend, typo3.org or another official
TYPO3 surface. Those products have their own owners and design rules.
A project on this system makes no claim on any of them.

![](_images/community-bookshelf.png)

## The same decisions survive every hand-off

Design systems often stop at a design file or a component library. Soul keeps
the design evidence, the documentation renderer, the class vocabulary and the
elements connected to the same sources.

**Readers keep their bearings**

Product pages, guides and interfaces use the same navigation, type,
controls and states. The next project feels familiar before its
content is familiar.

**Changes keep their source**

A colour changes in a token, a component changes in its element, and
the story regenerates the specimen. The hand-off carries evidence, not
a second interpretation.

## One contract, whichever route a project takes

Three layers, and a surface takes whichever one it needs. Each one rests on
the one under it, so a page that mixes them is still one system.

| Layer | Written as | Reach for it when |
| --- | --- | --- |
| Tokens | `var(--surface-raised)` | the surface needs a value at all |
| Classes | `class="sds-card"` | a server produces the markup |
| Elements | `<sds-note tone="warn">` | the surface has behaviour or state |

[As a standalone frontend](frontend/index.md) says what each layer holds and which of them a given
surface takes.

## Start where the work is

The system does not ask every project to adopt the same toolchain. It asks
each toolchain to speak the same visual language.

**[Explore the rules and their specimens](design-system/index.md)**

See the colour, type, spacing, state and brand decisions beside the
rendered evidence that keeps each rule concrete.

**[Render a project of your own](guides-theme/example.md)**

Start from a complete Guides project, then replace its content. The
shell, search, navigation and publish workflow stay in place.