Menu

Individual skill

ux-settings

0upvotes

Design or critique a settings / preferences page — organizing many options without overwhelm, plus the save model (autosave vs. explicit Save, confirmation, revert). Applies the always-true core (only relevant settings, frequency-ordered groups, plain labels, visible current status, destructive actions last, clear save feedback) and gates context-dependent levers (autosave vs. Save button, search, advanced-settings split, sensitive-change confirmation) with trade-offs. Trigger when the user asks to design or review a settings page, preferences screen, account settings, app configuration, or a save/confirmation pattern.

ux/screens/settings/SKILL.md

Read pinned source

Source commit 5007cd0241ccaa51ae2e4681f9618912dc10e239

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
No
Repository scan complete
No
Skill scan complete
Yes
Observed behavior
Not checked yet
Last checked
Nov 6, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
40
Repository last updated
Jul 2, 2026
License
MIT

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

# 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.
Back to top