Individual skill

visual-design

Use when choosing or reviewing how a screen, flow, or page looks — colour palette, typography, spacing, cards and surfaces, buttons, icons, illustration and imagery, onboarding and paywall visuals, dark mode — or when a UI looks generic, flat, cluttered, dated, or inconsistent across screens, or someone asks to make it look premium or modern. Picks a visual direction and expresses it as tokens for web/SaaS, Apple platforms (iOS, iPadOS, macOS, visionOS, watchOS, tvOS), Android, and React Native/Expo. Reviews screenshots and mockups as well as code. Not for UX behaviour (use ux-psychology), accessibility audits, or animation timing.

plugins/tartinerlabs/skills/skills/visual-design/SKILL.md

Read pinned source

Source commit d780783eba4ecc7c8b9429f95c9362df95f07c61

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
Yes
Repository scan complete
No
Skill scan complete
No
Observed behavior
Network or broad shell
Last checked
Nov 4, 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)
1,532
Repository last updated
Nov 6, 2026
License
Apache-2.0

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

You decide how a screen looks: colour, type, spacing, surfaces, actions, icons, and imagery. A good-looking product is mostly a consistent one. It picks one visual direction, writes it down as tokens, and applies it everywhere. These rules are strong defaults, not laws. A product with a reason to differ keeps that reason.

## 1. Choose the Mode

Infer the mode from the request without asking.

- **Build**: the task creates or restyles UI. Apply the rules while writing the code. Do not narrate them: name a rule only when it changed a choice, in one line (e.g. "accent kept to the primary button and the selected day — colour"). Produce no report.
- **Audit**: the user asks for a visual review or critique, asks why a UI looks off, cheap, generic, or inconsistent, or shares screenshots or mockups for feedback. Produce the report in Step 6.

Requests to make an app "look premium", "look modern", or "pop" are usually hierarchy, consistency, or type problems, not palette problems. Check `rules/hierarchy.md`, `rules/surfaces.md`, and `rules/typography.md` before proposing new colours.

## 2. Find the Platform and the Existing System

Read the manifest as prose, then load **only** the matching guide: