Apple design system
Change shared semantic tokens or design-system components in the consumer workspace. Keep the system neutral and reusable; do not encode product branding or one-off screen layout here.
Workflow
- Inventory first. Locate existing token modules, color/type/space scales, and shared components in the consumer repo. Extend them; do not create a parallel design system without authorization.
- Semantic tokens before chrome. Prefer roles (
background, label, accent, danger, spacing scale, type styles) over raw hex or one-off sizes. Map tokens to light/dark (and increased contrast when the project supports it).
- Native first. Prefer system materials, typography, and controls. Custom tokens should wrap or complement platform defaults, not fight them.
- Appearance and motion. New visual tokens must remain readable in light and dark appearance. Prefer Reduce Motion–safe defaults; avoid decorative motion that is the only affordance of meaning.
- Polish defaults. Content layer stays solid/opaque; reserve Liquid Glass for system navigation/control chrome (not content lists, cards, or tables). A Liquid Glass request means adopting native
TabView, navigation bars, toolbars, and sheets before considering custom effects; never rebuild that chrome with materials, overlays, or safe-area bars. Use brand/accent for primary actions and content highlights, not full custom chrome. Shared interactive targets must remain usable at ~44×44 pt. Prefer system text styles and Regular/Medium/Semibold/Bold; avoid Ultralight/Thin for UI copy.
- Differentiate without color alone. Status and state must not rely only on hue when color is the sole signal.
- Layering. Tokens feed shared components; app screens consume components/tokens. Do not hardcode magic numbers for shared UI when a token should exist.
- Document usage. Name tokens for role, not for a single marketing campaign or temporary experiment. Note deprecations when replacing tokens.
- Verify. Add or update focused tests/examples or a gallery surface when the project has one. Build the affected target. Accessibility audits of screens belong to
apple-accessibility-review, not this skill alone.
Stop conditions
- Application branding, campaign colors, or logo work → keep out of the shared system unless the user explicitly wants brand tokens in the consumer design system.
- App-specific screens or feature copy → feature implementation, not this skill.
- General accessibility audit of existing UI →
apple-accessibility-review.
- Planning-only request → document proposed tokens/components and migration impact without implementation.
Verification
Use swift-testing-verification for meaningful API or token logic changes. Build affected consumer targets. Report which appearances were checked and residual risk for unchecked contrast modes.
Inputs: shared token or component change. Output: neutral documented behavior, focused tests/examples, and gallery/build verification. Do not introduce branding or implement a planning-only request.
1---2name: apple-design-system3description: Use when adding or changing reusable design-system tokens or components. Do not use for application branding, app-specific screens, or a general accessibility audit.4---56# Apple design system78Change **shared** semantic tokens or design-system components in the **consumer workspace**. Keep the system neutral and reusable; do not encode product branding or one-off screen layout here.910## Workflow11121. **Inventory first.** Locate existing token modules, color/type/space scales, and shared components in the consumer repo. Extend them; do not create a parallel design system without authorization.132. **Semantic tokens before chrome.** Prefer roles (`background`, `label`, `accent`, `danger`, spacing scale, type styles) over raw hex or one-off sizes. Map tokens to light/dark (and increased contrast when the project supports it).143. **Native first.** Prefer system materials, typography, and controls. Custom tokens should wrap or complement platform defaults, not fight them.154. **Appearance and motion.** New visual tokens must remain readable in light and dark appearance. Prefer Reduce Motion–safe defaults; avoid decorative motion that is the only affordance of meaning.165. **Polish defaults.** Content layer stays solid/opaque; reserve Liquid Glass for system navigation/control chrome (not content lists, cards, or tables). A Liquid Glass request means adopting native `TabView`, navigation bars, toolbars, and sheets before considering custom effects; never rebuild that chrome with materials, overlays, or safe-area bars. Use brand/accent for primary actions and content highlights, not full custom chrome. Shared interactive targets must remain usable at ~44×44 pt. Prefer system text styles and Regular/Medium/Semibold/Bold; avoid Ultralight/Thin for UI copy.176. **Differentiate without color alone.** Status and state must not rely only on hue when color is the sole signal.187. **Layering.** Tokens feed shared components; app screens consume components/tokens. Do not hardcode magic numbers for shared UI when a token should exist.198. **Document usage.** Name tokens for role, not for a single marketing campaign or temporary experiment. Note deprecations when replacing tokens.209. **Verify.** Add or update focused tests/examples or a gallery surface when the project has one. Build the affected target. Accessibility audits of screens belong to `apple-accessibility-review`, not this skill alone.2122## Stop conditions2324- Application branding, campaign colors, or logo work → keep out of the shared system unless the user explicitly wants brand tokens in the consumer design system.25- App-specific screens or feature copy → feature implementation, not this skill.26- General accessibility audit of existing UI → `apple-accessibility-review`.27- Planning-only request → document proposed tokens/components and migration impact without implementation.2829## Verification3031Use `swift-testing-verification` for meaningful API or token logic changes. Build affected consumer targets. Report which appearances were checked and residual risk for unchecked contrast modes.3233Inputs: shared token or component change. Output: neutral documented behavior, focused tests/examples, and gallery/build verification. Do not introduce branding or implement a planning-only request.
brbndon