---
name: hierarchical-agent-memory
description: "Scoped CLAUDE.md memory system that reduces context token spend. Creates directory-level context files, tracks savings via dashboard, and routes agents to the right sub-context."
risk: safe
source: "https://github.com/kromahlusenii-ops/ham"
date_added: "2026-02-27"
---

# Hierarchical Agent Memory (HAM)

Scoped memory system that gives AI coding agents a cheat sheet for each directory instead of re-reading your entire project every prompt. Root CLAUDE.md holds global context (~200 tokens), subdirectory CLAUDE.md files hold scoped context (~250 tokens each), and a `.memory/` layer stores decisions, patterns, and an inbox for unconfirmed inferences.

## When to Use This Skill

- Use when you want to reduce input token costs across Claude Code sessions
- Use when your project has 3+ directories and the agent keeps re-reading the same files
- Use when you want directory-scoped context instead of one monolithic CLAUDE.md
- Use when you want a dashboard to visualize token savings, session history, and context health
- Use when setting up a new project and want structured agent memory from day one

## How It Works

### Step 1: Setup ("go ham")

Auto-detects your project platform and maturity, then generates the memory structure:

```
project/
├── CLAUDE.md              # Root context (~200 tokens)
├── .memory/
│   ├── decisions.md       # Architecture Decision Records
│   ├── patterns.md        # Reusable patterns
│   ├── inbox.md           # Inferred items awaiting confirmation
│   └── audit-log.md       # Audit history
└── src/
    ├── api/CLAUDE.md      # Scoped context for api/
    ├── components/CLAUDE.md
    └── lib/CLAUDE.md
```

### Step 2: Context Routing

The root CLAUDE.md includes a routing section that tells the agent exactly which sub-context to load:

```markdown
## Context Routing

→ api: src/api/CLAUDE.md
→ components: src/components/CLAUDE.md
→ lib: src/lib/CLAUDE.md
```

The agent reads root, then immediately loads the relevant subdirectory context — no guessing.

### Step 3: Dashboard ("ham dashboard")

Launches a web dashboard at localhost:7777 that visualizes:
- Token savings (HAM-on vs HAM-off sessions)
- Daily token and cost trends
- Per-directory session breakdown
- Context file health (missing/stale/inherited CLAUDE.md coverage)
- Routing compliance (how often the agent follows the routing map)
- Carbon/energy estimates

## Commands

| Trigger | What it does |
|---|---|
| `go ham` | Set up HAM — auto-detect platform, generate CLAUDE.md files |
| `ham savings` | Show token and cost savings report |
| `ham dashboard` | Launch the interactive web dashboard |
| `ham audit` | Health check on memory files |
| `ham insights` | Generate actionable insights from session data |
| `ham route` | Add/update Context Routing section in root CLAUDE.md |
| `ham carbon` | Show energy and carbon efficiency data |

## Examples

### Example 1: First-time setup

```
User: go ham

Agent: HAM setup complete. Created 8 files.
  - CLAUDE.md (root)
  - .memory/decisions.md
  - .memory/patterns.md
  - .memory/inbox.md
  - src/api/CLAUDE.md
  - src/components/CLAUDE.md
  - src/lib/CLAUDE.md
  - src/utils/CLAUDE.md

Baseline captured in .memory/baseline.json
Run "HAM savings" to see your token and cost savings.
```

### Example 2: Checking savings

```
User: ham savings

Agent:
  Before HAM: ~7,500 tokens/prompt
  After HAM:    ~450 tokens/prompt
  Savings:    7,050 tokens (94%)

  Monthly projection (1,500 prompts):
    Sonnet: ~$31.73 saved
    Opus:   ~$158.63 saved
```

## Best Practices

- Keep root CLAUDE.md under 60 lines / 250 tokens
- Keep subdirectory CLAUDE.md files under 75 lines each
- Run `ham audit` every 2 weeks to catch stale or missing context files
- Use `ham route` after adding new directories to keep routing current
- Review `.memory/inbox.md` periodically — confirm or reject inferred items

## Limitations

- Token estimates use ~4 chars = 1 token approximation, not a real tokenizer
- Baseline savings comparisons are estimates based on typical agent behavior
- Dashboard requires Node.js 18+ and reads session data from `~/.claude/projects/`
- Context routing detection relies on CLAUDE.md read order in session JSONL files
- Does not auto-update subdirectory CLAUDE.md content — you maintain those manually or via `ham audit`
- Carbon estimates use regional grid averages, not real-time energy data

## Related Skills

- `agent-memory-systems` — general agent memory architecture patterns
- `agent-memory-mcp` — MCP-based memory integration


---
name: hig-components-content
description: Apple Human Interface Guidelines for content display components.
risk: safe
source: community
date_added: '2026-02-27'
---

# Apple HIG: Content Components

Check for `.claude/apple-design-context.md` before asking questions. Use existing context and only ask for information not already covered.

## Key Principles

1. **Adapt to different sizes and contexts.** Content components must work across screen sizes, orientations, and multitasking configurations. Use Auto Layout and size classes.

2. **Make content accessible.** Charts need audio graph support. Images need alt text. Collections need proper VoiceOver navigation order. All content components need labels and descriptions.

3. **Maintain visual hierarchy.** Use spacing, sizing, and grouping to establish clear information hierarchy. Primary content should be visually prominent.

4. **Use system components first.** Evaluate UICollectionView, SwiftUI Charts, WKWebView before building custom. System components come with built-in accessibility and platform adaptation.

5. **Respect platform conventions.** A collection on tvOS uses large lockups with parallax. The same collection on iOS uses compact cells with touch targets. On visionOS, content gains depth and hover effects.

6. **Handle empty states.** Show a meaningful empty state with guidance on how to populate it, not a blank screen.

7. **Optimize for performance.** Use lazy loading, cell reuse, pagination, and prefetching for large datasets.

## Reference Index

| Reference | Topic | Key content |
|---|---|---|
| [charts.md](references/charts.md) | Charts | Swift Charts, bar/line/area/point marks, chart accessibility, audio graphs |
| [collections.md](references/collections.md) | Collections | Grid/list layouts, compositional layout, selection, reordering, diffable data sources |
| [image-views.md](references/image-views.md) | Image Views | Aspect ratio handling, content modes, SF Symbol images, accessibility |
| [image-wells.md](references/image-wells.md) | Image Wells | Drag-and-drop image selection, macOS-specific, placeholder content |
| [color-wells.md](references/color-wells.md) | Color Wells | Color selection UI, system color picker, custom color spaces |
| [web-views.md](references/web-views.md) | Web Views | WKWebView, SFSafariViewController, navigation controls, content restrictions |
| [activity-views.md](references/activity-views.md) | Activity Views | Share sheets, activity items, custom activities, action extensions |
| [lockups.md](references/lockups.md) | Lockups | Image+text elements, tvOS card layouts, focus effects, shelf layouts |

## Component Selection Guide

| Content Need | Recommended Component | Platform Notes |
|---|---|---|
| Visualizing quantitative data | Charts (Swift Charts) | iOS 16+, macOS 13+, watchOS 9+ |
| Browsing a grid or list of items | Collection View | Compositional layout for complex arrangements |
| Displaying a single image | Image View | Support aspect ratio fitting; provide accessibility description |
| Selecting an image via drag or browse | Image Well | macOS primarily; use image pickers on iOS |
| Selecting a color | Color Well | Triggers system color picker; macOS, iOS 14+ |
| Showing web content inline | Web View (WKWebView) | Use SFSafariViewController for external browsing |
| Sharing content to other apps | Activity View | System share sheet with configurable activity types |
| Content card (image + text) | Lockup | Primarily tvOS; adaptable to other platforms |

## Output Format

1. **Component recommendation with rationale**, referencing the relevant HIG reference file.
2. **Configuration guidance** -- key properties and setup.
3. **Accessibility requirements** for the recommended component.
4. **Platform-specific notes** for targeted platforms.

## Questions to Ask

1. What type of content? (Quantitative data, images, web content, browsable collection, share action?)
2. Which platforms?
3. Static or dynamic content?
4. How much content? (Few items vs hundreds/thousands affects component choice and optimization.)

## Related Skills

- **hig-foundations** -- Color, typography, accessibility, and image guidelines
- **hig-patterns** -- Data visualization, sharing, and loading patterns
- **hig-components-layout** -- Structural containers (scroll views, lists, split views) hosting content
- **hig-platforms** -- Platform-specific component behavior (lockups on tvOS, web views on macOS)

---

