agentsclimarketplace

Web design system

Skill ahtishamshahzad/agent_dev_flow/.ai/skills/web/web-design-system

Tool-neutral AI Engineering System: 174 reusable skills (installable as Claude Code plugins) for planning and building software with AI agents. Classify → plan → approve → build under quality gates. Works with Claude Code, Codex, Cursor, Windsurf, Copilot & Antigravity. Canonical in .ai/.

Install
npx -y skills add ahtishamshahzad/agent_dev_flow --skill web-design-system

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

2 things to look at

  • 21 days oldThe repository was created 21 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 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 to plan the web design system — tokens (color/spacing/typography/radius), scales, reusable primitives, the styling approach (Tailwind, CSS Modules, CSS-in-JS), and component-library evaluation. Also decides how UI is shared across web apps and the dashboard.

SKILL.md

4.9 KB, 956 tokens by cl100k_base, as published. Nobody here has run it

Web Design System

Purpose

Define the visual and component foundation for the web app(s): design tokens, scales, reusable primitives, a justified styling approach, and whether/how the system is shared across multiple web apps (marketing site, customer app, dashboard).

When to Use

  • After the foundation skill, before building screens at scale.
  • When UI inconsistency or ad-hoc styling is accumulating in an existing app.
  • Not for theming mechanics (web-theme) or one-off page styling.

Inputs

  • Brand/design direction (if any) and the page inventory.
  • Selected applications and dashboard placement (dashboard-architecture) — they determine sharing needs.
  • Framework foundation (styling integrates differently in Next.js server components vs a Vite SPA).

Discovery Questions

  • Is there an existing brand/design language to encode, or are we establishing one?
  • Which styling approach fits the team: Tailwind, CSS Modules, CSS-in-JS (note server-component constraints)?
  • Should a headless/component library (e.g., Radix primitives, shadcn/ui-style copies) be evaluated, or is the surface small?
  • Do multiple apps (customer app + dashboard) need to share this system — and via what boundary (shared package, copy, monorepo)?

Responsibilities

  • Define tokens: color (semantic, theme-ready for web-theme), spacing, typography, radius, elevation, breakpoints — as the single styling vocabulary.
  • Define scales and layout primitives (stack/grid/container) before one-off components.
  • Evaluate the styling approach and any component library as decisions with trade-offs — not defaults.
  • Specify the core primitives (Button, Input, Card, Dialog, Table shell…) with accessibility expectations built in (web-accessibility).
  • Decide UI sharing across apps: shared package vs duplication, aligned with dashboard-architecture and ../../repository-architecture.

Required Workflow

  1. Gather brand direction and sharing requirements.
  2. Define tokens and scales; make color tokens semantic (theme-ready).
  3. Choose the styling approach + library candidates with justification.
  4. List the primitive set needed by the actual page inventory.
  5. Record the plan; install nothing without approval.

Decision Rules

  • Tokens first: no primitive ships with hardcoded values that a token should own.
  • Prefer headless/accessible primitives over restyling heavy widget suites.
  • CSS-in-JS runtimes conflict with server components — verify compatibility before recommending on Next.js.
  • Share UI across apps only when dashboard-architecture keeps them in one system; a separate-repo dashboard may deliberately diverge.

Rules

  • Accessibility (roles, focus, contrast) is part of a primitive's definition of done.
  • No new one-off variant when a token/primitive extension covers it.
  • Long code examples live in ../../../references/web/design-system/, not in this skill.

Anti-Patterns

  • Building screens first and extracting a "design system" from the wreckage later.
  • Adopting a large component library for three primitives.
  • Hardcoding hex values/pixel sizes that bypass tokens.
  • Duplicating a diverging copy of the system per app without a decision.

Validation Checklist

  • Tokens and scales defined; colors semantic and theme-ready.
  • Styling approach chosen with justification (server-component compatible if Next.js).
  • Component-library decision recorded (adopt/partial/none) with trade-offs.
  • Primitive set specified with accessibility expectations.
  • Cross-app sharing decision aligned with dashboard placement.

Definition of Done

A recorded design-system plan — tokens, scales, styling approach, primitive set, and sharing boundary — that screens can be built against consistently, with no unapproved installs.

Related Skills

web-theme, web-accessibility, dashboard-architecture, ../../repository-architecture, nextjs-foundation, vite-react-foundation, dashboard-tables.

Related Knowledge

../../../knowledge/ (brand direction, UI conventions).

Related References

../../../references/web/design-system/ (token tables, primitive specs — when populated).

Context Loading Guidance

  • Requires: brand direction, page inventory, sharing needs, framework foundation.
  • Does not require: full app source, data/state detail.
  • May load: web-theme when tokens are ready; dashboard-architecture for sharing boundaries.
  • Stop when: tokens, approach, and primitive set are recorded.

Token Efficiency Guidance

Keep token definitions tabular and terse. Specify primitives as one-line contracts; push code samples to references.

Gives 0 of the 12 instructions most css styling skills give in 956 tokens

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

  • avoid excessive centered layoutsin 55 of 586, across 12 files
  • bundle code into single HTML filein 54 of 586, across 14 files
  • Respect prefers-reduced-motion user settingsin 52 of 586, across 35 files
  • avoid purple gradientsin 51 of 586, across 11 files
  • avoid uniform rounded cornersin 51 of 586, across 11 files
  • avoid Inter fontin 51 of 586, across 11 files
  • edit generated files to develop artifactin 50 of 586, across 10 files
  • animate only transform and opacity propertiesin 43 of 586
  • Make touch targets at least 44x44 pixelsin 41 of 586, across 15 files
  • Ensure minimum color contrast of 4.5:1in 39 of 586, across 10 files
  • use tailwind cssin 39 of 586, across 24 files
  • Use SVG icons instead of emojisin 38 of 586, across 11 files

Said here and by no other author read

  • define semantic color spacing typography radius tokens
  • define scales and layout primitives first
  • justify the chosen styling approach and component library
  • specify primitive set needed by page inventory
  • verify server component compatibility before recommending
  • decide cross app UI sharing boundary

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.