Implement accessible UI with ak:ui-styling

Use ak:ui-styling to implement or refine React-based interfaces with shadcn/ui, Radix primitives, Tailwind CSS, theme tokens, responsive layouts, and accessibility patterns. The Skill can advise from bundled references or mutate the project by adding components and generating configuration.

Choose ak:ui-styling for UI implementation

Use ak:ui-styling when

• You need to add or compose shadcn/ui components in an existing project.
• You are implementing Tailwind utilities, tokens, dark mode, responsive layout, form behavior, focus states, or screen-reader support.
• You want a component-level accessibility and visual-consistency pass.
• You need a canvas-style visual artifact with an accompanying design philosophy.

Choose another workflow when

• You need product-level style, palette, typography, UX, or chart recommendations before implementation. Use ak:ui-ux-pro-max.
• You only need an audit against current external web guidelines. Use ak:web-design-guidelines.
• You need logos, identity mockups, posters, or marketing graphics. Use ak:design.
• The task is backend-only or does not change a visible or interactive surface.

Prepare the project

• Read repository instructions and identify the existing framework, package manager, Tailwind version, theme source, aliases, and component conventions.
• Preserve current design tokens. Provide the relevant page or component, supported breakpoints, states, content, and acceptance criteria.
• Confirm components.json exists before adding shadcn/ui components. The bundled installer does not initialize shadcn/ui for you.
• Make Node.js and npx available for shadcn/ui. Python is required only for the bundled helper scripts.
• Define the file boundary and whether package manifests, lockfiles, components/ui/, global CSS, or Tailwind configuration may change.

See Runtime adapters for delivery details.

Run the Skill

The top-level Skill takes a component or layout request and has no documented mode flags. Put the desired states, responsive behavior, accessibility checks, and file boundary in the request.

/ak:ui-styling "Add an accessible account dialog using existing tokens; preserve components.json, support keyboard focus and reduced motion, test light/dark at mobile and desktop, and do not overwrite existing UI files"

/ak:ui-styling "Add an accessible account dialog using existing tokens; preserve components.json, support keyboard focus and reduced motion, test light/dark at mobile and desktop, and do not overwrite existing UI files"

$ak:ui-styling "Add an accessible account dialog using existing tokens; preserve components.json, support keyboard focus and reduced motion, test light/dark at mobile and desktop, and do not overwrite existing UI files"

Choose the mutation path deliberately

The Tailwind generator supports --framework, --js, --colors, --fonts, --spacing, --breakpoints, --plugins, --output, and --validate-only. Generated plugin entries still require the named packages to be installed.

Follow the observable stages

1. Inspect the system. Identify versions, tokens, component patterns, accessibility requirements, responsive boundaries, and protected files.
2. Select primitives and states. Prefer semantic HTML and Radix-backed behavior; define default, hover, focus, pressed, disabled, loading, error, empty, and dark-mode states before styling.
3. Review the file plan. Distinguish component copies, package changes, global theme changes, and generated configuration. Use dry-run or validation-only helpers when appropriate.
4. Implement with existing tokens. Keep utilities static and discoverable, use semantic color names, preserve visible focus, and build mobile-first.
5. Verify behavior and visuals. Run focused project checks, keyboard flows, contrast checks, reduced motion, zoom, and breakpoint inspection.
6. Report evidence. List changed files, installed packages, commands, test results, screenshots or manual checks, and any unverified state.

Keep approvals with the project owner

• npx shadcn@latest can contact a package registry and execute downloaded CLI code. Record the resolved package changes and use the repository package manager when its policy requires one.
• The configuration generator can replace an existing file at its output path. Compare or choose a new path before writing.
• Dark-mode and token changes can affect the entire application. Treat global CSS and shared primitives as broader scope than one component.
• An accessible primitive does not make its composition accessible. Labels, focus order, errors, contrast, keyboard behavior, zoom, and reduced motion still require verification.

Verify outputs and evidence

A complete run should show:

• The exact component, stylesheet, config, manifest, and lockfile diff.
• The source token mapping and confirmation that no accidental raw colors or one-off spacing values replaced semantic tokens.
• Keyboard navigation, visible focus, dialog focus return, labels, live-region behavior, error association, touch targets, and color-contrast results.
• Light and dark mode at relevant breakpoints, including 320px, 640px, 768px, 1024px, landscape, 200% zoom, and reduced motion when applicable.
• Focused tests and build/type evidence available in the project, plus explicit notes for anything checked manually or not checked.

Troubleshoot and limits

The reference files are bundled guidance and can lag current shadcn/ui, Tailwind, browser, or accessibility documentation. Confirm version-sensitive syntax against the installed project. Stable and beta contain identical ak:ui-styling content and helpers in the documented releases.

Continue with Runtime adapters, Projects, artifacts, and checkpoints, or the Engineer Kit overview.