Individual skill
design-preferences
Apply swyx's design preferences when building or changing app screens, or designing, restyling, or reviewing websites: reuse shared app layouts, preserve information density, use readable typography, avoid decorative card accent strips, and give brand color a clear purpose. Use alongside task-specific design workflows.
design-preferences/SKILL.md
Source commit 1acf58f08cca24b764a4352a6c30fed1f7fb9fb6
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 7, 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)
- 198
- Repository last updated
- Nov 9, 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
SKILL.mdcore · 4,161 bytes
Read excerpt
# Design preferences
These are the user's defaults, not universal design rules. Follow an explicit visual reference or request when it overrides them. Apply them to the requested surface; do not expand a small task into a site redesign.
- **No decorative thin accent strips on cards.** Avoid colored or gradient top borders, ribbons, and `::before` lines added just to make repeated panels look designed. Functional table rules, chart marks, focus rings, and active-navigation indicators are fine.
- **Choose the layout for the information.** Use aligned rows or tables for repeated comparisons, and place a finding beside its evidence. Use cards when items genuinely form independent units, not as the automatic wrapper for every paragraph or statistic. Avoid nested cards.
- **Density comes from composition, not tiny text.** Start around 17–18px for reading text on desktop and 16–17px on mobile. Keep secondary labels legible. Shorten repetitive copy, align related facts, and reduce container padding before shrinking type. Recompose mobile comparisons rather than scaling down a desktop table.
- **Make whitespace earn its place.** Use space to distinguish sections and establish hierarchy. Avoid oversized introductory regions, tall rows around two numbers, and equal-height panels full of emptiness. Put repeated caveats once at the relevant section level while retaining essential denominators beside the data.
- **Use brand color confidently and purposefully.** Prefer meaningful series colors, selected states, or a substantial focal region over ornamental gradients repeated everywhere. Preserve strong text contrast on colored surfaces. Follow the actual brand assets and palette; do not invent a substitute logo. A dark masthead and a broad gradient can work when appropriate, but are not mandatory.
## Shared application layout
- **Signed-in pages inherit the shared app shell.** Reuse the existing navigation, account controls, and workspace switcher where the app has one. Include workspace selection, settings, creation/editing, and detail pages; do not build detached page-specific chrome. The shell must also work before a workspace is selected.
- **Keep context through every state.** Loading, empty, error, expired-session, and permission states retain applicable navigation and account or sign-in controls, with useful recovery actions. A missing workspace must not strand the user without a way to switch accounts or sign out.