agentsclimarketplace

Design system

Skill danieloleary/design-md-for-codex/skills/design-system

A Codex skill that makes agents read DESIGN.md before frontend UI work.

Install
npx -y skills add danieloleary/design-md-for-codex --skill design-system

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when building, editing, reviewing, or refactoring frontend UI in a repo with DESIGN.md or design-system guidance. Read the design source first, then apply its colors, typography, spacing, components, accessibility rules, taste profile, and do/don'ts.

SKILL.md

3.3 KB, 650 tokens by cl100k_base, as published. Nobody here has run it

Design System

Use this skill to make UI work obey the repo's design source of truth.

The bundled references/DESIGN.md is a fallback starter: dark command surfaces, warm editorial support surfaces, one accent, clean borders. Use it only when the repo has no local design file.

Workflow

  1. Find the design source.

    • Prefer DESIGN.md at the repository or workspace root.
    • If absent, search one level up and then under docs/, .agents/, and design/.
    • If no repo-local design file exists, use this skill's bundled references/DESIGN.md.
    • If multiple design files exist, prefer the closest repo-root DESIGN.md and mention conflicts briefly.

  2. Read DESIGN.md before touching UI.

    • Treat YAML front matter tokens as normative values.
    • Treat Markdown sections as product rules and rationale.
    • Preserve existing app behavior while moving touched UI toward the design rules.

  3. Apply the system.

    • Use the documented colors, typography, spacing, radii, elevation, components, layout, motion, and accessibility rules.
    • Do not invent new colors, font scales, radii, shadows, component variants, or decorative motifs when a documented rule fits.
    • Prefer existing project components and tokens over new abstractions.
    • When the design direction is open, bias toward restrained, product-grade UI: clear hierarchy, few accents, borders before shadows, and practical workflows.

  4. Validate design files when they change.

    • If Node/npm are available, run: npx @google/design.md lint DESIGN.md
    • If validating the bundled example from this skill, run: npx @google/design.md lint skills/design-system/references/DESIGN.md
    • Treat linter errors as blockers. Treat warnings as review items to fix or explain.

  5. Verify the rendered UI.

    • Start the app's existing dev server if needed.
    • Use browser-based checks or screenshots at desktop and mobile widths.
    • Check for overflow, overlapping text, broken focus states, unreadable contrast, and layout shift.
    • In the final response, name which design file you read and summarize the main rules you applied.

Review Checklist

  • UI uses DESIGN.md tokens or project variables derived from them.
  • Primary actions are visually clear and not overused.
  • Typography matches the documented hierarchy.
  • Spacing follows the documented scale.
  • Components follow documented shape, border, and elevation rules.
  • Color communicates state accessibly and never as the only signal.
  • Mobile and desktop layouts remain usable without text overlap.
  • No decorative gradients, blobs, nested cards, or invented visual systems were added unless the repo design file explicitly asks for them.
  • Final response confirms the DESIGN.md source and the design rules applied.

Missing Or Incomplete Design Files

If DESIGN.md is missing, say so briefly and use the app's existing conventions or the bundled starter. If a needed rule is missing, make the smallest reasonable choice and offer to add the rule so the next pass is sharper.

Gives 0 of the 12 instructions most design systems skills give in 650 tokens

Counted across 528 of the 534 authors here whose files we hold, read 2026-08-06

  • create a custom theme if neededin 54 of 528, across 10 files
  • read the corresponding theme filein 54 of 528, across 10 files
  • ask which theme to applyin 53 of 528, across 9 files
  • show the theme showcasein 53 of 528, across 9 files
  • maintain visual identity across all slidesin 50 of 528, across 6 files
  • apply the specified colors and fontsin 47 of 528, across 3 files
  • get explicit confirmationin 45 of 528, across 1 file
  • Generate a design system before codingin 19 of 528, across 6 files
  • Maintain at least 4.5:1 color contrast ratioin 19 of 528, across 8 files
  • Describe component shapes, colors, shadows, and interaction statesin 18 of 528, across 4 files
  • Check Python installation and install if missingin 17 of 528, across 4 files
  • Default to html-tailwind if stack is unspecifiedin 17 of 528, across 4 files

Said here and by no other author read

  • use documented colors typography spacing and components
  • prefer existing project components and tokens
  • treat linter errors as blockers
  • verify the rendered UI at desktop and mobile widths
  • name the design file and summarize applied rules
  • use bundled design file if repo lacks one

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.