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

Scenario	Action
No DESIGN.md exists and the task establishes visual rules	Copy shared/DESIGN-template.md to project root, rename to DESIGN.md, fill in during session
DESIGN.md exists, user says "redesign" / "重新設計"	Run shared/redesign-protocol.md first — detect Preserve vs Overhaul, audit the current state — then rewrite DESIGN.md accordingly
DESIGN.md exists, user wants changes	Read first, then expand/modify specific sections. Preserve unchanged tokens.
DESIGN.md exists, new task on same project	Read first, stay consistent with existing tokens unless user says otherwise

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/:

File	Engine	Holds
docs/design/decisions.md	cinematic-ui	Phase 1 — director, film reference, shell-ban list, uniqueness audit
docs/design/storyboard.md	cinematic-ui	Phase 2 — scene-by-scene treatment
docs/design/compiled-spec.md	cinematic-ui	Phase 3 — the sole implementation source (web)
docs/design/slide-spec.md	cinematic-ui	Phase 3 — replaces compiled-spec.md for PPTX
docs/design/product-facts.md	practical	Verified product facts gathered before designing
docs/design/brand-spec.md	shared	Frozen brand asset paths and extracted colors

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:

Signal	Engine	Sub-skill
Director, film, cinema, editorial feel	Cinematic	cinematic-ui/GUIDE.md
High-end static website with visual narrative	Cinematic	cinematic-ui/GUIDE.md
Prototype, mockup, interactive demo	Practical	practical/GUIDE.md
PPT, slides, deck, 簡報	Practical	practical/GUIDE.md
Animation, motion, MP4, GIF	Practical	practical/GUIDE.md
Expert review, critique, scoring	Practical	practical/GUIDE.md
Infographic, data visualization	Practical	practical/GUIDE.md
App/iOS/Android prototype	Practical	practical/GUIDE.md
Quick design variants (3 directions)	Practical	practical/GUIDE.md
Ambiguous / "make something good"	Practical (Fallback advisor)	practical/GUIDE.md
Brand materials with specific brand	Either — use shared brand protocol	Depends on output type
New brand identity from scratch (logo concepting, brand-kit board)	Practical	practical/GUIDE.md → practical/references/brand-identity-board.md
High-conversion LP (explicit CTA / value props / conversion goal)	Hand off	landing-page-studio skill — it reads this skill's shared rules and style library, then runs its own conversion workflow
Web-based deck — live presenting, presenter mode, deploy to a URL (not an editable PPTX)	Hand off	open-slide-studio skill — this skill supplies DESIGN.md and the style direction; it owns the open-slide workspace, authoring hand-off, and delivery

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.