Design Studio

Design Studio

Unified design skill. One entry point, two engines, one design system file.

DESIGN.md: The Design System File

Create or update DESIGN.md when establishing or changing reusable visual rules. For a review or a small edit that leaves those rules unchanged, use existing design context and deliver the requested review or edit. Read an existing DESIGN.md before design work.

Format

Follow the Google DESIGN.md spec. Structure:

---
version: alpha
name: <Project Name>
colors:
  primary: "#hex"
  secondary: "#hex"
  tertiary: "#hex"
  neutral: "#hex"
typography:
  h1:
    fontFamily: <Font Name>
    fontSize: 48px
    fontWeight: 600
    lineHeight: 1.1
  body-md:
    fontFamily: <Font Name>
    fontSize: 16px
    fontWeight: 400
rounded:
  sm: 4px
  md: 8px
spacing:
  sm: 8px
  md: 16px
  lg: 32px
components:
  button-primary:
    backgroundColor: "{colors.tertiary}"
    textColor: "#fff"
---

## Overview
<Brand personality, audience, emotional intent>

## Colors
<Palette rationale and usage rules>

## Typography
<Type hierarchy and pairing logic>

## Layout
<Grid system, spacing rhythm>

## Elevation & Depth
<Shadows, layers, or flat alternatives>

## Shapes
<Corner radius language>

## Components
<Button, card, input, chip specs with token refs>

## Do's and Don'ts
<Guardrails>

DESIGN.md Lifecycle

Iron rule: Always read existing DESIGN.md before starting work. The design grows from what's already there, not from zero.

Where Process Files Go

DESIGN.md is the only design file that belongs in the project root. Every working file a design session produces goes in docs/design/:

Create the directory if it does not exist. Bare filenames elsewhere in this skill and its sub-skills resolve against docs/design/.

These are session working state, not project assets. A user opening the repo root should see DESIGN.md and their own files, not six intermediate artifacts from one design run.

Route Decision

After reading DESIGN.md (or deciding to create one), route to the right engine:

Ambiguous: Ask one question: "Do you have a film or director in mind as visual reference, or want me to recommend directions?"

Session Flow (this file drives every session)

1. Context — Read DESIGN.md if it exists (lifecycle table above); create one from shared/DESIGN-template.md when the task establishes visual rules.

2. Shared rules — Read shared/anti-slop.md, shared/hard-rules.md, shared/guardrails.md, shared/brand-asset.md, shared/verification.md. They bind every route.

3. Route — Pick the engine from the Route Decision table, then read only that engine's GUIDE and run its workflow:

   • Cinematic → cinematic-ui/GUIDE.md — director + film → cinematic grammar → web structure, in 4 phases: decisions → storyboard → compiled-spec → build. Best for landing pages, brand websites, editorial layouts. References: cinematic-ui/references/ (200 directors, hero archetypes, compositions, color grades).
   • Practical → practical/GUIDE.md — task router → brand protocol → Fallback advisor → Junior Designer. Best for prototypes, presentations, animations, reviews, infographics. References: practical/references/ (40 styles, animation pitfalls, slide decks, critique guide).

   A GUIDE is an execution manual, not a separate skill: it runs inside this session, under the shared rules and the DESIGN.md context already loaded. This file stays in charge of steps 4–6.

4. During design — Record new or changed reusable colors, typography, spacing, and component rules in DESIGN.md.

5. Before delivery — Run shared/verification.md; if visual rules changed, make DESIGN.md reflect the final design.

6. On revisit — Read DESIGN.md first. Expand, don't restart.

Hybrid Tasks

When both engines apply, pick the one matching the primary output. Reference the other's principles where useful. Never mix workflows.

PPTX

Both engines produce PPTX. Cinematic uses PptxGenJS natively. Practical uses HTML deck → PptxGenJS export. Read the PPTX reference from the chosen route.