# Swiftui Component Author

> Use when creating or refactoring a reusable SwiftUI component. Do not use for business-specific screens, non-UI services, or design-token-only changes.

- Skill: `brbndon/swiftui-component-author` (Agent Skill)
- Install (CLI): `npx skillmds@latest add brbndon/swiftui-component-author`
- Raw SKILL.md: https://api.skillmd.com/api/skills/brbndon/swiftui-component-author/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: brbndon (https://skillmd.com/u/brbndon)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/brbndon/swiftui-component-author

---


# SwiftUI component author

Create or refactor a **reusable** SwiftUI component in the **consumer workspace**. Do not implement business-specific screens or token-only design work with this skill.

## Workflow

1. **Confirm scope.** Name the responsibility, at least two plausible consumers, supported platforms, and the configuration surface (parameters, styles, sizes). Stop if the request is a one-off screen, feature flow, or design-token-only change — use the appropriate feature or `apple-design-system` skill instead.
2. **Inspect first.** Read existing design-system tokens, sibling components, and repository UI conventions. Prefer extending an existing component over forking a near-duplicate.
3. **Prefer native controls.** Use system controls and semantic configuration. Avoid custom chrome that reimplements buttons, lists, or navigation unless the product requires it and accessibility parity is planned.
4. **Own state explicitly.** Prefer initializer parameters and environment injection. Use native observation for shared app state. Do not introduce a view model without a state-ownership or testability reason written in the handoff.
5. **Accessibility baseline (required).** Support Dynamic Type, VoiceOver labels/traits/grouping, keyboard and focus order where the platform has them, sufficient contrast, Reduce Motion, Differentiate Without Color, and a descriptive label for every icon-only control. Touch targets must remain usable (~44×44 pt). At large Dynamic Type sizes, allow scrolling by default and prioritize primary text growth so essential content is not clipped.
6. **Visual craft.** Match SF Symbol weight and scale to adjacent text. Prefer frequency-gated, interruptible motion: critically damped defaults; bounce only after momentum; press feedback on touch-down; source-anchored sheets/menus when origin matters; never lock input during transitions. Never animate keyboard-initiated or other high-frequency paths (command palettes, shortcuts, rapid focus moves). Custom enter/exit transitions should use the same path. Prefer system transitions; avoid multi-second decorative choreography and motion that is the only affordance of meaning. Icon-only controls need a label and a usable hit area.
7. **Keep the public API small.** Expose only configuration the consumers need. Document defaults and non-obvious parameters. Prefer semantic style enums over raw colors/fonts when tokens exist.
8. **Ship a preview or example** that exercises primary configurations and at least one accessibility-sensitive case (for example large Dynamic Type or an empty state).
9. **Test what the component owns.** Focused tests for configuration logic, state transitions, and public API contracts. Do not claim VoiceOver or visual polish passed without evidence — list manual checks.

## Stop conditions

- Business-specific screen copy, navigation shell, or domain workflow → implement as a feature, not a “component.”
- Token or branding-only request → `apple-design-system`.
- Genuine iOS/macOS divergence in interaction → chain `ios-macos-platform-adaptation`.
- Planning-only request → deliver design + verification plan without writing product code.

## Verification

Use `swift-testing-verification` and XcodeBuildMCP for the affected consumer target. Build the component’s host target; run focused tests. When the component is shared UI, follow with `apple-accessibility-review` before calling reusable work complete. If custom motion was added, confirm high-frequency/keyboard paths stay unanimated and Reduce Motion still provides non-motion feedback. Report residual risk for untested platforms and manual-only a11y checks.

Inputs: reusable component requirement and consumers. Output: a small documented component, self-contained preview/example, focused tests, and relevant build result. For planning-only requests, provide the component design and verification plan without implementation.