Sc UI

sc-ui — visual craft without AI slop

Language

Keep durable instructions in English. Reply in the user's language unless requested otherwise.

Default behavior

Inspect before inventing. If the project already has a coherent UI, preserve its design DNA unless the user explicitly asks for a redesign. Do not reset an existing product to generic defaults.

Before editing, produce an internal Design Read from the available product/code/rendered UI:

• product type and primary jobs,
• audience and expertise,
• platform and viewport priorities,
• hierarchy and information density,
• typography and spacing rhythm,
• surface/border/radius/shadow language,
• color roles and contrast,
• icon and illustration language,
• motion language,
• existing design tokens/components,
• explicit exclusions from the user.

Anti-slop filter

AI slop is not a specific color or component. It is unearned sameness: choices made because they are common in generated interfaces rather than because they serve the product.

Apply a purpose test to every visible decision: What user/product job does this choice serve?

Flag and fix when unjustified:

• cards wrapping every section or nested cards with no hierarchy benefit,
• decorative gradients/glass/blur/noise that do not communicate state or brand,
• excessive pills, badges, rounded rectangles, icon buttons, and floating containers,
• generic centered hero/marketing composition inside an application shell,
• fake metrics, fake social proof, placeholder dashboards, decorative charts, or meaningless activity,
• repeated same-sized modules that flatten hierarchy,
• arbitrary huge headings, low-information whitespace, or over-spacious admin/tool UIs,
• excessive shadows/radii that erase grouping structure,
• animation on everything rather than on state change or spatial continuity,
• hard-coded one-off colors/spacing where project tokens already exist,
• rebuilding a mature design system instead of extending it.

These are detectors, not blanket bans. Keep any pattern that has a clear product, accessibility, or brand reason.

Visual system contract

Prefer a small coherent system over many local decisions:

1. Typography: clear roles for display/title/body/label/code; readable measure and line height.
2. Spacing: repeatable rhythm; proximity communicates grouping before boxes do.
3. Color: semantic roles before decorative palette; preserve brand tokens.
4. Shape: radii/borders/shadows have explicit hierarchy roles.
5. Density: match task frequency and expertise; tools can be compact, reading surfaces can breathe.
6. Components: all interactive states exist — default, hover where relevant, focus-visible, active/selected, disabled, loading, error.
7. Motion: communicate causality, continuity, feedback, or hierarchy; respect reduced-motion preferences.
8. Responsive behavior: preserve task priority rather than merely stacking desktop rectangles.

Desktop shell rules

For application/workbench shells, prefer frame → navigation → primary work area → contextual tools/inspector over dashboard-card composition. Keep frequent actions visible, secondary actions discoverable, separators aligned, resize behavior intentional, and selected/focus states unmistakable.

Never redesign or modify an explicitly excluded surface. If the user says not to touch mobile navigation, treat it as a hard scope lock.

Verification gate

Do not call visual work done from code inspection alone. When tools allow it, inspect rendered pixels at representative sizes and verify:

• hierarchy is obvious in a 3-second scan,
• no accidental overflow/clipping/wrapping,
• alignment and divider continuity,
• typography and density consistency,
• component states,
• light/dark theme if supported,
• responsive behavior,
• no new generic/slop patterns introduced.

Report concrete defects and fixes, not subjective praise.