SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsbrand-design-md

brand-design-md

Design & creation

View repository

Updated 10-16 05:01

About this skill

Brand Design MD

Have the model obtain the real brand's structured design specifications first, then write UI, rather than guessing blindly based on "something like so-and-so's style".

Quick Assessment

Use primarily for these scenarios:

  • The user explicitly names the visual language of a brand, product, or media site
  • The user wants to generate a new page, new component, or new prototype "referencing a brand's official website style"
  • The user wants to restyle an existing React/Vue/HTML component into a brand's style
  • The user wants to mix two explicit brands and wants to clarify which layer of design language each is responsible for

Do not use for these scenarios:

  • Saying only "a bit more modern", "a bit more premium", "more design-forward"
  • Logo design, image/poster generation, visual cards, flowcharts/architecture diagrams, slide theme replacement
  • Pure design analysis or brand research without the need to produce UI code

Inputs and Outputs

Inputs typically include:

  • The user's original request
  • Existing project code or component paths (if modifying an existing project)
  • Optional output paths or target files

Outputs must be:

  • UI code generated based on real brand specifications, or
  • An incremental modification plan and code for existing UI

Do not degrade the result into abstract style suggestions; either provide code, or provide a modification explanation that is explicit down to the token source.

Entry Point

Use the local helper first; do not manually maintain the brand master list in SKILL.md , and do not assume a fixed /tmp/.../DESIGN.md path.

Helper commands

node "$SKILL_DIR/scripts/getdesign-helper.mjs" list --json
node "$SKILL_DIR/scripts/getdesign-helper.mjs" resolve --query "<user request>"
node "$SKILL_DIR/scripts/getdesign-helper.mjs" fetch --slug <brand-slug>
node "$SKILL_DIR/scripts/getdesign-helper.mjs" fetch --slug <brand-slug> --out <target-file>

This helper is responsible for:

  • Using npx getdesign@latest list to fetch the official real-time brand directory
  • Maintaining a small alias layer (Chinese names, common alternate names, easily confused spellings)
  • Resolving brands in a fixed order:alias -> slug -> fuzzy
  • Using npx getdesign@latest add <slug> --out <path> to fix the output file path

Workflow

1. First determine whether it is "creating a new prototype" or "modifying an existing project"

  • If the user is modifying within an existing repo/component, first read the current framework, component structure, and styling organization, then output incremental code in that stack.
  • If the user has not provided existing code or specified a framework, output a complete single-file HTML by default.

Do not rewrite "modify a React component" as a new HTML prototype detached from context.

2. Resolve the brand

Pass the full user request to the helper's resolve command.

  • If resolution is exact, directly use the returned matches
  • If resolution is fuzzy and there is only one high-confidence match, you may continue and state this assumption in the reply
  • If resolution is none, or the ambiguous result is not stable enough, directly show the suggestionsreturned by the helper; do not guess

By default, support at most 2 brands:

  • 1 brand: directly adopt that brand's specifications
  • 2 brands: the first brand handles layout, density, and component structure; the second brand handles accent colors, typographic character, or dimensions the user explicitly specifies
  • 3 or more brands: first ask the user to narrow down to 1-2, otherwise both output quality and attribution will be distorted

3. Get the DESIGN spec

Run the helper for each selected brand fetch：

  • When no output path is specified, have the helper write to a temporary file
  • Only pass --out <project path>

Then read the outPath file contents returned by the helper.

How to use DESIGN content

Extract and verify at least these 4 categories of tokens from the DESIGN text:

  • Colors: background, body text, accent, border
  • Typography: font, font size, font weight, line height, letter spacing
  • Spacing: section spacing, component padding, layout density
  • Shape: corner radius, stroke, shadow

If the spec gives exact values, reuse them directly; do not freely approximate.

Incorrect examples:

  • Changing rgba(...) to an approximate hex on your own
  • Rounding negative letter spacing
  • Reusing only the primary color while changing the overall density and typographic rhythm to a generic AI template

Mixing rules

When there are only two brands, handle them in this order:

  1. First determine the primary brand and the secondary brand
  2. The primary brand handles page structure, component skeleton, and spacing density
  3. The secondary brand handles accent colors, typographic mood, or the dimensions the user names
  4. If the user explicitly names a combination like "Apple whitespace + Claude accent colors", override the default rules according to the dimensions the user specifies

In mixed output, you must explain:

  • Which slugs were chosen
  • Which tokens come from the primary brand
  • Which tokens come from the secondary brand

Output contract

Whether the output is HTML, React, or Vue, it must satisfy:

  1. First state the brands and slugs finally used
  2. State whether it is the "new prototype" path or the "modify existing project" path
  3. List the key token sources in code comments or delivery notes
  4. Name at least 4 categories of tokens that are directly reused
  5. When mixing, clearly state "which part comes from which brand"

Default output:

  • Greenfield scenario: single-file HTML
  • Framework already specified: follow the original framework
  • Only save the DESIGN file into the project directory when the user explicitly requests it

At delivery, clearly state at least these 4 things:

  1. The resolved brand slugs
  2. Whether the "new prototype" or "modify existing project" path is used
  3. Evidence of directly reused tokens
  4. Where the code finally lands (in the reply, a target file, or a helper output file)

Failures and fallbacks

  • getdesign unavailable or npx fails: report the error explicitly, and suggest the user check Node.js / npx
  • Brand not found: prefer showing the helper's top 3 suggestions; do not make up your own list of supported brands
  • Upstream brand catalog changes: rely on list real-time results; this skill should not fail because of static numbers in the README
  • User provides 3 or more brands: narrow down first, then output; do not make a mix of "a little of everything"
  • User only provides vague terms (e.g., "a bit more modern"): directly state that this skill does not apply, and pivot to a more generalized design skill

Final self-check

Before delivery, quickly verify:

  • Whether the brand analysis comes from the helper, rather than handwritten guesses
  • Whether the selected slug actually exists in getdesign list
  • Whether at least 4 categories of tokens can be directly evidenced in the DESIGN text
  • Whether existing project requests preserve the original framework and original component forms
  • When mixing, whether the primary brand, secondary brand, and the layers each is responsible for are clearly stated
  • Whether the final output is still UI code, rather than vague style commentary