Stark

stark-backend

This skill should be used for server-side accessibility work — whenever the user is dealing with accessibility concerns that originate on the back end: missing or wrong `lang` / document metadata, server-rendered (SSR / template / transactional email) markup semantics, API error and validation payload shape, dynamic/streamed fragments, HTTP status and session handling, or content-model fields like image `alt`. Use it when the user mentions "server", "API", "backend", "template", "SSR", "validation errors", "lang attribute", or wants to fix Stark code-asset violations whose root cause is server-side, or to set up code / CI scanning. Prefer this skill when an accessibility issue is really about responses, contracts, or metadata rather than UI components.

stark-design

This skill should be used for design-stage accessibility work in Figma or Sketch — whenever the user mentions "contrast", "color contrast", "color blindness", "design accessibility", "Figma accessibility", "target size", "reading order", "alt text" at design time, or wants to fix Stark violations on a Figma/design asset, or to scan a Figma file. Use it to give fixes in design language — contrast ratios, hex values, spacing, type scales, component states, and design tokens — never code. Prefer this skill for any accessibility work on design files even if the user doesn't say "Stark".

stark-frontend

This skill should be used for web front-end accessibility work — whenever the user mentions "accessibility", "a11y", "WCAG", "ARIA", "screen reader", "keyboard navigation", "focus management", or "semantic HTML", asks to fix accessibility violations on a web / URL / code / Storybook asset in Stark, or wants to set up accessibility scanning for a website or front-end codebase. Use it to turn Stark violations into correct, minimal HTML/ARIA fixes and to tell real WCAG failures apart from best-practice cleanup. Prefer this skill for any web UI accessibility task even if the user doesn't say "Stark".

stark-mobile

This skill should be used for native mobile accessibility work — iOS (UIKit/SwiftUI), Android (Views/Compose), and cross-platform frameworks (React Native, Flutter). Use it whenever the user mentions "VoiceOver", "TalkBack", "accessibilityLabel", "contentDescription", "Dynamic Type", "Compose semantics", "touch target", "iOS accessibility", "Android accessibility", or wants to fix Stark violations on an iOS / Android / mobile code asset, or set up scanning for a mobile app. Use it to translate WCAG criteria into the correct native accessibility API for the user's platform. Prefer this skill for any mobile-app accessibility task even if the user doesn't say "Stark".

stark-pm

This skill should be used for accessibility program and project management — whenever the user asks where they stand on accessibility, about compliance status against WCAG / Section 508 / EAA, how to prioritize a violation backlog, what to put in a status update or audit summary, or how to plan remediation across a team. Use it when the user mentions "compliance", "posture", "are we compliant", "audit", "roadmap", "prioritize", "Compliance Center", "status update", or works at the project/team level rather than fixing individual issues. It gives posture, priorities, and stakeholder-ready language — never code — and routes fixes to the right discipline. Prefer this skill for accessibility management and reporting questions.