# Apply Design System Tokens at Project Level vs. Generation Prompts in Stitch

> Apply design system tokens at the project level in Stitch for visual consistency reduce LLM costs and simplify prompts. Learn why this approach beats generation prompts.

- Repository: [Google Labs Code/stitch-skills](https://github.com/google-labs-code/stitch-skills)
- Tags: best-practices
- Published: 2026-07-16

---

**Applying design system tokens at the project level rather than embedding them directly in generation prompts creates a single source of truth that ensures visual consistency across all screens while reducing LLM token costs and prompt complexity.**

In the `google-labs-code/stitch-skills` repository, the Stitch framework decouples visual styling from generation logic by centralizing design tokens—colors, typography, spacing, and component styles—at the project scope. This architectural decision, implemented across skills like `manage-design-system` and `generate-design`, prevents visual drift and eliminates the need to repeat design specifications in every generation prompt.

## Architectural Advantages of Project-Level Design Tokens

Centralizing design system tokens at the project level delivers specific technical benefits that embedding tokens in prompts cannot match.

### Consistency Across Screens

When a design system is attached to a project, every screen automatically inherits the same visual rules through the `apply_design_system` binding. This prevents accidental drift where different prompts specify slightly different shades or font families. According to the implementation in [`/plugins/stitch-design/skills/manage-design-system/SKILL.md`](https://github.com/google-labs-code/stitch-skills/blob/main//plugins/stitch-design/skills/manage-design-system/SKILL.md), the system applies these tokens globally, ensuring that generated components adhere to a unified visual language without manual synchronization across individual prompts.

### Single Source of Truth

Centralizing tokens means a single edit updates the entire UI. Changing a primary color in the design system instantly propagates to all generated components without editing each prompt. The `generate-design` skill explicitly checks for an existing design system before proceeding, as documented in [`/plugins/stitch-design/skills/generate-design/SKILL.md`](https://github.com/google-labs-code/stitch-skills/blob/main//plugins/stitch-design/skills/generate-design/SKILL.md), enforcing the "design-system-as-code" philosophy where visual definitions live independently from generation logic.

### Reduced Prompt Bloat and Latency

Generation prompts should focus on *what* to create, not *how* it should look. Keeping prompts concise improves LLM interpretability and reduces token usage, which lowers both cost and latency. The `enhance-prompt` skill, detailed in [`/plugins/stitch-utilities/skills/enhance-prompt/SKILL.md`](https://github.com/google-labs-code/stitch-skills/blob/main//plugins/stitch-utilities/skills/enhance-prompt/SKILL.md), injects design-system context only when needed, maintaining a clean separation between intent and styling.

### Scalable Multi-Page Validation

Large projects may contain dozens of screens. Embedding tokens in each prompt would be error-prone and difficult to audit. Project-level tokens allow the `stitch-loop` skill to verify that the design system block is present in the **baton**—the overall prompt payload—across all generation cycles. This validation logic, found in [`/plugins/stitch-utilities/skills/stitch-loop/SKILL.md`](https://github.com/google-labs-code/stitch-skills/blob/main//plugins/stitch-utilities/skills/stitch-loop/SKILL.md), ensures that no screen generates without the proper design context in multi-page workflows.

### Designer-Developer Collaboration

Designers and developers can edit the [`DESIGN.md`](https://github.com/google-labs-code/stitch-skills/blob/main/DESIGN.md) file—the canonical design system definition—without touching generation logic. The `design-md` skill extracts this file and synthesizes a semantic design system for downstream usage, as described in [`/plugins/stitch-utilities/skills/design-md/SKILL.md`](https://github.com/google-labs-code/stitch-skills/blob/main//plugins/stitch-utilities/skills/design-md/SKILL.md). This separation allows design teams to update tokens using familiar markdown syntax while development teams focus on generation prompts.

## Implementation: Binding Tokens to Projects

The Stitch framework implements project-level design systems through a specific pipeline that moves from definition to application.

First, the `design-md` skill parses a markdown-based design definition into structured tokens. Then, the `manage-design-system` skill binds these tokens to the project via `apply_design_system`. Finally, the `enhance-prompt` skill automatically injects these tokens into the generation context when the `generate-design` skill runs, eliminating the need for manual token specification in each prompt.

## Practical Code Examples

The following commands demonstrate the workflow from design definition to generation, leveraging the project-level token architecture.

### Create a Design System from DESIGN.md

```bash
stitch design-md \
  --project MyProject \
  --source .stitch/DESIGN.md

```

*The `design-md` skill reads the markdown file, builds a structured token set, and registers it in Stitch.*

### Apply the Design System to All Screens

```bash
stitch apply-design-system \
  --project MyProject \
  --design-system MyDesignSystem

```

*This binds the token set to every screen in the project, so subsequent generations automatically inherit the styles without explicit token references in prompts.*

### Generate Components with High-Level Prompts

```bash
stitch generate-design \
  --project MyProject \
  --prompt "Create a card component with a title and a description."

```

*Because the project already has a design system attached via `apply_design_system`, the LLM does not need explicit color or font tokens in the prompt. The `generate-design` skill automatically pulls the correct tokens from the project context.*

### Override Tokens for Single-Screen Exceptions

```bash
stitch generate-design \
  --project MyProject \
  --prompt "Create a button with a secondary color." \
  --override-tokens "colorSecondary:#ff6600"

```

*Overrides are optional and scoped to the specific generation call, leaving the project-wide design system untouched while allowing one-off exceptions.*

## Summary

- **Project-level tokens** create a single source of truth that propagates changes instantly across all screens, eliminating the need to edit individual prompts.
- **Separation of concerns** allows the `enhance-prompt` skill to inject design context automatically, reducing token usage and improving LLM performance.
- **The `baton`**—Stitch's overall prompt payload—carries design system references that the `stitch-loop` skill validates to ensure consistency in multi-page projects.
- **Collaboration** improves when designers edit [`DESIGN.md`](https://github.com/google-labs-code/stitch-skills/blob/main/DESIGN.md) files while developers work with clean, intent-focused prompts in `generate-design`.

## Frequently Asked Questions

### What happens if I need different tokens for a single screen?

You can use the `--override-tokens` flag in the `generate-design` command to specify exceptions for individual screens. This scoped override applies only to that generation call while preserving the project-level design system for all other screens.

### How does Stitch know when to inject design system context?

The `enhance-prompt` skill automatically detects when a project has an applied design system and injects the relevant tokens into the generation context. As implemented in [`/plugins/stitch-utilities/skills/enhance-prompt/SKILL.md`](https://github.com/google-labs-code/stitch-skills/blob/main//plugins/stitch-utilities/skills/enhance-prompt/SKILL.md), this injection happens only when needed, keeping prompts clean and focused on structural intent.

### What is the baton in Stitch skills?

The **baton** is the overall prompt payload that carries state and context across skills in a Stitch workflow. According to the `stitch-loop` skill in [`/plugins/stitch-utilities/skills/stitch-loop/SKILL.md`](https://github.com/google-labs-code/stitch-skills/blob/main//plugins/stitch-utilities/skills/stitch-loop/SKILL.md), the baton must contain the design system block for validation purposes, ensuring that multi-page projects maintain consistent styling across all generation cycles.

### How do I migrate from prompt-embedded tokens to a project-level system?

First, extract your existing design definitions into a [`DESIGN.md`](https://github.com/google-labs-code/stitch-skills/blob/main/DESIGN.md) file and run the `design-md` skill to register them. Then apply the system to your project using `apply-design-system`. Finally, remove the explicit token references from your `generate-design` prompts; the system will automatically pull the correct values from the project context.