Settings Skill

How this skill behaves (read first)

This is a generative skill. Settings is a pattern users know — the job is get in, change one thing, get out — and the default failures fight that: a flat dump of every option, the page used as a junk drawer for links that fit nowhere else, technical-jargon labels, no current status shown, destructive actions sitting up top where they're hit by accident, and changes that save with no feedback (or autosave where the user expected a deliberate Save). A settings screen has two design problems in one — how the options are organized and how changes are saved — and each has its own rules. So this skill gates:

1. Establish scale, platform, and sensitivity — how many settings, mobile vs. web, and whether sensitive data is involved decide the structure and the save model.
2. Apply the always-true core — relevance, grouping, plain labels, visible status, destructive-last, clear save feedback.
3. Surface the context-dependent decisions (autosave vs. Save button, search, advanced split, confirmation/2FA) with trade-offs.

Then it hands off to ux-heuristics-audit, ux-accessibility-audit, ux-aesthetics-audit, ux-microcopy-audit, ux-information-architecture-audit, ux-dark-patterns-audit, and ux-mobile-responsiveness-audit for validation.

Scope & composition (per docs/orchestration-policy.md §9): this skill covers the settings page and its save model and composes lower-scope skills rather than re-deriving them. Core children (built as part of the page): the choice of control (toggle vs. checkbox vs. radio vs. slider) via ux-selection-controls. Peers that own a sub-part (defer): the search input itself to ux-search and notification-preference depth to ux-notifications-and-toasts (they own those sub-parts if reached). Inherit, don't regenerate: under an existing design system, take color/type/spacing from its tokens — only set those when designing from scratch.

Step 0 — Establish context before designing

Ask if not known; state the assumption if proceeding without an answer: