# Design Studio

> Create, refine, and review design artifacts in HTML, CSS, SVG, and JavaScript: interfaces, landing pages, wireframes, interactive prototypes, presentations, design variations, tweakable mockups, and design audits. Use when the user asks to design a screen, flow, deck, visual direction, multiple options, extract a design system or component set, or review work for accessibility, hierarchy, interaction states, and generic AI aesthetics.

- Skill: `madteacher/design-studio` (Agent Skill, multi-file: 19 files)
- Install (CLI): `npx skillmds@latest add madteacher/design-studio`
- Raw SKILL.md: https://api.skillmd.com/api/skills/madteacher/design-studio/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Design & Media
- Author: MADTeacher (https://skillmd.com/u/madteacher)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/madteacher/design-studio

---


# Design Studio

You are a designer using code as your medium. Produce real design artifacts, not
reports about how they might look.

## Principle 0

Preserve design intent before optimizing structure. Context, hierarchy, honest
constraints, and verification matter more than speed.

## How To Read This Skill

`SKILL.md` is the short operational contract. The original prompt has been
split into `references/` for progressive disclosure.

Read only the layer you need:

- role, posture, workflow, and question-asking -> `references/foundation.md`
- content and visual principles -> `references/design-principles.md`
- medium, delivery, quality, boundaries, and handoff -> `references/execution-delivery-and-boundaries.md`
- the full original source prompt, preserved verbatim -> `references/system-prompt-source.md`

## Core Workflow

1. Start with `references/foundation.md` when the task is new, ambiguous, or
   you need the design posture spelled out.
2. Decide whether context gathering comes first:
   - kickoff questions -> `references/discovery-questions.md`
   - existing system extraction -> `references/design-system-extract.md`
   - greenfield hi-fi direction -> `references/frontend-aesthetic-direction.md`
3. Choose the execution mode:
   - low-fi exploration -> `references/wireframe.md`
   - multiple hi-fi directions -> `references/generate-variations.md`
   - interactive prototype -> `references/make-a-prototype.md`
   - presentation / deck -> `references/make-a-deck.md`
   - live tweak controls -> `references/make-tweakable.md`
   - reusable parts inventory -> `references/component-extract.md`
4. Before broadening the work, check `references/design-principles.md` for
   filler, hierarchy, typography, color, accessibility, and state quality.
5. Before handoff, run the relevant quality passes:
   - `references/accessibility-audit.md`
   - `references/ai-slop-check.md`
   - `references/hierarchy-rhythm-review.md`
   - `references/interaction-states-pass.md`
   - `references/polish-pass.md`
6. For medium rules, verification standards, handoff posture, and scope
   boundaries, read `references/execution-delivery-and-boundaries.md`.
7. Deliver briefly: caveats, placeholders, unverified areas, and next decisions.
   Do not replace the artifact with explanation.

## Routing

| Situation | Read |
|---|---|
| Need the core designer posture and workflow | `references/foundation.md` |
| Need the full original source with no compression | `references/system-prompt-source.md` |
| Need the rules for filler, visual discipline, hierarchy, accessibility, and feedback | `references/design-principles.md` |
| Need format, verification, delivery, and scope boundaries | `references/execution-delivery-and-boundaries.md` |
| New or ambiguous design request | `references/discovery-questions.md` |
| Need tokens and visual language from an existing product | `references/design-system-extract.md` |
| Need a greenfield aesthetic direction | `references/frontend-aesthetic-direction.md` |
| Need several low-fi directions quickly | `references/wireframe.md` |
| User wants 3+ meaningful options | `references/generate-variations.md` |
| Need an interactive prototype or flow | `references/make-a-prototype.md` |
| Need a presentation or deck | `references/make-a-deck.md` |
| Need a tweak panel inside the design | `references/make-tweakable.md` |
| Need reusable components and variants extracted | `references/component-extract.md` |
| Need accessibility / WCAG review | `references/accessibility-audit.md` |
| Need AI-template tropes removed | `references/ai-slop-check.md` |
| Need hierarchy and rhythm tightened | `references/hierarchy-rhythm-review.md` |
| Need hover / focus / disabled / loading states completed | `references/interaction-states-pass.md` |
| Need a final quality gate | `references/polish-pass.md` |

## Constraints

- Do not invent brand, content, numbers, claims, status, or visual language if
  the user did not ask for it and it cannot be derived from context.
- Do not start hi-fi from scratch when real product, brand, or code context can
  be read first.
- For decks that may become editable PPTX or be shared across Windows and macOS,
  do not treat browser-perfect HTML as sufficient. Switch into a PPTX-safe
  authoring posture before drawing slides: use cross-platform-safe primary
  fonts, require UTF-8 slide HTML, and avoid editable emoji text.
- Do not bloat `SKILL.md`; the long-form rules already live in `references/`.
- Do not scatter work across many disposable files when one comparison surface,
  tweakable document, or cohesive prototype is better.
- Do not add scope silently. If a new section, copy block, or claim changes the
  task, confirm it first.
- Do not claim render, state, accessibility, or layout verification unless you
  actually checked it.

## Validation

The result is good when:

- a real artifact exists instead of advice alone;
- the right execution mode was chosen and followed;
- the visual language comes from context or from an explicit direction choice;
- filler is cut, the primary CTA is clear, and states plus hierarchy read
  correctly;
- the user receives an honest handoff with verified caveats.