*Built by [Raintree Technology](https://raintree.technology) · [More developer tools](https://raintree.technology)*

## When to Use
This skill is applicable to execute the workflow or actions described in the overview.

## Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.


---
name: hig-components-controls
description: "Check for .claude/apple-design-context.md before asking questions. Use existing context and only ask for information not already covered."
risk: none
source: community
date_added: '2026-02-27'
---

# Apple HIG: Selection and Input Controls

Check for `.claude/apple-design-context.md` before asking questions. Use existing context and only ask for information not already covered.

## Key Principles

1. **Clear current state.** Users must always see what is selected. Toggles show on/off, segmented controls highlight the active segment, pickers display the current selection.

2. **Prefer standard system controls.** Built-in controls provide consistency and accessibility. Custom controls introduce a learning curve and may break assistive features.

3. **Toggles for binary states.** On or off. In Settings-style screens, changes take effect immediately. In modal forms, changes commit on confirmation.

4. **Segmented controls for mutually exclusive options.** 2-5 items, roughly equal importance, short labels.

5. **Sliders for continuous values.** When precise numeric input is not critical. Provide min/max labels or icons for range endpoints.

6. **Pickers for long option lists.** Too many options for a segmented control. Works well for dates, times, structured data.

7. **Steppers for small, precise adjustments.** Increment/decrement in fixed steps. Display current value next to the stepper with reasonable min/max bounds.

8. **Text fields for short, single-line input.** Text views for multi-line. Configure keyboard type to match expected input (email, URL, number).

9. **Combo boxes: text input + selection list.** macOS. Type a value or choose from a predefined list when custom values are valid.

10. **Token fields: discrete values as visual tokens.** macOS. For email recipients, tags, or collections of discrete items.

11. **Gauges and rating indicators display values.** Gauges show a value within a range. Rating indicators show ratings (often stars). Display-only; use interactive variants for input.

## Reference Index

| Reference | Topic | Key content |
|---|---|---|
| [controls.md](references/controls.md) | General controls | States, affordance, system controls |
| [toggles.md](references/toggles.md) | Toggles | On/off, immediate effect |
| [segmented-controls.md](references/segmented-controls.md) | Segmented controls | 2-5 options, equal weight |
| [sliders.md](references/sliders.md) | Sliders | Continuous range, min/max labels |
| [steppers.md](references/steppers.md) | Steppers | Fixed steps, bounded values |
| [pickers.md](references/pickers.md) | Pickers | Dates, times, long option sets |
| [combo-boxes.md](references/combo-boxes.md) | Combo boxes | macOS, type or select, custom values |
| [text-fields.md](references/text-fields.md) | Text fields | Short input, keyboard types, validation |
| [text-views.md](references/text-views.md) | Text views | Multi-line, comments, descriptions |
| [labels.md](references/labels.md) | Labels | Placement, VoiceOver support |
| [token-fields.md](references/token-fields.md) | Token fields | macOS, chips, tags, recipients |
| [virtual-keyboards.md](references/virtual-keyboards.md) | Virtual keyboards | Email, URL, number keyboard types |
| [rating-indicators.md](references/rating-indicators.md) | Rating indicators | Star ratings, display-only |
| [gauges.md](references/gauges.md) | Gauges | Level indicators, range display |

## Output Format

1. **Control recommendation with rationale** and why alternatives are less suitable.
2. **State management** -- how the control communicates current state and whether changes apply immediately or on confirmation.
3. **Validation approach** -- when to show errors and how to communicate rules.
4. **Accessibility** -- labels, traits, hints for VoiceOver.

## Questions to Ask

1. What type of data? (Boolean, choice from fixed set, numeric, free-form text?)
2. How many options?
3. Which platforms? (Combo boxes and token fields are macOS-only)
4. Settings screen or inline form?

## Related Skills

- **hig-components-menus** -- Buttons and pop-up buttons complementing selection controls
- **hig-components-dialogs** -- Sheets and popovers containing forms
- **hig-components-search** -- Search fields sharing text input patterns
- **hig-inputs** -- Keyboard, pointer, gesture interactions with controls
- **hig-foundations** -- Typography, color, layout for control styling

---

*Built by [Raintree Technology](https://raintree.technology) · [More developer tools](https://raintree.technology)*

## When to Use
This skill is applicable to execute the workflow or actions described in the overview.

## Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.


---
name: hig-components-dialogs
description: Apple HIG guidance for presentation components including alerts, action sheets, popovers, sheets, and digit entry views.
risk: none
source: community
date_added: '2026-02-27'
---

# Apple HIG: Presentation Components

Check for `.claude/apple-design-context.md` before asking questions. Use existing context and only ask for information not already covered.

## Key Principles

1. **Alerts: sparingly, for critical situations.** Errors needing attention, destructive action confirmations, or information requiring acknowledgment. They interrupt flow and demand a response.

2. **Sheets: focused tasks that maintain context.** Slides in from the edge (or attaches to a window on macOS). Use for creating items, editing settings, multi-step forms.

3. **Popovers: non-modal on iPad and Mac.** Appear next to the trigger element, dismissed by tapping outside. For additional information, options, or controls without taking over the screen.

4. **Action sheets: choosing among actions.** Present when picking from multiple actions, especially if one is destructive. iPhone: slide up from bottom. iPad: appear as popovers.

5. **Minimize interruptions.** Before reaching for a modal, consider inline presentation or making the action undoable instead.

6. **Concise, actionable alert text.** Short descriptive title. Brief message body if needed. Button labels should be specific verbs ("Delete", "Save"), not "OK".

7. **Mark destructive actions clearly.** Destructive button style (red text). Place destructive buttons where users are less likely to tap reflexively.

8. **Provide a cancel option** for alerts and action sheets with multiple actions. On action sheets, cancel appears at the bottom, separated.

9. **Digit entry: focused and accessible.** Appropriately sized input fields, automatic advancement between digits, support for paste and autofill.

10. **Adapt presentation to platform.** The same interaction may use different components on iPhone, iPad, Mac, and visionOS.

## Reference Index

| Reference | Topic | Key content |
|---|---|---|
| [alerts.md](references/alerts.md) | Alerts | Button ordering, title/message text, confirmation, destructive actions |
| [action-sheets.md](references/action-sheets.md) | Action sheets | Multiple actions, cancel option, destructive handling |
| [popovers.md](references/popovers.md) | Popovers | Non-modal, dismiss on tap outside, iPad/Mac |
| [sheets.md](references/sheets.md) | Sheets | Modal task, context preservation |
| [digit-entry-views.md](references/digit-entry-views.md) | Digit entry | PIN input, autofill, auto-advance |

## Output Format

1. **Recommended presentation type with rationale** and why alternatives are less suitable.
2. **Content guidelines** -- title, message, button labels per Apple's tone and brevity rules.
3. **Dismiss behavior** -- how the user dismisses and what happens (save, discard, cancel).
4. **Alternatives** -- when the scenario might not need a modal at all (inline feedback, undo, progressive disclosure).

## Questions to Ask

1. What information or action does the presentation need?
2. Blocking or non-blocking?
3. Which platforms?
4. How often does this appear?

## Related Skills

- **hig-components-menus** -- Buttons and toolbar items triggering presentations
- **hig-components-controls** -- Input controls within sheets and popovers
- **hig-components-search** -- Search and navigation within presented views
- **hig-patterns** -- Modality, interruptions, user flow management
- **hig-foundations** -- Color, typography, layout for presentation components

---

*Built by [Raintree Technology](https://raintree.technology) · [More developer tools](https://raintree.technology)*

## When to Use
This skill is applicable to execute the workflow or actions described in the overview.

## Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.


---
name: hig-components-layout
description: Apple Human Interface Guidelines for layout and navigation components.
risk: none
source: community
date_added: '2026-02-27'
---

# Apple HIG: Layout and Navigation Components

Check for `.claude/apple-design-context.md` before asking questions. Use existing context and only ask for information not already covered.

## Key Principles

1. **Organize hierarchically.** Structure information from broad categories to specific details. Sidebars for top-level sections, lists for browsable items, detail views for individual content.

2. **Use standard navigation patterns.** Tab bars for flat navigation between peer sections (iPhone). Sidebars for deep hierarchical navigation (iPad, Mac). Match the pattern to the information architecture and platform.

3. **Adapt to screen size.** Three-column on iPad collapses to single-column on iPhone. Use size classes and adaptive APIs (NavigationSplitView) for automatic adaptation.

4. **Support multitasking on iPad.** Respond gracefully to Split View, Slide Over, and Stage Manager. Test at every split ratio and size class transition.

5. **Maintain spatial consistency on visionOS.** Windows, volumes, and ornaments in shared space. Position predictably. Use ornaments for toolbars and controls without occluding content.

6. **Use scroll views for overflow content.** Enable paging for discrete content units. Support pull-to-refresh where appropriate. Respect safe areas.

7. **Keep navigation predictable.** Users should always know where they are, how they got there, and how to go back. Use back buttons, breadcrumbs, and clear section titles.

8. **Prefer system components.** UINavigationController, UISplitViewController, NavigationSplitView, and TabView provide built-in adaptivity, accessibility, and state restoration.

## Reference Index

| Reference | Topic | Key content |
|---|---|---|
| [sidebars.md](references/sidebars.md) | Sidebars | Source lists, selection state, collapsible sections, iPad/Mac patterns |
| [column-views.md](references/column-views.md) | Column Views | Finder-style browsing, progressive disclosure through columns |
| [outline-views.md](references/outline-views.md) | Outline Views | Expandable hierarchies, disclosure triangles, tree structures |
| [split-views.md](references/split-views.md) | Split Views | Two/three column layouts, NavigationSplitView, adaptive collapse |
| [tab-views.md](references/tab-views.md) | Tab Views | Segmented tabs, page-style tabs, macOS tab grouping |
| [tab-bars.md](references/tab-bars.md) | Tab Bars | Bottom tab bars (iOS), badge counts, max tab count |
| [scroll-views.md](references/scroll-views.md) | Scroll Views | Paging, scroll indicators, content insets, pull-to-refresh |
| [windows.md](references/windows.md) | Windows | macOS/visionOS window management, sizing, full-screen, restoration |
| [panels.md](references/panels.md) | Panels | Inspector panels, utility panels, floating panels, macOS conventions |
| [lists-and-tables.md](references/lists-and-tables.md) | Lists and Tables | Plain/grouped/inset-grouped styles, swipe actions, section headers |
| [boxes.md](references/boxes.md) | Boxes | Content grouping containers, labeled boxes, macOS grouping |
| [ornaments.md](references/ornaments.md) | Ornaments | visionOS toolbar attachments, positioning, visibility |

## Navigation Pattern Selection

| App Structure | Recommended Pattern | Platform Adaptation |
|---|---|---|
| 3-5 peer top-level sections | Tab Bar | iPhone: bottom tab bar. iPad: sidebar (`.sidebarAdaptable`, iPadOS 18+). Mac: sidebar or toolbar tabs |
| Deep hierarchical content | Sidebar + NavigationSplitView | iPhone: single column stack. iPad: two/three columns. Mac: full multi-column |
| Deep file/folder tree | Column View | Mac: Finder-style. iPad: adaptable. iPhone: push navigation |
| Flat list with detail | Split View (two column) | iPhone: push/pop stack. iPad/Mac: primary + detail columns |
| Document-based with inspectors | Window + Panels | Mac: main window with inspector. iPad: sheet or popover |
| Spatial app with tools | Window + Ornaments | visionOS: ornaments on window. Other platforms: toolbars |

## Layout Adaptation Checklist

- [ ] **Compact width (iPhone portrait):** Navigation collapses to single stack? Tab bars visible?
- [ ] **Regular width (iPad landscape, Mac):** Navigation expands to sidebar + detail? Space used well?
- [ ] **Multitasking (iPad):** Adapts at every split ratio? Works in Slide Over?
- [ ] **Accessibility:** Supports Dynamic Type at all sizes? VoiceOver order logical?
- [ ] **Orientation:** Content reflows between portrait and landscape?
- [ ] **visionOS:** Windows positioned ergonomically? Ornaments accessible? Depth meaningful?

## Output Format

1. **Recommended navigation pattern** with rationale for the app's information architecture.
2. **Layout hierarchy** from root container down (e.g., TabView > NavigationSplitView > List > Detail).
3. **Platform adaptation** across targeted platforms and size classes.
4. **Size class behavior** at each transition.

## Questions to Ask

1. What is the app's information architecture? (Sections, hierarchy depth, top-level categories?)
2. How many top-level sections?
3. Which platforms?
4. Need multitasking on iPad?
5. SwiftUI or UIKit?

## Related Skills

- **hig-foundations** -- Layout spacing, margins, safe areas, alignment
- **hig-platforms** -- Platform-specific navigation conventions
- **hig-patterns** -- Multitasking, full-screen, and launching patterns
- **hig-components-content** -- Content displayed within layout containers

---

*Built by [Raintree Technology](https://raintree.technology) · [More developer tools](https://raintree.technology)*

## When to Use
This skill is applicable to execute the workflow or actions described in the overview.

## Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.


---
name: hig-components-menus
description: "Check for .claude/apple-design-context.md before asking questions. Use existing context and only ask for information not already covered."
risk: none
source: community
date_added: '2026-02-27'
---

# Apple HIG: Menus and Buttons

Check for `.claude/apple-design-context.md` before asking questions. Use existing context and only ask for information not already covered.

## Key Principles

1. **Menus should be contextual and predictable.** Standard items in standard locations. Follow platform conventions for ordering and grouping.

2. **Use standard button styles.** System-defined styles communicate affordance and maintain visual consistency. Prefer them over custom designs.

3. **Toolbars for frequent actions.** Most commonly used commands in the toolbar. Rarely used actions belong in menus.

4. **Menu bar is the primary command interface on macOS.** Every command reachable from the menu bar. Toolbars and context menus supplement, not replace.

5. **Context menus for secondary actions.** Right-click or long-press, relevant to the item under the pointer. Never put a command only in a context menu.

6. **Pop-up buttons for mutually exclusive choices.** Select exactly one option from a set.

7. **Pull-down buttons for action lists.** No current selection; they offer a set of commands.

8. **Action buttons consolidate related actions** behind a single icon in toolbars or title bars.

9. **Disclosure controls for progressive disclosure.** Show or hide additional content.

10. **Dock menus: short and focused** on the most useful actions when the app is running.

## Reference Index

| Reference | Topic | Key content |
|---|---|---|
| [menus.md](references/menus.md) | General menu design | Item ordering, grouping, shortcuts |
| [context-menus.md](references/context-menus.md) | Context menus | Right-click, long press, secondary actions |
| [dock-menus.md](references/dock-menus.md) | Dock menus | macOS app-level actions, running state |
| [edit-menus.md](references/edit-menus.md) | Edit menus | Undo, copy, paste, standard items |
| [the-menu-bar.md](references/the-menu-bar.md) | Menu bar | macOS primary command interface, structure |
| [toolbars.md](references/toolbars.md) | Toolbars | Frequent actions, customization, placement |
| [buttons.md](references/buttons.md) | Buttons | System styles, sizing, affordance |
| [action-button.md](references/action-button.md) | Action button | Grouped secondary actions, toolbar use |
| [pop-up-buttons.md](references/pop-up-buttons.md) | Pop-up buttons | Mutually exclusive choice selection |
| [pull-down-buttons.md](references/pull-down-buttons.md) | Pull-down buttons | Action lists, no current selection |
| [disclosure-controls.md](references/disclosure-controls.md) | Disclosure controls | Progressive disclosure, show/hide |

## Output Format

1. **Component recommendation** -- which menu or button type and why.
2. **Visual hierarchy** -- placement, sizing, grouping within the interface.
3. **Platform-specific behavior** across iOS, iPadOS, macOS, visionOS.
4. **Keyboard shortcuts** (macOS) -- standard and custom shortcuts for menu items and toolbar actions.

## Questions to Ask

1. Which platforms?
2. Primary or secondary action?
3. How many actions need to be available?
4. macOS menu bar app?

## Related Skills

- **hig-components-search** -- Search fields, page controls alongside toolbars and menus
- **hig-components-controls** -- Toggles, pickers, segmented controls complementing buttons
- **hig-components-dialogs** -- Alerts, sheets, popovers triggered by menu items or buttons
- **hig-inputs** -- Keyboard shortcuts and pointer interactions with menus and toolbars

---

*Built by [Raintree Technology](https://raintree.technology) · [More developer tools](https://raintree.technology)*

## When to Use
This skill is applicable to execute the workflow or actions described in the overview.

## Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.


---
name: hig-components-search
description: Apple HIG guidance for navigation-related components including search fields, page controls, and path controls.
risk: safe
source: community
date_added: '2026-02-27'
---

# Apple HIG: Navigation Components

Check for `.claude/apple-design-context.md` before asking questions. Use existing context and only ask for information not already covered.

## Key Principles

1. **Search: discoverable with instant feedback.** Place search fields where users expect them (top of list, toolbar/navigation bar). Show results as the user types.

2. **Page controls: position in a flat page sequence.** For discrete, equally weighted pages (onboarding, photo gallery). Show current page and total count.

3. **Path controls: file hierarchy navigation.** macOS path controls display location within a directory structure and allow jumping to any ancestor.

4. **Search scopes narrow large result sets.** Provide scope buttons so users can filter without complex queries.

5. **Clear empty states for search.** Helpful message suggesting corrections or alternatives, not a blank screen.

6. **Page controls are not for hierarchical navigation.** Flat, linear sequences only. Use navigation controllers, tab bars, or sidebars for hierarchy.

7. **Keep path controls concise.** Show meaningful segments only. Users can click any segment to navigate directly.

8. **Support keyboard for search.** Command-F and system search shortcuts should activate search.

## Reference Index

| Reference | Topic | Key content |
|---|---|---|
| [search-fields.md](references/search-fields.md) | Search fields | Scopes, tokens, instant results, placement |
| [page-controls.md](references/page-controls.md) | Page controls | Dot indicators, flat page sequences |
| [path-controls.md](references/path-controls.md) | Path controls | Breadcrumbs, ancestor navigation |

## Output Format

1. **Component recommendation** -- search field, page control, or path control, and why.
2. **Behavior specification** -- interaction model (search-as-you-type, swipe for pages, click-to-navigate for paths).
3. **Platform differences** across iOS, iPadOS, macOS, visionOS.

## Questions to Ask

1. What type of content is being searched or navigated?
2. Which platforms?
3. How large is the dataset?
4. Is search the primary interaction?

## Related Skills

- **hig-components-menus** -- Toolbars and menu bars hosting search and navigation controls
- **hig-components-controls** -- Text fields, pickers, segmented controls in search interfaces
- **hig-components-dialogs** -- Popovers and sheets for expanded search or filtering
- **hig-patterns** -- Navigation patterns and information architecture
- **hig-foundations** -- Typography and layout for navigation components

---

*Built by [Raintree Technology](https://raintree.technology) · [More developer tools](https://raintree.technology)*

## When to Use
This skill is applicable to execute the workflow or actions described in the overview.

## Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.


---
name: hig-components-status
description: Apple HIG guidance for status and progress UI components including progress indicators, status bars, and activity rings.
risk: safe
source: community
date_added: '2026-02-27'
---

# Apple HIG: Status Components

Check for `.claude/apple-design-context.md` before asking questions. Use existing context and only ask for information not already covered.

## Key Principles

### Progress Indicators

1. **Show progress for operations longer than a second or two.**

2. **Determinate when duration/percentage is known.** A filling progress bar gives users a clear sense of remaining work. Use for downloads, uploads, or any measurable process.

3. **Indeterminate when duration is unknown.** A spinner communicates work is happening without promising a timeframe. Use for unpredictable network requests.

4. **Prefer progress bars over spinners.** Determinate progress feels faster and more trustworthy.

5. **Place indicators where content will appear.** Inline progress near the content area, not modal or distant.

6. **Don't stack multiple indicators.** Aggregate simultaneous operations into one representation or show the most relevant.

### Status Bars

7. **Don't hide the status bar without good reason.** Reserve hiding for immersive experiences (full-screen media, games, AR).

8. **Match status bar style to your content.** Light or dark for adequate contrast.

9. **Respect safe areas.** No interactive content behind the status bar.

10. **Restore promptly** when exiting immersive contexts.

### Activity Rings

11. **Activity rings are for Move, Exercise, and Stand goals.** Don't repurpose the ring metaphor for unrelated data.

12. **Respect ring color conventions.** Red (Move), green (Exercise), blue (Stand) are strongly associated with Apple Fitness.

13. **Use HealthKit APIs** for activity data rather than manual tracking.

14. **Celebrate completions** with animation and haptics when rings close.

## Reference Index

| Reference | Topic | Key content |
|---|---|---|
| [progress-indicators.md](references/progress-indicators.md) | Progress bars and spinners | Determinate, indeterminate, inline placement, duration |
| [status-bars.md](references/status-bars.md) | iOS/iPadOS status bar | System info, visibility, style, safe areas |
| [activity-rings.md](references/activity-rings.md) | watchOS activity rings | Move/Exercise/Stand, HealthKit, fitness tracking, color |

## Output Format

1. **Indicator type recommendation** with rationale (determinate vs indeterminate).
2. **Timing and animation guidance** -- duration thresholds, animation style, transitions.
3. **Accessibility** -- VoiceOver progress announcements, live region updates.
4. **Platform-specific behavior** across targeted platforms.

## Questions to Ask

1. Is the duration known or unknown?
2. Which platforms?
3. How long does the operation typically take?
4. System-level or in-app indicator?

## Related Skills

- **hig-components-system** -- Widgets and complications displaying progress or status
- **hig-inputs** -- Gestures triggering progress states (pull-to-refresh)
- **hig-technologies** -- HealthKit for activity ring data; VoiceOver for progress announcements

---

*Built by [Raintree Technology](https://raintree.technology) · [More developer tools](https://raintree.technology)*

## When to Use
This skill is applicable to execute the workflow or actions described in the overview.

## Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.


---
name: hig-components-system
description: 'Apple HIG guidance for system experience components: widgets, live activities, notifications, complications, home screen quick actions, top shelf, watch faces, app clips, and app shortcuts.'
risk: safe
source: community
date_added: '2026-02-27'
---

# Apple HIG: System Experiences

Check for `.claude/apple-design-context.md` before asking questions. Use existing context and only ask for information not already covered.

## Key Principles

### General

1. **Glanceable, immediate value.** System experiences bring your app's most important content to surfaces the user sees without launching your app. Design for seconds of attention.

2. **Respect platform context.** A Lock Screen widget has different constraints than a Home Screen widget. A complication is far smaller than a top shelf item.

### Widgets

3. **Show relevant information, not everything.** Display the most useful subset, updated appropriately.

4. **Support multiple sizes with distinct layouts.** Each size should be a thoughtful design, not a scaled version of another.

5. **Deep-link on tap.** Take users to the relevant content, not the app's root screen.

### Live Activities

6. **Track events with a clear start and end.** Deliveries, scores, timers, rides. Design for both Dynamic Island and Lock Screen.

7. **Stay updated and timely.** Stale data undermines trust. End promptly when the event concludes.

### Notifications

8. **Respect user attention.** Only send notifications for information users genuinely care about. No promotional or low-value notifications.

9. **Actionable and self-contained.** Include enough context to understand and act without opening the app. Support notification actions. Use threading and grouping.

### Complications

10. **Focused data on the watch face.** Design for the smallest useful representation. Support multiple families. Budget updates wisely.

### Home Screen Quick Actions

11. **3-4 most common tasks.** Short titles, optional subtitles, relevant SF Symbol icons.

### Top Shelf

12. **tvOS showcase.** Feature content that entices: new episodes, featured items, recent content.

### App Clips

13. **Instant, focused functionality within a strict size budget.** Load quickly without App Store download. Only what's needed for the immediate task, then offer full app install.

### App Shortcuts

14. **Surface key actions to Siri and Spotlight.** Define shortcuts for frequent tasks. Use natural, conversational trigger phrases.

## Reference Index

| Reference | Topic | Key content |
|---|---|---|
| [widgets.md](references/widgets.md) | Widgets | Glanceable info, sizes, deep linking, timeline |
| [live-activities.md](references/live-activities.md) | Live Activities | Real-time tracking, Dynamic Island, Lock Screen |
| [notifications.md](references/notifications.md) | Notifications | Attention, actions, grouping, content |
| [complications.md](references/complications.md) | Complications | Watch face data, families, budgeted updates |
| [home-screen-quick-actions.md](references/home-screen-quick-actions.md) | Quick actions | Haptic Touch, common tasks, SF Symbols |
| [top-shelf.md](references/top-shelf.md) | Top shelf | Featured content, showcase |
| [app-clips.md](references/app-clips.md) | App Clips | Instant use, lightweight, focused task, NFC/QR |
| [watch-faces.md](references/watch-faces.md) | Watch faces | Custom complications, face sharing |
| [app-shortcuts.md](references/app-shortcuts.md) | App Shortcuts | Siri, Spotlight, voice triggers |

## Output Format

1. **System experience recommendation** -- which surface best fits the use case.
2. **Content strategy** -- what to display, priority, what to omit.
3. **Update frequency** -- refresh rate including system budget constraints.
4. **Size/family variants** -- which to support and how layout adapts.
5. **Deep link behavior** -- where tapping takes the user.

## Questions to Ask

1. What information needs to surface outside the app?
2. Which platform?
3. How frequently does the data update?
4. What is the primary glanceable need?

## Related Skills

- **hig-components-status** -- Progress indicators in widgets or Live Activities
- **hig-inputs** -- Interaction patterns for system experiences (Digital Crown for complications)
- **hig-technologies** -- Siri for App Shortcuts, HealthKit for complications, NFC for App Clips

---

*Built by [Raintree Technology](https://raintree.technology) · [More developer tools](https://raintree.technology)*

## When to Use
This skill is applicable to execute the workflow or actions described in the overview.

## Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.


---
name: hig-foundations
description: Apple Human Interface Guidelines design foundations.
risk: none
source: community
date_added: '2026-02-27'
---

# Apple HIG: Design Foundations

Check for `.claude/apple-design-context.md` before asking questions. Use existing context and only ask for information not already covered.

## Key Principles

1. **Prioritize content over chrome.** Reduce visual clutter. Use system-provided materials and subtle separators rather than heavy borders and backgrounds.

2. **Build in accessibility from the start.** Design for VoiceOver, Dynamic Type, Reduce Motion, Increase Contrast, and Switch Control from day one. Every interactive element needs an accessible label.

3. **Use system colors and materials.** System colors adapt to light/dark mode, increased contrast, and vibrancy. Prefer semantic colors (`label`, `secondaryLabel`, `systemBackground`) over hard-coded values.

4. **Use platform fonts and icons.** SF Pro, SF Compact, SF Mono by default. New York for serif. Follow the type hierarchy at recommended sizes. Use SF Symbols for iconography.

5. **Match platform conventions.** Align look and behavior with system standards. Provide direct, responsive manipulation and clear feedback for every action.

6. **Respect privacy.** Request permissions only when needed, explain why clearly, provide value before asking for data. Design for minimal data collection.

7. **Support internationalization.** Accommodate text expansion, right-to-left scripts, and varying date/number formats. Use Auto Layout for dynamic content sizing.

8. **Use motion purposefully.** Animation should communicate meaning and spatial relationships. Honor Reduce Motion by providing crossfade alternatives.

## Reference Index

| Reference | Topic | Key content |
|---|---|---|
| [accessibility.md](references/accessibility.md) | Accessibility | VoiceOver, Dynamic Type, color contrast, motor accessibility, Switch Control, audio descriptions |
| [app-icons.md](references/app-icons.md) | App Icons | Icon grid, platform-specific sizes, single focal point, no transparency |
| [branding.md](references/branding.md) | Branding | Integrating brand identity within Apple's design language, subtle branding, custom tints |
| [color.md](references/color.md) | Color | System colors, Dynamic Colors, semantic colors, custom palettes, contrast ratios |
| [dark-mode.md](references/dark-mode.md) | Dark Mode | Elevated surfaces, semantic colors, adapted palettes, vibrancy, testing in both modes |
| [icons.md](references/icons.md) | Icons | Glyph icons, SF Symbols integration, custom icon design, icon weights, optical alignment |
| [images.md](references/images.md) | Images | Image resolution, @2x/@3x assets, vector assets, image accessibility |
| [immersive-experiences.md](references/immersive-experiences.md) | Immersive Experiences | AR/VR design, spatial immersion, comfort zones, progressive immersion levels |
| [inclusion.md](references/inclusion.md) | Inclusion | Diverse representation, non-gendered language, cultural sensitivity, inclusive defaults |
| [layout.md](references/layout.md) | Layout | Margins, spacing, alignment, safe areas, adaptive layouts, readable content guides |
| [materials.md](references/materials.md) | Materials | Vibrancy, blur, translucency, system materials, material thickness |
| [motion.md](references/motion.md) | Motion | Animation curves, transitions, continuity, Reduce Motion support, physics-based motion |
| [privacy.md](references/privacy.md) | Privacy | Permission requests, usage descriptions, privacy nutrition labels, minimal data collection |
| [right-to-left.md](references/right-to-left.md) | Right-to-Left | RTL layout mirroring, bidirectional text, icons that flip, exceptions |
| [sf-symbols.md](references/sf-symbols.md) | SF Symbols | Symbol categories, rendering modes, variable color, custom symbols, weight matching |
| [spatial-layout.md](references/spatial-layout.md) | Spatial Layout | visionOS window placement, depth, ergonomic zones, Z-axis design |
| [typography.md](references/typography.md) | Typography | SF Pro, Dynamic Type sizes, text styles, custom fonts, font weight hierarchy, line spacing |
| [writing.md](references/writing.md) | Writing | UI copy guidelines, tone, capitalization rules, error messages, button labels, conciseness |

## Applying Foundations Together

Consider how principles interact:

1. **Color + Dark Mode + Accessibility** -- Custom palettes must work in both modes while maintaining WCAG contrast ratios. Start with system semantic colors.

2. **Typography + Accessibility + Layout** -- Dynamic Type must scale without breaking layouts. Use text styles and Auto Layout for the full range of type sizes.

3. **Icons + Branding + SF Symbols** -- Custom icons should match SF Symbols weight and optical sizing. Brand elements should integrate without overriding system conventions.

4. **Motion + Accessibility + Feedback** -- Every animation must have a Reduce Motion alternative. Motion should reinforce spatial relationships, not decorate.

5. **Privacy + Writing + Onboarding** -- Permission requests need clear, specific usage descriptions. Time them to when the user will understand the benefit.

## Output Format

1. **Cite the specific HIG foundation** with file and section.
2. **Note platform differences** for the user's target platforms.
3. **Provide concrete code patterns** (SwiftUI/UIKit/AppKit).
4. **Explain accessibility impact** (contrast ratios, Dynamic Type scaling, VoiceOver behavior).

## Questions to Ask

1. Which platforms are you targeting?
2. Do you have existing brand guidelines?
3. What accessibility level are you targeting? (WCAG AA, AAA, Apple baseline?)
4. System colors or custom?

## Related Skills

- **hig-platforms** -- How foundations apply per platform (e.g., type scale differences on watchOS vs macOS)
- **hig-patterns** -- Interaction patterns where foundations like writing and accessibility are critical
- **hig-components-layout** -- Structural components implementing layout principles
- **hig-components-content** -- Content display using color, typography, and images

---

*Built by [Raintree Technology](https://raintree.technology) · [More developer tools](https://raintree.technology)*

## When to Use
This skill is applicable to execute the workflow or actions described in the overview.

## Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.


---
name: hig-inputs
description: "Check for .claude/apple-design-context.md before asking questions. Use existing context and only ask for information not already covered."
risk: none
source: community
date_added: '2026-02-27'
---

# Apple HIG: Inputs

Check for `.claude/apple-design-context.md` before asking questions. Use existing context and only ask for information not already covered.

## Key Principles

### General

1. **Support multiple input methods.** Touch, pointer, keyboard, pencil, voice, eyes, hands, controllers. Design for the inputs available on each platform. On iPadOS, support both touch and pointer; on macOS, both pointer and keyboard.

2. **Consistent feedback for every input action.** Visible, audible, or haptic response.

### Gestures

3. **Standard gestures must behave consistently.** Tap to activate, swipe to scroll/navigate, pinch to zoom, long press for context menus, drag to move. Don't override system gestures (edge swipes for back, Home, notifications).

4. **Use standard recognizers; keep custom gestures discoverable.** Apple's built-in recognizers handle edge cases and accessibility. If you add non-standard gestures, provide hints or coaching to teach them.

### Apple Pencil

5. **Precision drawing, markup, and selection.** Support pressure, tilt, and hover. Distinguish finger from Pencil when appropriate (finger pans, Pencil draws).

6. **Support Scribble in text fields.** Users expect to write with Pencil in any text input.

### Keyboards

7. **Keyboard shortcuts and full navigation.** Standard shortcuts (Cmd+C/V/Z) plus custom ones visible in the iPadOS Command key overlay. Logical tab order.

8. **Respect the software keyboard.** Adjust layout when keyboard appears. Use keyboard-avoidance APIs.

### Game Controllers

9. **MFi controllers with on-screen fallbacks.** Map to extended gamepad profile, sensible defaults, remappable. Always offer touch or keyboard alternatives.

### Pointer and Trackpad

10. **Native feel.** Hover effects, pointer shape adaptation, standard cursor behaviors. Two-finger scroll, pinch to zoom, swipe to navigate.

### Digital Crown

11. **Primary scrolling and value-adjustment input on watchOS.** Scrolling lists, adjusting values, navigating views. Haptic feedback at detents.

### Eyes and Spatial (visionOS)

12. **Look and pinch.** Generous hit targets (eye tracking is less precise than touch). Avoid sustained gaze for activation. Direct hand manipulation in immersive experiences.

### Focus System

13. **Critical for tvOS and visionOS.** Predictable focus movement. Every interactive element focusable. Clear visual indicators (scale, highlight, elevation). Logical focus groups.

### Remotes

14. **Siri Remote: limited surface.** Touch area for swiping, clickpad for selection, few physical buttons. Keep interactions simple.

### Motion and Nearby

15. **Gyroscope, accelerometer, UWB: use judiciously.** Suits gaming, fitness, AR. Not for essential tasks. Provide calibration and reset. For UWB, communicate distance and direction with visual or haptic cues.

## Reference Index

| Reference | Topic | Key content |
|---|---|---|
| [gestures.md](references/gestures.md) | Touch gestures | Tap, swipe, pinch, long press, drag, system gestures |
| [apple-pencil-and-scribble.md](references/apple-pencil-and-scribble.md) | Apple Pencil | Precision, pressure, tilt, hover, handwriting |
| [keyboards.md](references/keyboards.md) | Keyboards | Shortcuts, navigation, software keyboard, Command key |
| [game-controls.md](references/game-controls.md) | Game controllers | MFi, extended gamepad, remapping, fallbacks |
| [pointing-devices.md](references/pointing-devices.md) | Pointer/trackpad | Hover, cursor morphing, trackpad gestures |
| [digital-crown.md](references/digital-crown.md) | Digital Crown | Scrolling, value adjustment, haptic detents |
| [eyes.md](references/eyes.md) | Eye tracking | Look and tap, gaze targeting, hit target sizing |
| [spatial-interactions.md](references/spatial-interactions.md) | Spatial input | Hand gestures, direct manipulation, immersive input |
| [focus-and-selection.md](references/focus-and-selection.md) | Focus system | tvOS/visionOS navigation, focus indicators, groups |
| [remotes.md](references/remotes.md) | Remotes | Touch surface, clickpad, simple interactions |
| [gyro-and-accelerometer.md](references/gyro-and-accelerometer.md) | Motion sensors | Gyroscope, accelerometer, calibration, gaming |
| [nearby-interactions.md](references/nearby-interactions.md) | Nearby interactions | U1 chip, directional finding, proximity triggers |
| [camera-control.md](references/camera-control.md) | Camera Control | iPhone camera hardware button, quick launch |

## Output Format

1. **Input method recommendations by platform** and how they interact.
2. **Gesture specification table** -- standard and custom gestures with expected behaviors.
3. **Keyboard shortcut recommendations** following system conventions.
4. **Accessibility input alternatives** for VoiceOver, Switch Control, etc.

## Questions to Ask

1. Which platforms and input devices?
2. Productivity or casual app?
3. Custom gestures in the design?
4. Game controller support needed?

## Related Skills

- **hig-components-status** -- Progress indicators responding to input (pull-to-refresh)
- **hig-components-system** -- System experiences with unique input constraints
- **hig-technologies** -- VoiceOver, Siri voice input, ARKit spatial gesture context

---

*Built by [Raintree Technology](https://raintree.technology) · [More developer tools](https://raintree.technology)*

## When to Use
This skill is applicable to execute the workflow or actions described in the overview.

## Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.


---
name: hig-patterns
description: Apple Human Interface Guidelines interaction and UX patterns.
risk: none
source: community
date_added: '2026-02-27'
---

# Apple HIG: Interaction Patterns

Check for `.claude/apple-design-context.md` before asking questions. Use existing context and only ask for information not already covered.

## Key Principles

1. **Minimize modality.** Use modality only when it is critical to get attention, a task must be completed or abandoned, or saving changes is essential. Prefer non-modal alternatives.

2. **Provide clear feedback.** Every action should produce visible, audible, or haptic response. Activity indicators for indeterminate waits, progress bars for determinate, haptics for physical confirmation.

3. **Support undo over confirmation dialogs.** Destructive actions should be reversible when possible. Undo is almost always better than "Are you sure?"

4. **Launch quickly.** Display a launch screen that transitions seamlessly into the first screen. No splash screens with logos. Restore previous state.

5. **Defer sign-in.** Let users explore before requiring account creation. Support Sign in with Apple and passkeys.

6. **Keep onboarding brief.** Three screens max. Let users skip. Teach through progressive disclosure and contextual hints.

7. **Use progressive disclosure.** Show essentials first, let users drill into details. Don't overwhelm with every option on one screen.

8. **Respect user attention.** Consolidate notifications, minimize interruptions, give users control over alerts. Never use notifications for marketing.

## Reference Index

| Reference | Topic | Key content |
|---|---|---|
| [charting-data.md](references/charting-data.md) | Charting Data | Data visualization patterns, accessible charts, interactive elements |
| [collaboration-and-sharing.md](references/collaboration-and-sharing.md) | Collaboration & Sharing | Share sheets, activity views, collaborative editing, SharePlay |
| [drag-and-drop.md](references/drag-and-drop.md) | Drag and Drop | Drag sources, drop targets, spring loading, multi-item drag, visual feedback |
| [entering-data.md](references/entering-data.md) | Entering Data | Text fields, pickers, steppers, input validation, keyboard types, autofill |
| [feedback.md](references/feedback.md) | Feedback | Alerts, action sheets, haptic patterns, sound feedback, visual indicators |
| [file-management.md](references/file-management.md) | File Management | Document browser, file providers, iCloud integration, document lifecycle |
| [going-full-screen.md](references/going-full-screen.md) | Going Full Screen | Full-screen transitions, immersive content, exiting full screen |
| [launching.md](references/launching.md) | Launching | Launch screens, state restoration, cold vs warm launch |
| [live-viewing-apps.md](references/live-viewing-apps.md) | Live Viewing Apps | Live content display, real-time updates, Live Activities, Dynamic Island |
| [loading.md](references/loading.md) | Loading | Activity indicators, progress views, skeleton screens, lazy loading, placeholders |
| [managing-accounts.md](references/managing-accounts.md) | Managing Accounts | Sign in with Apple, passkeys, account creation, credential autofill, account deletion |
| [managing-notifications.md](references/managing-notifications.md) | Managing Notifications | Permission requests, grouping, actionable notifications, provisional delivery |
| [modality.md](references/modality.md) | Modality | Sheets, alerts, popovers, full-screen modals, when to use each |
| [multitasking.md](references/multitasking.md) | Multitasking | iPad Split View, Slide Over, Stage Manager, responsive layout, size class transitions |
| [offering-help.md](references/offering-help.md) | Offering Help | Contextual tips, onboarding hints, help menus, support links |
| [onboarding.md](references/onboarding.md) | Onboarding | Welcome screens, feature highlights, progressive onboarding, skip options |
| [playing-audio.md](references/playing-audio.md) | Playing Audio | Audio sessions, background audio, Now Playing, audio routing, interruptions |
| [playing-haptics.md](references/playing-haptics.md) | Playing Haptics | Core Haptics, UIFeedbackGenerator, haptic patterns, custom haptics |
| [playing-video.md](references/playing-video.md) | Playing Video | Video player controls, picture-in-picture, AirPlay, full-screen video |
| [printing.md](references/printing.md) | Printing | Print dialogs, page setup, AirPrint integration |
| [ratings-and-reviews.md](references/ratings-and-reviews.md) | Ratings & Reviews | SKStoreReviewController, timing, frequency limits, in-app feedback |
| [searching.md](references/searching.md) | Searching | Search bars, suggestions, scoped search, results display, recents |
| [settings.md](references/settings.md) | Settings | In-app vs Settings app, preference organization, toggles, defaults |
| [undo-and-redo.md](references/undo-and-redo.md) | Undo and Redo | Shake to undo, undo/redo stack, multi-level undo |
| [workouts.md](references/workouts.md) | Workouts | Workout sessions, live metrics, Always On display, summaries, HealthKit |

## Pattern Selection Guide

| User Goal | Recommended Pattern | Avoid |
|---|---|---|
| First app experience | Brief onboarding (max 3 screens) + progressive disclosure | Long tutorials, mandatory sign-up |
| Waiting for content | Skeleton screens or progress indicators | Blocking spinners with no context |
| Confirming destructive action | Undo support | Excessive "Are you sure?" dialogs |
| Collecting user input | Inline validation, smart defaults, autofill | Modal forms for simple inputs |
| Requesting permissions | Contextual, just-in-time with explanation | Requesting all permissions at launch |
| Providing feedback | Haptics + visual indicator | Silent actions with no confirmation |
| Organizing preferences | In-app settings for frequent items | Burying all settings in system Settings app |

## Output Format

1. **Recommended pattern with rationale**, citing the relevant reference file.
2. **Step-by-step implementation** covering each screen or state.
3. **Platform variations** for targeted platforms.
4. **Common pitfalls** that violate HIG for this pattern.

## Questions to Ask

1. Where in the app does this pattern appear? What comes before and after?
2. Which platforms?
3. Designing from scratch or improving an existing flow?
4. Does this involve sensitive actions? (Destructive operations, payments, permissions)

## Related Skills

- **hig-foundations** -- Accessibility, color, typography, and privacy principles underlying every pattern
- **hig-platforms** -- Platform-specific pattern implementations
- **hig-components-layout** -- Structural components (tab bars, sidebars, split views) for navigation patterns
- **hig-components-content** -- Content display within patterns (charts, collections, search results)

---

*Built by [Raintree Technology](https://raintree.technology) · [More developer tools](https://raintree.technology)*

## When to Use
This skill is applicable to execute the workflow or actions described in the overview.

## Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.


---
name: hig-platforms
description: Apple Human Interface Guidelines for platform-specific design.
risk: safe
source: community
date_added: '2026-02-27'
---

# Apple HIG: Platform Design

Check for `.claude/apple-design-context.md` before asking questions. Use existing context and only ask for information not already covered.

## Key Principles

1. **Each platform has a distinct identity.** Do not port designs between platforms. Respect each platform's conventions, interaction models, and user expectations.

2. **iOS: touch-first.** Direct manipulation on a handheld screen. Optimize for one-handed use. Navigation uses tab bars and push/pop stacks.

3. **iPadOS: expanded canvas.** Support Split View, Slide Over, and Stage Manager. Use sidebars and multi-column layouts. Support pointer and keyboard alongside touch.

4. **macOS: pointer and keyboard.** Dense information display is acceptable. Use menu bars, toolbars, and keyboard shortcuts extensively. Windows are resizable with precise control.

5. **tvOS: remote and focus.** Viewed from a distance. Design for the Siri Remote with focus-based navigation. Large text, simple layouts, linear navigation.

6. **visionOS: spatial interaction.** 3D environment using windows, volumes, and spaces. Eye tracking for targeting, indirect gestures for interaction. Respect ergonomic comfort zones.

7. **watchOS: glanceable and brief.** Information consumable at a glance. Brief interactions. Digital Crown, haptics, and complications for timely content.

8. **Games: own paradigm.** Free to define in-game interaction models, but still respect platform conventions for system interactions (notifications, accessibility, controllers).

## Reference Index

| Reference | Topic | Key content |
|---|---|---|
| [designing-for-ios.md](references/designing-for-ios.md) | iOS | Touch, tab bars, navigation stacks, gestures, screen sizes, safe areas |
| [designing-for-ipados.md](references/designing-for-ipados.md) | iPadOS | Multitasking, sidebars, pointer, keyboard, Apple Pencil, Stage Manager |
| [designing-for-macos.md](references/designing-for-macos.md) | macOS | Menu bars, toolbars, window management, keyboard shortcuts, dense layouts, Dock |
| [designing-for-tvos.md](references/designing-for-tvos.md) | tvOS | Focus engine, Siri Remote, lean-back experience, content-forward, parallax |
| [designing-for-visionos.md](references/designing-for-visionos.md) | visionOS | Spatial computing, windows/volumes/spaces, eye tracking, hand gestures, depth |
| [designing-for-watchos.md](references/designing-for-watchos.md) | watchOS | Glanceable UI, Digital Crown, complications, notifications, haptics |
| [designing-for-games.md](references/designing-for-games.md) | Games | Controllers, immersive experiences, platform-specific conventions, accessibility |

## Decision Framework

1. **Identify the primary use context.** On the go (iOS/watchOS), at a desk (macOS), on the couch (tvOS), spatial environment (visionOS)?

2. **Match input to interaction.** Touch for direct manipulation, pointer for precision, gaze+gesture for spatial, Digital Crown for quick scrolling, remote for focus navigation.

3. **Adapt, don't replicate.** A macOS sidebar becomes a tab bar on iPhone. A visionOS volume has no equivalent on watchOS. Translate intent, not implementation.

4. **Leverage platform strengths.** Live Activities on iOS, Desktop Widgets on macOS, complications on watchOS, immersive spaces on visionOS.

5. **Maintain brand consistency** while respecting each platform's visual language and interaction patterns.

## Output Format

1. **Platform-specific recommendations** citing relevant HIG sections.
2. **Platform differences table** comparing navigation, input, layout, and conventions.
3. **Implementation notes** per platform including recommended APIs and adaptation strategies.

## Questions to Ask

1. Which platforms are you targeting?
2. New app or adapting an existing one? If existing, which platform is the base?
3. SwiftUI or UIKit/AppKit?
4. Need to support older OS versions?
5. Primary use context? (On the go, desk, couch, spatial, glanceable?)

## Related Skills

- **hig-foundations** -- Shared principles (color, typography, accessibility, layout) across platforms
- **hig-patterns** -- Interaction patterns that manifest differently per platform
- **hig-components-layout** -- Navigation structures (tab bars, sidebars, split views) that vary by platform
- **hig-components-content** -- Content display that adapts across platforms

---

*Built by [Raintree Technology](https://raintree.technology) · [More developer tools](https://raintree.technology)*

## When to Use
This skill is applicable to execute the workflow or actions described in the overview.

## Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.


---
name: hig-project-context
description: Create or update a shared Apple design context document that other HIG skills use to tailor guidance.
risk: critical
source: community
date_added: '2026-02-27'
---

# Apple HIG: Project Context

Create and maintain `.claude/apple-design-context.md` so other HIG skills can skip redundant questions.

Check for `.claude/apple-design-context.md` before asking questions. Use existing context and only ask for information not already covered.

## Gathering Context

Before asking questions, auto-discover context from:

1. **README.md** -- Product description, platform targets
2. **Package.swift / .xcodeproj** -- Supported platforms, minimum OS versions, dependencies
3. **Info.plist** -- App category, required capabilities, supported orientations
4. **Existing code** -- Import statements reveal frameworks (SwiftUI vs UIKit, HealthKit, etc.)
5. **Assets.xcassets** -- Color assets, icon sets, dark mode variants
6. **Accessibility audit** -- Grep for accessibility modifiers/attributes

Present findings and ask the user to confirm or correct. Then gather anything still missing:

### 1. Product Overview
- What does the app do? (one sentence)
- Category (productivity, social, health, game, utility, etc.)
- Stage (concept, development, shipped, redesign)

### 2. Target Platforms
- Which Apple platforms? (iOS, iPadOS, macOS, tvOS, watchOS, visionOS)
- Minimum OS versions
- Universal or platform-specific?

### 3. Technology Stack
- UI framework: SwiftUI, UIKit, AppKit, or mixed?
- Architecture: single-window, multi-window, document-based?
- Apple technologies in use? (HealthKit, CloudKit, ARKit, etc.)

### 4. Design System
- System defaults or custom design system?
- Brand colors, fonts, icon style?
- Dark mode and Dynamic Type support status

### 5. Accessibility Requirements
- Target level (baseline, enhanced, comprehensive)
- Specific considerations (VoiceOver, Switch Control, etc.)
- Regulatory requirements (WCAG, Section 508)

### 6. User Context
- Primary personas (1-3)
- Key use cases and environments (desk, on-the-go, glanceable, immersive)
- Known pain points or design challenges

### 7. Existing Design Assets
- Figma/Sketch files?
- Apple Design Resources in use?
- Existing component library?

## Context Document Template

Generate `.claude/apple-design-context.md` using this structure:

```markdown
# Apple Design Context

## Product
- **Name**: [App name]
- **Description**: [One sentence]
- **Category**: [Category]
- **Stage**: [Concept / Development / Shipped / Redesign]

## Platforms
| Platform | Supported | Min OS | Notes |
|----------|-----------|--------|-------|
| iOS      | Yes/No    |        |       |
| iPadOS   | Yes/No    |        |       |
| macOS    | Yes/No    |        |       |
| tvOS     | Yes/No    |        |       |
| watchOS  | Yes/No    |        |       |
| visionOS | Yes/No    |        |       |

## Technology
- **UI Framework**: [SwiftUI / UIKit / AppKit / Mixed]
- **Architecture**: [Single-window / Multi-window / Document-based]
- **Apple Technologies**: [List any: HealthKit, CloudKit, ARKit, etc.]

## Design System
- **Base**: [System defaults / Custom design system]
- **Brand Colors**: [List or reference]
- **Typography**: [System fonts / Custom fonts]
- **Dark Mode**: [Supported / Not yet / N/A]
- **Dynamic Type**: [Supported / Not yet / N/A]

## Accessibility
- **Target Level**: [Baseline / Enhanced / Comprehensive]
- **Key Considerations**: [List any specific needs]

## Users
- **Primary Persona**: [Description]
- **Key Use Cases**: [List]
- **Known Challenges**: [List]
```

## Updating Context

When updating an existing context document:

1. Read the current `.claude/apple-design-context.md`
2. Ask what has changed
3. Update only the changed sections
4. Preserve all unchanged information

## Related Skills

- **hig-platforms** -- Platform-specific guidance
- **hig-foundations** -- Color, typography, layout decisions
- **hig-patterns** -- UX pattern recommendations
- **hig-components-*** -- Component recommendations
- **hig-inputs** -- Input method coverage
- **hig-technologies** -- Apple technology relevance

---

*Built by [Raintree Technology](https://raintree.technology) · [More developer tools](https://raintree.technology)*

## When to Use
This skill is applicable to execute the workflow or actions described in the overview.

## Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.


---
name: hig-technologies
description: "Check for .claude/apple-design-context.md before asking questions. Use existing context and only ask for information not already covered."
risk: safe
source: community
date_added: '2026-02-27'
---

# Apple HIG: Technologies

Check for `.claude/apple-design-context.md` before asking questions. Use existing context and only ask for information not already covered.

## Key Principles

### General

1. **Apple technologies extend app capabilities through system integration.** Each technology has established user-facing patterns; deviating creates confusion and erodes trust.

2. **Privacy and user control are paramount.** Especially for health, payment, and identity technologies. Request only needed data, explain why, respect choices.

### Siri and Voice

3. **Natural, predictable, recoverable.** Clear conversational intent phrases that complete quickly and confirm results. Support App Shortcuts for proactive suggestions. Handle errors with clear fallbacks.

### Payments and Commerce

4. **Transparent and frictionless.** Standard Apple Pay button styles. Never ask for card details when Apple Pay is available. Clearly describe what the user is buying, the price, and whether it's one-time or subscription.

### Health and Fitness

5. **Health data is deeply personal.** Explain the health benefit before requesting access. CareKit tasks should be encouraging. ResearchKit consent flows must be thorough, readable, and respect autonomy.

### Smart Home

6. **Simple and reliable.** Immediate response when controlling devices. Clear device state. Graceful handling of connectivity issues.

### Augmented Reality

7. **Genuine value, not gimmicks.** Use AR when spatial context improves understanding. Guide setup (surface, lighting, space). Provide clear exit back to standard interaction.

### Machine Learning and Generative AI

8. **Enhance without surprising.** Smart suggestions, image recognition, text prediction. Clearly attribute AI-generated content. Controls to edit, regenerate, or dismiss. Let users correct mistakes.

### Identity and Authentication

9. **Sign in with Apple as top option.** Standard button styles. Respect email hiding preference. ID Verifier: guided flows, don't store sensitive data beyond what verification requires.

### Cloud and Data

10. **Invisible and reliable sync.** Data appears on all devices without manual intervention. Handle conflicts gracefully. Never lose data.

### Shared Experiences

11. **Real-time participation.** SharePlay: support multiple participants, show presence, handle latency. AirPlay: appropriate Now Playing metadata.

### Automotive

12. **Driver safety first.** Minimize interaction complexity, large touch targets, no distracting content. Only permitted app types: audio, messaging, EV charging, navigation, parking, quick food ordering.

### Accessibility

13. **Baseline requirement.** Every element has a meaningful VoiceOver label, trait, and action. Support Dynamic Type, Switch Control, and other assistive technologies. Test entirely with VoiceOver enabled.

## Reference Index

| Reference | Topic | Key content |
|---|---|---|
| [siri.md](references/siri.md) | Siri | Intents, shortcuts, voice interaction, App Shortcuts |
| [apple-pay.md](references/apple-pay.md) | Apple Pay | Payment buttons, checkout flow, security |
| [tap-to-pay-on-iphone.md](references/tap-to-pay-on-iphone.md) | Tap to Pay | Merchant flows, contactless payment |
| [in-app-purchase.md](references/in-app-purchase.md) | In-app purchase | Subscriptions, one-time purchases, transparency |
| [healthkit.md](references/healthkit.md) | HealthKit | Health data access, privacy, permissions |
| [carekit.md](references/carekit.md) | CareKit | Care plans, tasks, health management |
| [researchkit.md](references/researchkit.md) | ResearchKit | Studies, informed consent, data collection |
| [homekit.md](references/homekit.md) | HomeKit | Smart home control, device state, scenes |
| [augmented-reality.md](references/augmented-reality.md) | ARKit | Spatial context, surface detection, setup |
| [machine-learning.md](references/machine-learning.md) | Core ML | Predictions, smart features, confidence handling |
| [generative-ai.md](references/generative-ai.md) | Generative AI | Attribution, editing, responsible AI, uncertainty |
| [icloud.md](references/icloud.md) | iCloud | CloudKit, cross-device sync, conflict resolution |
| [sign-in-with-apple.md](references/sign-in-with-apple.md) | Sign in with Apple | Authentication, privacy, button styles |
| [id-verifier.md](references/id-verifier.md) | ID Verifier | Identity verification, document scanning |
| [shareplay.md](references/shareplay.md) | SharePlay | Shared experiences, participant presence |
| [airplay.md](references/airplay.md) | AirPlay | Media streaming, Now Playing, wireless display |
| [carplay.md](references/carplay.md) | CarPlay | Driver safety, permitted app types, large targets |
| [game-center.md](references/game-center.md) | Game Center | Achievements, leaderboards, multiplayer |
| [voiceover.md](references/voiceover.md) | VoiceOver | Screen reader, labels, traits, accessibility |
| [wallet.md](references/wallet.md) | Wallet | Passes, tickets, loyalty cards |
| [nfc.md](references/nfc.md) | NFC | Tag reading, quick interactions, App Clips |
| [maps.md](references/maps.md) | Maps | Location display, annotations, directions |
| [mac-catalyst.md](references/mac-catalyst.md) | Mac Catalyst | iPad to Mac, menu bar, keyboard, pointer |
| [live-photos.md](references/live-photos.md) | Live Photos | Motion capture, playback, editing |
| [imessage-apps-and-stickers.md](references/imessage-apps-and-stickers.md) | iMessage apps | Messages extension, stickers, compact UI |
| [shazamkit.md](references/shazamkit.md) | ShazamKit | Audio recognition, music identification |
| [always-on.md](references/always-on.md) | Always-on display | Dimmed state, power efficiency, reduced updates |
| [photo-editing.md](references/photo-editing.md) | Photo editing | System photo editor, filters, adjustments |

## Output Format

1. **Implementation checklist** -- step-by-step requirements per Apple's guidelines.
2. **Required vs optional features** for approval.
3. **Privacy and permission requirements** -- data access, usage descriptions.
4. **User-facing flow** from permission prompt through task completion.
5. **Testing guidance** -- key scenarios including edge cases.

## Questions to Ask

1. Which Apple technology?
2. Core use case?
3. Which platforms?
4. API requirements and entitlements reviewed?
5. What data or permissions needed?

## Related Skills

- **hig-inputs** -- Input methods interacting with technologies (voice for Siri, Pencil for AR, gestures for Maps)
- **hig-components-system** -- Widgets, complications, Live Activities surfacing technology data
- **hig-components-status** -- Progress indicators for technology operations (sync, payment, AR loading)

---

*Built by [Raintree Technology](https://raintree.technology) · [More developer tools](https://raintree.technology)*

## When to Use
This skill is applicable to execute the workflow or actions described in the overview.

## Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.


---
name: high-contrast
description: Web and App implementation guide for High Contrast Design. Trigger when user wants accessibility-focused design, extreme legibility, or stark visual impact.
date_added: "2026-06-17"
risk: safe
source: self
source_type: self
---

# High Contrast Design

> "Maximum legibility. Stark, powerful, and universally accessible."

## When to Use
Use this sub-style when the user's request matches the aesthetic described above. This is a child reference of the `design-it` skill and is not meant to be triggered directly.

## Core Principles
1. **WCAG AAA Compliance**: Every color pairing must exceed a 7:1 contrast ratio.
2. **Clear Boundaries**: Interactive elements have highly visible borders and focus states.
3. **No Ambiguity**: Avoid subtle greys, low-opacity text, or purely decorative elements that distract from the core content.

## Visual DNA
- **Colors**: **Industrial Chic** (Black and White) or **Modern Editorial**. Often uses a single, highly luminous accent color (like pure Yellow `#FFFF00` or Cyan `#00FFFF`) against black.
- **Typography**: Highly legible, robust sans-serifs (`Atkinson Hyperlegible`, `Inter`, `Roboto`). Large base font sizes (18px+).
- **Styling**: Solid 2px borders around cards and buttons. Avoid drop shadows as they reduce edge clarity.

## Web Implementation
- Focus heavily on focus states (`:focus-visible`) and clear active states.
- **CSS Example**:
```css
:root {
  --hc-bg: #ffffff;
  --hc-text: #000000;
  --hc-accent: #0000FF; /* Pure blue */
  --hc-focus: #FF00FF; /* High visibility focus ring */
}

body {
  background-color: var(--hc-bg);
  color: var(--hc-text);
  font-family: 'Atkinson Hyperlegible', sans-serif;
  font-size: 18px; /* Larger default */
}

.hc-card {
  background-color: #ffffff;
  border: 3px solid #000000; /* Unmissable boundary */
  padding: 32px;
  border-radius: 8px;
}

.hc-btn {
  background-color: var(--hc-accent);
  color: #ffffff;
  border: 3px solid transparent; /* Reserve space for focus */
  border-radius: 4px;
  padding: 16px 32px;
  font-weight: 700;
  font-size: 1.1rem;
  cursor: pointer;
}

/* Crucial for high contrast / accessibility */
.hc-btn:focus-visible, a:focus-visible {
  outline: 4px solid var(--hc-focus);
  outline-offset: 4px;
}

a {
  color: var(--hc-accent);
  text-decoration: underline;
  text-decoration-thickness: 2px;
}
```

## App Implementation

### SwiftUI
```swift
struct HighContrastView: View {
    var body: some View {
        VStack(spacing: 32) {
            // High Contrast Card
            VStack(alignment: .leading, spacing: 16) {
                Text("Maximum Legibility")
                    .font(.custom("Atkinson Hyperlegible", size: 24))
                    .fontWeight(.bold)
                    .foregroundColor(.black)

                Text("Content is king. Borders are stark. Contrast ratios exceed 7:1.")
                    .font(.custom("Atkinson Hyperlegible", size: 18))
                    .foregroundColor(.black)
            }
            .padding(32)
            .background(Color.white)
            .overlay(
                RoundedRectangle(cornerRadius: 8)
                    .stroke(Color.black, lineWidth: 3)
            )

            // High Contrast Action Button
            Button(action: {}) {
                Text("CONFIRM ACTION")
                    .font(.custom("Atkinson Hyperlegible", size: 18))
                    .fontWeight(.black)
                    .foregroundColor(.white)
                    .padding(.vertical, 16)
                    .padding(.horizontal, 32)
                    .background(Color.blue) // Must be a high-contrast blue, e.g., #0000FF
                    .cornerRadius(4)
            }
        }
        .padding()
        .frame(maxWidth: .infinity, maxHeight: .infinity)
        .background(Color.white)
    }
}
```
- Rely on thick `.stroke(Color.black, lineWidth: 3)` overlays.
- Ensure text is pure `.black` on pure `.white`. Do not use `.secondary` colors if they drop below a 7:1 contrast ratio.
- Use fonts specifically designed for legibility, like Atkinson Hyperlegible.

### Flutter
```dart
class HighContrastScreen extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      backgroundColor: Colors.white,
      body: Center(
        child: Padding(
          padding: const EdgeInsets.all(24.0),
          child: Column(
            mainAxisAlignment: MainAxisAlignment.center,
            children: [
              // High Contrast Card
              Container(
                width: double.infinity,
                padding: const EdgeInsets.all(32),
                decoration: BoxDecoration(
                  color: Colors.white,
                  borderRadius: BorderRadius.circular(8),
                  border: Border.all(color: Colors.black, width: 3), // Unmissable boundary
                ),
                child: Column(
                  crossAxisAlignment: CrossAxisAlignment.start,
                  children: const [
                    Text('Maximum Legibility',
                      style: TextStyle(fontFamily: 'Atkinson', fontSize: 24, fontWeight: FontWeight.bold, color: Colors.black)),
                    SizedBox(height: 16),
                    Text('Content is king. Borders are stark. Contrast ratios exceed 7:1.',
                      style: TextStyle(fontFamily: 'Atkinson', fontSize: 18, color: Colors.black)),
                  ],
                ),
              ),
              const SizedBox(height: 32),

              // High Contrast Button
              ElevatedButton(
                onPressed: () {},
                style: ElevatedButton.styleFrom(
                  backgroundColor: const Color(0xFF0000FF), // Pure blue
                  foregroundColor: Colors.white,
                  padding: const EdgeInsets.symmetric(horizontal: 32, vertical: 16),
                  shape: RoundedRectangleBorder(borderRadius: BorderRadius.circular(4)),
                  elevation: 0, // No shadows
                ),
                child: const Text('CONFIRM ACTION',
                  style: TextStyle(fontFamily: 'Atkinson', fontSize: 18, fontWeight: FontWeight.w900)),
              ),
            ],
          ),
        ),
      ),
    );
  }
}
```
- Disable `elevation` on buttons; shadows blur the edges and reduce contrast.
- Use `Border.all(color: Colors.black, width: 3)` on containers to explicitly define spatial boundaries for users with low vision.

### React Native
```jsx
const HighContrastScreen = () => {
  return (
    <View style={{ flex: 1, backgroundColor: '#FFFFFF', padding: 24, justifyContent: 'center' }}>

      {/* High Contrast Card */}
      <View style={{
        backgroundColor: '#FFFFFF',
        borderColor: '#000000',
        borderWidth: 3,
        borderRadius: 8,
        padding: 32,
        marginBottom: 32
      }}>
        <Text style={{ fontFamily: 'Atkinson-Bold', fontSize: 24, color: '#000000', marginBottom: 16 }}>
          Maximum Legibility
        </Text>
        <Text style={{ fontFamily: 'Atkinson-Regular', fontSize: 18, color: '#000000' }}>
          Content is king. Borders are stark. Contrast ratios exceed 7:1.
        </Text>
      </View>

      {/* High Contrast Button */}
      <TouchableOpacity style={{
        backgroundColor: '#0000FF',
        paddingVertical: 16,
        paddingHorizontal: 32,
        borderRadius: 4,
        alignItems: 'center'
      }}>
        <Text style={{ fontFamily: 'Atkinson-Bold', fontSize: 18, color: '#FFFFFF', fontWeight: '900' }}>
          CONFIRM ACTION
        </Text>
      </TouchableOpacity>

    </View>
  );
};
```
- In React Native, accessibility relies heavily on high contrast. Ensure `borderWidth: 3` and explicit pure `#000000` text colors.
- Make sure to use accessible `<TouchableOpacity>` areas (minimum 48x48 padding for hit slop).

### Jetpack Compose
```kotlin
@Composable
fun HighContrastScreen() {
    Column(
        modifier = Modifier
            .fillMaxSize()
            .background(Color.White)
            .padding(24.dp),
        verticalArrangement = Arrangement.Center
    ) {
        // High Contrast Card
        Box(
            modifier = Modifier
                .fillMaxWidth()
                .background(Color.White, RoundedCornerShape(8.dp))
                .border(3.dp, Color.Black, RoundedCornerShape(8.dp))
                .padding(32.dp)
        ) {
            Column {
                Text(
                    text = "Maximum Legibility",
                    fontSize = 24.sp,
                    fontWeight = FontWeight.Bold,
                    color = Color.Black
                )
                Spacer(Modifier.height(16.dp))
                Text(
                    text = "Content is king. Borders are stark. Contrast ratios exceed 7:1.",
                    fontSize = 18.sp,
                    color = Color.Black
                )
            }
        }

        Spacer(Modifier.height(32.dp))

        // High Contrast Button
        Button(
            onClick = { },
            colors = ButtonDefaults.buttonColors(
                containerColor = Color(0xFF0000FF),
                contentColor = Color.White
            ),
            shape = RoundedCornerShape(4.dp),
            elevation = null, // Disable shadows for stark look
            modifier = Modifier.fillMaxWidth().height(56.dp)
        ) {
            Text("CONFIRM ACTION", fontSize = 18.sp, fontWeight = FontWeight.Black)
        }
    }
}
```
- Use `Modifier.border(3.dp, Color.Black)` around containers.
- Disable button elevations (`elevation = null`) to keep the design perfectly flat and sharp.

## Do's and Don'ts
- **DO**: Run your colors through a contrast checker. If it's below 7:1, adjust it.
- **DON'T**: Rely on color alone to convey meaning (e.g., don't just make an error state red; make it red AND add an error icon AND bold the text).

## Limitations
- This is a styling reference and does not replace environment-specific validation, accessibility testing, or expert review.
- Ensure appropriate contrast ratios and responsive behaviors are verified separately.