fix: sync UIZZE skill with canonical workflow (#2771)

skills/anti-ui-slop/reference/audit.md

@@ -0,0 +1,14 @@
+# Audit an implemented interface
+
+Review only what can be observed in the implementation or rendered result. Do not invent missing requirements or turn personal taste into a defect.
+
+Inspect:
+
+- task clarity and hierarchy;
+- consistency with the product's existing system;
+- layout, overflow, media treatment, and responsive behavior;
+- interaction feedback and necessary loading, empty, error, success, disabled, and recovery states;
+- labels, focus, keyboard access, target size, and contrast;
+- obvious performance problems visible in the experience.
+
+Return at most three material findings, ordered by user impact. For each finding, name the observable evidence and the smallest concrete correction. If nothing material is visible, say so briefly. An audit does not modify the product unless the user also asked for fixes.

skills/anti-ui-slop/reference/distill.md

@@ -0,0 +1,20 @@
+# Simplify an interface
+
+Remove obstacles between the user and the main task without removing necessary capability.
+
+## Find the excess
+
+- Identify the primary goal and the information required to complete it.
+- Remove repeated copy, duplicate actions, decorative noise, and containers that do not clarify grouping.
+- Reduce unnecessary variation in colors, type sizes, button styles, spacing, and surface treatments.
+- Prefer one obvious primary action and a small number of clearly subordinate actions.
+- Use progressive disclosure for advanced or infrequent controls, but keep essential information visible.
+
+## Preserve clarity
+
+- Do not hide required actions behind mystery interactions.
+- Do not remove labels, focus states, accessibility semantics, error messages, or recovery paths.
+- Do not flatten genuinely complex information until it becomes harder to understand.
+- Prefer spacing and alignment over nested cards; prefer plain language over explanatory copy.
+
+Verify that the simplified result still supports the complete task, including its important states, at the relevant screen sizes.

skills/anti-ui-slop/reference/ios.md

@@ -0,0 +1,17 @@
+# Native iOS interfaces
+
+Follow the product's existing iOS conventions first, then Apple platform conventions. A native interface should feel predictable before it feels distinctive.
+
+## Structure and controls
+
+- Use a navigation stack for hierarchy, a tab bar for a small set of top-level destinations, and sheets for self-contained tasks.
+- Preserve the edge-swipe back gesture and safe-area behavior.
+- Prefer native controls, materials, menus, alerts, sheets, pickers, and text behavior unless the product already has a coherent custom system.
+- Keep touch targets comfortable, text scalable, labels accessible, and focus order sensible.
+- Account for the keyboard, long content, dynamic type, reduced motion, dark mode, and device insets.
+
+## States
+
+Include the states the task requires: loading, empty, error, success, permission denied, offline, disabled, and recovery where applicable. Feedback should be immediate and should not depend on color alone.
+
+When a simulator or runnable build is available, inspect the relevant device class once and fix observable clipping, overlap, unsafe-area violations, unreadable text, broken navigation, or inaccessible controls. Do not require extra tooling when the environment cannot provide it.

skills/anti-ui-slop/reference/new-work.md

@@ -0,0 +1,23 @@
+# New interface or major redesign
+
+Start from the product, not from a style trend. Read the brief, existing components, content, constraints, and any current interface before choosing a direction.
+
+## Decide the interface
+
+- Identify the primary user, their main task, and the one action that matters most on this surface.
+- Choose one coherent visual direction that fits the product. Do not present style menus or invent novelty for its own sake.
+- Establish a clear reading order: orientation, primary content, primary action, then secondary detail.
+- Reuse the existing design system when one exists. Extend it only where the requested work genuinely needs something new.
+- Keep familiar controls familiar. Distinction should come from the product's content, structure, typography, imagery, and interaction—not from making standard controls strange.
+
+## Build the complete state
+
+- Use real or clearly marked placeholder content that exercises the layout.
+- Include the states required by the task: loading, empty, error, success, disabled, or recovery when they can actually occur.
+- Define responsive behavior structurally. Decide what stacks, collapses, scrolls, or remains fixed instead of merely shrinking the desktop layout.
+- Keep typography, spacing, color, radius, icon style, and motion internally consistent.
+- Use motion only to explain a transition, reveal state, or provide feedback.
+
+## Verify once
+
+Render the result at the relevant sizes when the environment supports it. Fix observable clipping, overlap, distorted media, inaccessible controls, broken focus, unreadable hierarchy, or inert interactions. Stop when the requested interface works and feels coherent; do not add a separate ceremony around the work.

skills/anti-ui-slop/reference/operate.md

@@ -0,0 +1,23 @@
+# Product and dashboard interfaces
+
+Product UI should disappear into the task. Familiarity is a feature when users need to move quickly and trust the controls.
+
+## Structure
+
+- Make the current location, primary task, and next action obvious.
+- Match information density to the work. Dense tables and compact controls are appropriate when users need them; decorative containers are not.
+- Prefer standard navigation, forms, tables, tabs, menus, and dialogs over novel replacements.
+- Use spacing and alignment for grouping before adding borders, cards, or backgrounds.
+- Keep one component vocabulary across the surface.
+
+## States and behavior
+
+- Cover the states the product can reach: loading, empty, error, success, disabled, selected, expanded, and recovery where relevant.
+- Keep focus visible, controls labelled, contrast readable, and targets usable.
+- Prevent overlays and menus from being clipped by scroll or overflow containers.
+- Use quick motion only for state changes and feedback. Do not choreograph routine page loads.
+- Make responsive changes structural: collapse navigation, reflow groups, and preserve access to important actions.
+
+## Finish
+
+Use the interface at representative sizes. Fix the few observable issues that obstruct the task or break consistency. Do not redesign working areas outside the requested scope.

skills/anti-ui-slop/reference/polish.md

@@ -0,0 +1,18 @@
+# Refine an existing interface
+
+Polish improves the interface that exists; it does not conceal a redesign. Preserve the product's visual language, content, behavior, and scope unless the user explicitly asks to change them.
+
+## Inspect the real result
+
+Render or run the interface when possible. Check representative desktop and mobile sizes for web work, or the relevant device class for native work. Judge the rendered result rather than the source code alone.
+
+Prioritize the largest observable problems:
+
+- unclear hierarchy or competing primary actions;
+- inconsistent spacing, typography, color, radius, or icon treatment;
+- clipping, overlap, overflow, distorted images, or awkward wrapping;
+- missing hover, focus, disabled, loading, empty, error, or success feedback;
+- inaccessible controls, weak contrast, or poor keyboard behavior;
+- decorative noise that competes with the task.
+
+Fix related issues in one coherent pass. Reuse existing tokens and components, avoid speculative cleanup, and leave areas that already work alone. Confirm the changed surface once more after the fixes.