# As a parallel related question: Assess how penpot (self hosted at penpot.chem.dev) can optimally complement this CMS/frontend development/orchestration architecture
Yes—Penpot can complement this architecture **very well** if you position it as the self-hosted design system and collaboration layer, not as the primary coding/orchestration engine. Its biggest value is that it speaks web-native concepts directly—CSS, Grid, Flexbox, SVG, tokens, JSON, API, webhooks, and MCP—so it can become the canonical design source that feeds Claude Code, EmDash themes, and your frontend component pipeline with less translation loss than a traditional handoff workflow.[^1][^2][^3][^4][^5]
## Best role for Penpot
Penpot is strongest as the **design source of truth** for tokens, layouts, reusable UI patterns, annotations, and inspectable implementation details. In this architecture, Stitch is better treated as the fast exploratory or generative design assistant, while Penpot becomes the durable system where approved designs are normalized, documented, versioned, inspected, and handed to implementation agents.[^2][^3][^6][^7][^8][^1]
That means the practical division is:
- Stitch: generate initial directions, high-end visual exploration, concept variants, and rapid layout ideation.[^6][^7][^8]
- Penpot: refine, normalize, tokenize, annotate, inspect, and publish the approved system for engineering consumption.[^3][^1][^2]
- Claude Code: convert Penpot-approved specs and exported assets into production React/Astro/Next.js components and CMS themes.[^4][^1]
## Why Penpot fits your stack
Penpot aligns unusually well with your frontend/CMS architecture because it exposes real CSS, Grid, Flexbox, HTML, SVG, and semantic token names in its inspect flow, which reduces ambiguity for both human developers and coding agents. It also supports design tokens exported as JSON in the W3C DTCG format, which can be transformed into CSS variables and integrated into CI/CD, making it a natural bridge between design decisions and deployable code.[^1][^2][^3]
That is especially valuable for your target stack because:
- Claude Code benefits from explicit, structured artifacts rather than screenshots and vague intent.[^4][^1]
- EmDash themes are Astro projects with components and styles that map cleanly from tokenized design systems.[^5]
- Next.js/Tailwind/component-library work benefits from semantic tokens and inspectable layout rules instead of pixel-guessing.[^2][^1]
## Best architecture pattern
The best operating model is to make Penpot your persistent **design ops layer** between generative design tools and code generation agents. In other words, do not let agents code directly from rough visual prompts when a design has already matured; instead, require them to consume Penpot tokens, approved frames, annotations, and export bundles as implementation inputs.[^3][^1][^2][^4]
A strong architecture for `penpot.chem.dev` looks like this:
| Layer | Recommended role | Why |
| :-- | :-- | :-- |
| Visual ideation | Google Stitch | Fast generation of polished screens and variants.[^6][^7][^8] |
| Design system registry | Penpot self-hosted | Durable components, token sets, inspect, annotations, self-hosting, open formats.[^1][^9][^2] |
| Coding agent | Claude Code | Turns approved design artifacts into production code with project-aware rules.[^4] |
| CMS theming/content UI | EmDash + Astro | Secure CMS themes and content surfaces tied to shared tokens.[^5] |
| App frontend | Next.js + React | Best target for rich interactive components and design-system implementation.[^10][^4] |
| Multi-agent supervisor | LangGraph or internal orchestrator | Controls routing, approvals, and validation between design/code/content agents.[^11][^12] |
In this setup, Penpot becomes the place where your approved primitives live: colors, typography, spacing, grids, reusable blocks, interaction notes, and implementation status labels. That makes it ideal as a checkpoint between experimentation and productionization.[^1][^2]
## MCP and agentic value
Penpot has a meaningful agentic upside because it now has an MCP story rather than being just a passive design file repository. Penpot’s official MCP server is designed so LLMs can retrieve, modify, and create design data, with a dedicated Penpot plugin connecting over WebSocket and MCP endpoints exposed over HTTP/SSE for clients like Claude Code.[^4][^1]
That matters because it enables workflows like:
- Claude Code pulling structured design context directly from Penpot rather than relying on screenshots or copy-pasted specs.[^1][^4]
- Agents creating or updating Penpot design elements through the MCP server and plugin bridge.[^4]
- Design verification agents checking whether implemented components still match token and layout intent preserved in Penpot artifacts.[^2][^1]
For your architecture, this means Penpot can participate in the orchestration graph as an active tool surface, not just a design archive. The most useful tasks to expose agentically are read-heavy first: fetch tokens, export assets, inspect layout rules, get annotations, list component variants, and retrieve approved frame metadata. Write access should be more tightly gated because uncontrolled design mutation by agents can create drift and review pain.[^11][^2][^1][^4]
## Best use cases
Penpot is especially strong for the following high-value use cases in your stack:
- Shared design token management across EmDash themes and Next.js app shells, especially for dark mode, white-labeling, or client-specific branding.[^2][^1]
- Developer handoff replacement, because engineers can inspect CSS/Flex/Grid directly and export SVG/HTML/CSS instead of interpreting static mocks.[^3][^1]
- Component-library governance, where Penpot components mirror Storybook or internal React primitives and serve as the visual contract before implementation.[^13][^1]
- Self-hosted, security-conscious workflows, where you want design infrastructure inside your own environment rather than locked into a closed vendor platform.[^9][^14][^1]
For agency or SaaS operations, the token-set and theme support is particularly useful because Penpot’s token workflow can support brand swaps, seasonal campaigns, or white-label systems without changing the underlying implementation architecture. That pairs well with your CMS/frontend architecture where the same component primitives may power multiple client properties with different branding layers.[^5][^1][^2]
## Recommended implementation model
The optimal implementation model is to use Penpot as the canonical design system registry and implementation contract source. A clean workflow would be:[^1][^2]
1. Generate initial screens in Stitch for speed and visual range.[^7][^8][^6]
2. Rebuild or normalize approved screens/components in Penpot with proper naming, tokenization, annotations, and status labels.[^2][^1]
3. Export tokens in DTCG JSON and transform them into CSS variables or Tailwind/theme artifacts in CI.[^1][^2]
4. Feed Penpot outputs plus project rules into Claude Code for production implementation in Next.js, Astro, or shared component packages.[^4][^1]
5. Use verifier agents to compare implemented components against tokens, spacing, accessibility, and approved states.[^12][^11]
For your stack specifically, I would recommend storing these artifacts in Git:
- `/design/tokens/penpot-tokens.json` from Penpot exports.[^2]
- `/design/specs/*.md` for annotations and component notes derived from Penpot + Stitch.[^1]
- `/packages/ui` for React primitives and shared tokens.
- `/apps/web` for Next.js app surfaces.
- `/apps/cms-theme` or equivalent for EmDash/Astro themes.[^5]
This keeps Penpot connected to code as a governed upstream dependency rather than a separate design silo.[^2][^1]
## Limits and cautions
Penpot should not replace Claude Code, LangGraph, or your code orchestration layer, because its value is design-system alignment and inspectability rather than end-to-end software execution. It also should not replace Stitch for high-speed AI ideation if you want rapid concept generation, since Penpot’s advantage is durable collaboration and standards alignment more than frontier visual generation.[^8][^6][^7][^4][^1]
The biggest practical caution is governance: if both Stitch and Penpot are treated as editable truth sources, you can create design drift quickly. The cleanest rule is:[^6][^1]
- Stitch creates proposals.
- Penpot stores approved design truth.
- Claude Code implements.
- Storybook and visual QA verify.[^4][^1]
That operating model gives Penpot a very strong place in your architecture—especially because you already self-host it and can integrate it into your own orchestration boundary at `penpot.chem.dev`.[^14][^9][^1]
Would you like me to turn this into a concrete target architecture for `penpot.chem.dev` with service boundaries, data flows, and agent roles?
[^15][^16][^17][^18][^19][^20][^21][^22][^23]
⁂
[^1]: https://penpot.app/blog/how-penpot-eliminates-developer-handoffs/
[^2]: https://penpot.app/blog/the-developers-guide-to-design-tokens-and-css-variables/
[^3]: https://penpot.app/code
[^4]: Screenshot_20260406-005125.jpg
[^5]: https://blog.cloudflare.com/emdash-wordpress/
[^6]: https://pasqualepillitteri.it/en/news/647/google-stitch-mcp-export-claude-code-design-to-code
[^7]: https://dev.classmethod.jp/en/articles/new-stitch-ai-design/
[^8]: https://codelabs.developers.google.com/design-to-code-with-antigravity-stitch
[^9]: https://penpot.app
[^10]: https://vercel.com/blog/introducing-the-new-v0
[^11]: https://www.langchain.com/langgraph
[^12]: https://launchdarkly.com/docs/tutorials/agents-langgraph
[^13]: https://community.penpot.app/t/self-hosted-open-source-design-system/10168
[^14]: https://github.com/penpot/penpot
[^15]: https://www.temperstack.com/software/penpot/
[^16]: https://community.penpot.app/t/what-s-your-developer-handoff-workflow/115
[^17]: https://www.youtube.com/watch?v=YpNqB0fQGpY
[^18]: https://community.penpot.app/t/penpot-mcp-container/10095
[^19]: https://github.com/penpot/penpot-mcp
[^20]: https://www.xda-developers.com/self-hosted-figma-alternative-is-great-but-not-for-everyone-penpot/
[^21]: https://penpot.app/penpot-mcp-server
[^22]: https://community.penpot.app/t/penpot-for-frontend-development/10257
[^23]: https://community.penpot.app/t/improvements-of-inspect-mode/3781