designmd-brand-kit

DesignMD Brand Kit

Use this skill to turn a public website or provided DESIGN.md into practical design constraints for Codex UI work and client research.

Inputs

Accept any of:

• a public website URL or domain,
• a generated DESIGN.md,
• screenshots plus notes,
• existing CSS/Tailwind tokens,
• a client/company name for research.

If only a company name is given, find the official site before analyzing current visual identity.

Workflow

1. Gather brand evidence:
   • Prefer an existing DESIGN.md if provided.
   • Otherwise use designmd.supply or a local context-dot-dev/designmd-supply run when credentials are available.
   • If unavailable, manually inspect the official site, screenshots, CSS, and page content.
2. Extract constraints:
   • brand name, positioning, tone,
   • colors and semantic roles,
   • typography scale and font families,
   • spacing, radii, borders, elevation,
   • layout patterns,
   • component patterns,
   • concrete do's and don'ts.
3. Verify:
   • Check the site/screenshot for obvious mismatches.
   • Treat extracted tokens as evidence, not gospel.
   • Flag uncertainty instead of inventing precise token values.
4. Apply:
   • Generate or update DESIGN.md, Tailwind v4 theme tokens, CSS variables, or implementation notes as the task requires.
   • Use the brand kit as constraints, not as a demand to clone the original site.
5. For client research, summarize design implications without publishing, emailing, or changing external systems unless the user approves.

DESIGN.md Shape

Prefer this structure:

---
version: alpha
name:
description:
colors:
typography:
rounded:
spacing:
components:
---

## Overview
## Colors
## Typography
## Layout
## Elevation & Depth
## Shapes
## Components
## Do's and Don'ts

YAML values should be machine-usable. Markdown should explain when and how to apply them.

Token Rules

• Color values should be SRGB hex strings.
• Use semantic names: primary, secondary, surface, on-surface, muted, border, accent, error.
• Typography tokens should include font family, size, weight, line-height, and intended use.
• Spacing/radii should map to a small usable scale, not every observed value.
• Component tokens should describe repeated patterns: buttons, nav, cards, forms, badges, tables, hero, footer.
• If a token is inferred, say so in prose, not in the token value.