Design with Claude
Give Claude the written guidelines, rendered components and finished screens it needs to design with the same system developers ship.
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.
Start with measured screens and rendered components. Publish from reStructuredText or Markdown. Ship plain classes or web components. Every route resolves to the same tokens and the same markup contract.
Give Claude the written guidelines, rendered components and finished screens it needs to design with the same system developers ship.
Give Claude the written guidelines, rendered components and finished screens it needs to design with the same system developers ship.
Turn reStructuredText or Markdown into a site whose navigation, search and content components already belong to the interface around it.
Turn reStructuredText or Markdown into a site whose navigation, search and content components already belong to the interface around it.
Link the class layer directly, then add the custom elements where a surface needs behaviour. Server-rendered markup remains the contract.
Link the class layer directly, then add the custom elements where a surface needs behaviour. Server-rendered markup remains the contract.
Give Claude the written guidelines, rendered components and finished screens it needs to design with the same system developers ship.
Give Claude the written guidelines, rendered components and finished screens it needs to design with the same system developers ship.
Turn reStructuredText or Markdown into a site whose navigation, search and content components already belong to the interface around it.
Turn reStructuredText or Markdown into a site whose navigation, search and content components already belong to the interface around it.
Link the class layer directly, then add the custom elements where a surface needs behaviour. Server-rendered markup remains the contract.
Link the class layer directly, then add the custom elements where a surface needs behaviour. Server-rendered markup remains the contract.
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 provide 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, and adopting this system is not a claim on any of them.
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.
Product pages, guides and working interfaces use the same navigation, type, controls and states. The next project feels familiar before its content is familiar.
Product pages, guides and working interfaces use the same navigation, type, controls and states. The next project feels familiar before its content is familiar.
A colour changes in a token, a component changes in its element, and a specimen is regenerated from the story. The hand-off carries evidence instead of a second interpretation.
A colour changes in a token, a component changes in its element, and a specimen is regenerated from the story. The hand-off carries evidence instead of a second interpretation.
Product pages, guides and working interfaces use the same navigation, type, controls and states. The next project feels familiar before its content is familiar.
Product pages, guides and working interfaces use the same navigation, type, controls and states. The next project feels familiar before its content is familiar.
A colour changes in a token, a component changes in its element, and a specimen is regenerated from the story. The hand-off carries evidence instead of a second interpretation.
A colour changes in a token, a component changes in its element, and a specimen is regenerated from the story. The hand-off carries evidence instead of a second interpretation.
Three layers, and a surface reaches for whichever one it needs. Each is written in terms of the one under it, so a page that mixes them is still one system.
var(--surface-raised)class="sds-card"<sds-note tone="warn">| Layer | Written as | Reach for it when |
|---|---|---|
| Tokens | var(--surface-raised) |
a value is needed 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 says what each layer holds and which of them a given surface should be written in.
The system does not ask every project to adopt the same toolchain. It asks each toolchain to speak the same visual language.
See the colour, type, spacing, state and brand decisions beside the rendered evidence that keeps each rule concrete.
See the colour, type, spacing, state and brand decisions beside the rendered evidence that keeps each rule concrete.
Start from a complete Guides project, then replace its content while the shell, search, navigation and publishing workflow stay in place.
Start from a complete Guides project, then replace its content while the shell, search, navigation and publishing workflow stay in place.
See the colour, type, spacing, state and brand decisions beside the rendered evidence that keeps each rule concrete.
See the colour, type, spacing, state and brand decisions beside the rendered evidence that keeps each rule concrete.
Start from a complete Guides project, then replace its content while the shell, search, navigation and publishing workflow stay in place.
Start from a complete Guides project, then replace its content while the shell, search, navigation and publishing workflow stay in place.