Vercel geist design system
Community Agent Skills by joe-simo, including a Vercel Geist design-system skill for polished UI and companion routing.
npx -y skills add Joe-Simo/skills --skill vercel-geist-design-systemAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 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
Community skill for applying the Geist design system to Vercel-inspired rendered frontend UI across React/Next.js/Vite/Astro/Svelte/Vue/HTML/CSS, Tailwind, shadcn, and Radix. Use for typography, spacing, color, materials, components, app shells, dashboards, forms, tables, dialogs, states, responsive layout, and UI polish. Community-authored, not official Vercel. Trigger for Geist, Vercel-style UI, or generic clean/modern/premium/polished SaaS/developer-product visuals when no other final visual system is requested. Skip non-visual work unless it materially changes rendered UI.
SKILL.md
12.8 KB, as published. Nobody here has run it
Vercel Geist Design System
Use this community skill to make interfaces feel like they belong in Vercel's Geist design system: precise, calm, high-contrast, developer-focused, and production-ready. Official Vercel pages are the source of truth. This is not official Vercel guidance and is not permission to copy Vercel product screens.
Reference Loading Contract
This compact file is the operating contract. Detailed rules live in
references/; load only what the task needs, but never skip a required
reference because this summary seems sufficient.
- Always load
references/source-of-truth-gate.mdfor triggered visual work before claiming Geist, strict Geist, docs-aligned Geist, source-of-truth alignment, or Vercel Taste Gate passage. - Load
references/foundation-and-style-rules.mdbefore creating, restyling, redesigning, reviewing, or materially changing rendered UI. - Load
references/official-reference-map.mdwhen mapping foundations, brand/assets, or components to official Vercel URLs. - Load
references/vercel-design.mdwhen exact bundled light-theme token, component-default, motion, layout, focus, or voice values are needed. Loadreferences/vercel-design-dark.mdfor the same dark-theme values. - Load
references/component-system.mdbefore components, primitives, component states, custom compositions, or component-page mapping. - Load
references/trust-brand-and-asset-rules.mdbefore certification/trust credential displays, official marks, iconography, logos, badges, or brand asset work. - Load
references/motion-performance-copy-rules.mdbefore UI copy, performance-relevant UI, motion/interaction, or Web Interface Guidelines overlay work. - Load
references/companion-routing.mdonly when another Skills.sh entry, framework helper, verification helper, tool, or conditional surface could be relevant. - Load
references/taste-and-verification.mdbefore final audit, screenshots, interaction checks, or final response for triggered visual work.
Trigger Policy
Trigger this skill when a task creates, changes, critiques, specifies, or materially directs rendered frontend UI and the user asks for Geist, Vercel-style UI, or generic clean, modern, premium, beautiful, polished SaaS/developer-product visual design with no competing visual authority.
Do not trigger for TypeScript fixes, data wiring, API/state changes, analytics, tests, build tooling, dependency work, or behavior-only accessibility fixes unless rendered UI is created or materially changed.
An explicit non-Geist final visual system, brand style, supplied final non-Geist design artifact, game style, or illustrative art direction overrides this skill. Domain, industry, product, API, integration, content subject, Tailwind, shadcn, Radix, or component-library mentions are not visual-system overrides or trigger signals by themselves.
When triggered, Geist owns the visual system. Ignore generic frontend-design pushes toward bold, unforgettable, maximal, ornamental, or surprising visuals unless the user explicitly overrides Geist.
Content, IA, And Brand Preservation Gate
When applying Geist to an existing site, app, dashboard, docs surface, or product, preserve user-approved content, brand-defining visual moments, information architecture, route destinations, and external/internal link intent unless the user explicitly asks to change them or they create a concrete accessibility, performance, security, correctness, or legal/trademark problem.
Restyle before replacing. If an existing hero effect, animation, certification display, blog link, footer, contact path, navigation pattern, or route appears intentional, adapt it to Geist constraints instead of deleting, hiding, redirecting, duplicating, or inventing alternatives. If intent is unclear, report the tradeoff and keep the existing behavior.
Do not invent new CTAs, contact details, destinations, routes, issuer logos, certification labels, or navigation/footer sections solely to satisfy Geist, no-dead-end, app-shell, or primary-action guidance. Use existing product actions, existing routes, and existing content first.
For certification displays, preserve certification-specific official badge/logo artwork when present. Do not replace it with generic certificate imagery, certificate seals, course-completion marks, issuer/company logos, text labels, text monograms, or Geist Badge/Pill UI treatments.
Operating Loop
- Identify the UI surface and scope: greenfield app, full redesign, narrow workflow, marketing page, dashboard, settings, table/list, command workflow, docs, or component library.
- Select the matching Vercel/Geist reference archetype before designing. Do not treat the Vercel homepage as the default target for every Vercel-style request. For generic Vercel-style or Geist requests, use the official Geist docs plus 1-3 current Vercel surfaces that match the requested surface type when those pages are available. Use the homepage mainly for homepage, hero, launch, or broad marketing composition. For dashboards, docs, settings, forms, tables, pricing, portfolios, app shells, and component libraries, inspect comparable Vercel/Geist surfaces and components instead.
- Inspect the project before designing: framework, Tailwind version, component library, icon library, font setup, theme tokens, existing primitives, routing, package manager, and validation commands.
- Load the required references above.
- Open current official Vercel pages for every required foundation, token
source, guideline, brand/assets, and mapped component before implementation
or strict claims.
https://vercel.com/design.mdis the canonical compact token/default source for light theme work; also openhttps://vercel.com/design.dark.mdwhen dark mode or theme switching is in scope. - Complete the Foundation Gate before screen work: fonts, semantic color tokens, typography utilities, material/radius utilities, focus rings, app shell, primitives, shared states, and screen composition rules.
- Map every UI requirement to an official Geist foundation/component, official composition, or constrained custom composition before inventing patterns.
- Implement through shared tokens and primitives. Use Radix/shadcn only as behavior/accessibility infrastructure after Geist mapping; their visual defaults are not design authority.
- Verify with the Taste Gate, revise failures, then report evidence and blockers honestly.
Non-Negotiables
Official docs are binding design input, not optional inspiration.
https://vercel.com/design.md is required for every triggered visual task
because it is the official compact Geist token/default source for colors,
typography, spacing, rounded values, component defaults, layout rhythm,
elevation, motion, focus, and content voice. https://vercel.com/design.dark.md
is required when dark mode, theme switching, or dark screenshots are in scope.
Bundled snapshots in references/vercel-design.md and
references/vercel-design-dark.md exist so agents can inspect exact token tables
and defaults locally, but strict/docs-verified claims still require opening the
current live official documents because those pages are alpha.
Treat design.md as the foundation source. Use
https://vercel.com/design/guidelines for rendered UI interaction,
accessibility, state, browser, and polish checks. Use https://vercel.com/font
when installing/configuring Geist fonts or using Pixel. Use Geist Introduction,
Colors, Typography, or Materials only when the user asks for that page's detail,
design.md lacks a needed detail, or a component/page decision depends on it.
Brand/logo work requires https://vercel.com/geist/brands. Component work
requires every matching official component page from
references/official-reference-map.md or the live Geist component navigation.
If required official docs cannot be loaded after every available browsing/docs
tool is attempted in the current turn, state attempted URLs, tools, and exact
failures. Local rules then become advisory only, cannot satisfy
Docs Evidence, and cannot support strict/docs-verified claims. Label affected
work local Geist fallback, not docs-verified.
Final responses for triggered visual work must include the page-specific
Docs Evidence table defined in references/source-of-truth-gate.md. Do not
claim strict Geist, docs-aligned Geist, official Geist compliance,
source-of-truth alignment, or Vercel Taste Gate passage if any required applied
row is missing, blocked, lacks an exact section/anchor, or lacks a short
page-specific quote that affected a concrete decision. Strict claims also
require screenshot and interaction checks when those checks are possible.
Geist must own the relevant visual system. Do not create isolated
Vercel-looking widgets inside unrelated UI. Broad work covers app shell,
navigation, pages, forms, data views, dialogs, toasts, command menus, marketing
sections, and empty/loading/error states across all routable surfaces and shared
states. Narrow work covers the requested workflow plus touched primitives; say
whole app not verified unless every route/surface was audited.
Use Geist Sans globally, Geist Mono for code/technical identifiers, and Geist Pixel only for a constrained display/brand accent when justified. Keep ordinary product UI neutral-first, high-contrast, compact, semantic, accessible, and state-driven. Typography and spacing should carry hierarchy; color should be functional; borders should structure the UI; motion should be subtle and tied to state.
Use a grid system by default, not a grid background: CSS grid/flex, columns, rows, gutters, aligned cards, bordered cells, tables, dividers, spacing, and stable responsive spans are normal Geist layout. Solid page and component backgrounds are the default. Do not add decorative visible grid backgrounds, graph-paper lines, blueprint lines, or page-wide repeating gradients from the words grid layout, dashboard grid, feature grid, Vercel-style grid, or from an agent-selected Vercel reference. Add visible guide/cell/grid background art only when the user explicitly asks for visible grid art/backgrounds/cell guides, a user-supplied design clearly shows them, or the requested UI surface is the official Geist Grid component. Scope that art to the requested surface and make it a real content grid with aligned cells; never place it behind unrelated hero copy, product cards, tables, credentials, contact cells, app shells, or page bodies. Full-page visible grid backgrounds require an explicit full-page request.
Skills.sh companions are routing helpers only. They never replace official
Geist docs, never define Geist visuals, and never satisfy Docs Evidence.
Verification Contract
Before final response for triggered visual work, run the Vercel Taste Gate in
references/taste-and-verification.md: route inventory, current official docs,
Foundation Gate, component mapping, Web Interface Guidelines audit, screenshots,
interaction checks, responsive checks, anti-pattern scan, and revision loop.
If a local app can run, inspect mobile, laptop, desktop, and ultra-wide viewports plus changed states such as menus, dialogs, empty states, loading states, errors, and dense data views. If screenshots or interaction checks are possible and not captured, do not claim the Taste Gate passed. If the app cannot run or verification is blocked, state the exact blocker and use only the allowed limited claim.
Final responses must report the important evidence concisely: commands, URL,
viewport sizes, screenshot paths or blocker, changed states inspected,
interaction summary, Docs Evidence, revisions made because of the audit, and
any whole app not verified scope limit.