application

Define purple-themed application dashboard design-system rules with WCAG 2.2 AA accessibility.

1|Updated Jul 9, 2026
One-click install
npx skills add https://github.com/PiercingXX/xx-stack --skill application-piercingxx
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: application
Source: https://github.com/PiercingXX/xx-stack/tree/main/packs/design/design-skills/application
Command: npx skills add https://github.com/PiercingXX/xx-stack --skill application-piercingxx

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It provides consistent, implementation-ready visual and interaction guidance for building a purple-themed application dashboard without UI drift across teams.

Core Features & Use Cases

  • Design-system foundations: Establishes concrete tokens for colors, typography (Inter + JetBrains Mono), spacing, and layout (top-bar only navigation).
  • Component guidance: Defines how to structure rules using required states (default, hover, focus-visible, active, disabled, loading, error where relevant) so engineers can implement consistent UX.
  • Accessibility & QA standards: Sets WCAG 2.2 AA keyboard-first requirements and a testable acceptance/QA checklist to prevent regressions during code review.
  • Use case: When multiple squads contribute to an internal admin/app dashboard, you can standardize UI behavior and writing tone so the product feels coherent and accessible.

Quick Start

Ask the AI to generate application dashboard design-system rules that follow the provided foundations, include explicit states and accessibility acceptance criteria, and end with a code-review QA checklist.

Frequently Asked Questions about application

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I design an application dashboard that prevents UI drift across multiple teams?

To design an application dashboard without UI drift, use a design system with semantic tokens for colors, typography, and spacing, alongside explicit component interaction states. This ensures consistent visual patterns and UX behavior across multiple contributing squads.

What accessibility standards are required for a developer-first dashboard UI?

Developer-first dashboard UIs require WCAG 2.2 AA compliance with keyboard-first navigation. The design system must define explicit focus-visible, active, and disabled states, plus a testable acceptance checklist to prevent accessibility regressions during code review.

How do I structure design system tokens for a purple-themed product dashboard?

Structure purple-themed dashboard tokens semantically for colors, spacing, and typography using Inter and JetBrains Mono fonts. Apply these tokens to top-bar navigation and card-based layouts to maintain structured grid rhythms and consistent visual hierarchy.

What interaction states should I define for dashboard components in a design system?

Dashboard components must define default, hover, focus-visible, active, disabled, loading, and error states where relevant. Specifying these explicit states ensures engineers implement consistent UX patterns and accessible interactions across the application.

Can I use this dashboard design system guidance for internal admin tools with top-bar navigation?

Yes, this dashboard design system guidance suits internal admin tools by standardizing top-bar navigation, card-based layouts, and writing tone. It provides implementation-ready rules to make developer-first admin products feel coherent and accessible.