Unslop UI

Unslop UI audits and redesigns an existing interface, replacing inconsistent decoration with deliberate spacing, color, copy, typography and composition. It preserves the product, its features, meaningful content and section order unless the user requests a broader change. The aim is a screen with a specific product identity, not merely a cleaner generic template. Quiet navigation and controls support one or two richer moments in the content, such as a meaningful chart, product preview or object from the product's world.

The workflow starts with the rendered screen and the files that produce it. With only a live link, it snapshots the page and compares the saved copy against a live screenshot because script-drawn backgrounds may not survive. With only a screenshot, it first reconstructs a close static HTML original. Those paths deliver redesigned code for the real site's owner, rather than claiming that the live site has changed.

Use this skill for a requested visual audit or redesign. Prose editing belongs to the separate unslop skill. The audit determines the scope: substantial problems justify the full process, while light problems get targeted polish that retains the existing brand, palette, type, layout and visual. If the screen has no such problems, the workflow says so and proposes at most two or three precise refinements, applying them only with agreement.

Before editing, it writes a five-line direction covering Product, Character, World, Moments and Signature. These describe the audience and purpose, concrete character, natural materials or setting, places for visual richness and one recurring distinctive detail. The audit and direction are shown for approval unless the user has already authorized proceeding. Genuine brand assets are retained; trends and unsupported claims do not substitute for product facts.

Inputs can be project code, an authorized page URL or a screenshot. The main outputs are revised screen code and a report covering the direction, changes by pass, unresolved factual claims and any image prompts. The nine passes run across the whole screen in order: spacing, color, icons, copy, type, layout, details, visuals and motion.

Spacing establishes a 4px rhythm with small-control exceptions, consistent dimensions, grouping and aligned columns. Color uses a neutral ramp, three text roles and restrained accent use; app surfaces stay neutral while content carries richness. Accent text needs adequate contrast. Icons use one set, size and stroke, with aligned boxes and decorative symbols removed. Copy describes the existing product plainly, uses short contextual labels and identifies what numerical changes compare against. Unverified claims require confirmation or removal, and mock data must be plausible rather than invented evidence.

Typography follows the chosen character while retaining an authentic brand font, with a limited scale, restrained weights, sentence case and consistent tabular figures. Layout preserves usable desktop proportions and adapts to mobile reading order instead of shrinking a dense preview. Details include nested radii, focus states, quiet metadata, meaningful chart types and clear hierarchy between primary charts and supporting data. The signature detail appears only where it belongs.

Visuals show something true about the product. Dashboards generally draw richness from real content and carefully built charts rather than generated decoration. Landing heroes may use a scene from the product's world with calm space for text and a code-built preview of promised functionality. With no image tool, the workflow builds what it can, writes prompts and reserves appropriately sized slots. Motion removes purposeless loops and distracting effects, names transition properties and keeps feedback restrained and explanatory.

The final checklist compares the rendered result with the audit and tests whether the screen would still fit another product after a name swap. Screen rendering is limited to three checks during the run. Functionality and accessibility still need verification in the target project; the design guidance remains subjective.

Optional story videos show the transformation only when requested or needed as a shareable result. A standalone story.html preserves the original as step zero and adds three to five cumulative CSS steps. Changes morph in place with staggered timing, redline measurements and limited text swaps. Camera metadata chooses a close crop; the renderer produces square or wide video using Playwright and ffmpeg. Extracted frames are inspected before handoff. Story classes and attributes stay out of the normal production code.

Snapshots load site scripts and write files. Story HTML must be trusted because its scripts can access served files and make network requests; fresh output paths avoid overwrite, and the adapted tools refuse existing outputs. Image generation can send prompts externally and incur costs. Damir Sokolovsky's CC BY 4.0 attribution must be retained in copies or adaptations, including the video's small unslop by @heydamir credit.