---
name: nibble-skill
description: "Find and fix design mistakes that make an interface feel carelessly generated: unreadable text, inconsistent colors, misaligned icons, weak hierarchy, arbitrary spacing, and unnecessary decoration. Use to review or improve UI while preserving the project's identity and structure. Does not apply to backend-only tasks."
---

# Nibble Skill

Improve interface quality through corrections justified by what is visible and how it is used. Nibble's criteria teach which mistakes to detect; they do not define an aesthetic every project must copy.

**Preserve the product's identity.** Do not impose a default font, palette, layout, navigation pattern, or material. A colorful, dense, or expressive interface can be well designed. Invoking this skill should not turn it into a black catalog, an editorial column, or a copy of Nibble.

## Work on observable problems

1. **Understand the intent.** Read the request, local instructions, and actual screen. Identify the product, primary task, platform, existing visual system, and decisions the user has approved. Use references to understand the requested correction; do not copy their structure by association.
2. **Inspect before deciding.** Look at the screen and the styles or tokens that produce it. Check the actual font, sizes, contrast, icon boxes, alignment, density, and states. A class name or list of CSS values does not replace the rendered view.
3. **Separate defects from preferences.** Describe each problem by its effect: what is hard to read, what does not align, which control is unclear, or which screens contradict the system. Saying it "looks AI-generated" does not justify changing a decision. Reject changes that only replace the author's taste with another taste.
4. **Fix the shared cause.** Prioritize readability and controls, then hierarchy, alignment, spacing, and consistency; finally remove decoration with no function. Adjust responsible components and tokens instead of accumulating overrides or redesigning the entire application.
5. **Verify the result.** Compare before and after at the same viewport and in relevant states. Check mobile, keyboard, and available themes within scope. Verify that valid product decisions remain intact.

When asked to improve or fix, implement the relevant corrections. For an audit without changes, deliver findings and concrete recommendations. If there is no demonstrable problem, say so and preserve the interface; do not invent a redesign to appear productive.

For diagnostic examples, see [references/design-errors.md](references/design-errors.md). Look for tokens, components, and instructions inside the project being reviewed.

## The antislop-ai filter

This skill integrates `antislop-ai` rules alongside the user's corrections. For visual work, read [references/antislop-ai.md](references/antislop-ai.md) and the relevant modules. This is a versioned local copy: do not run the installer on every task or overwrite this skill with another of the same name.

The filter alone does not provide visual direction. Before building or redesigning, identify the product's direction and record decisions in `DESIGN.md` when justified: composition, typography, color, rhythm, and the purpose of effects. When the user leaves design decisions to you, form a concrete proposal, identify your own decisions, and execute within the authorized scope. Do not turn a decision from one trial into a universal rule.

Also check the opposite of excessive decoration: an interface can remain generic with neutral backgrounds, thin borders, small text, and identical controls. A sidebar, calendar, serif font, or restrained palette does not replace hierarchy built for the task. Avoid wellness or productivity slogans, duplicate summaries, and filler labels that do not help people act.

Before delivery, apply the integration's four verification blocks and keep evidence proportional to the work. A technical PASS does not prove the user likes the design; do not claim to have eliminated an AI-generated feel simply by changing a font or color.

## What to review when relevant

### Text and hierarchy

- Look for undersized primary text, hard-to-read controls, insufficient weights on muted backgrounds, and contradictory sizes across screens. Include footers, forms, filters, empty states, dialogs, and documentation, not only the hero.
- On a reading-oriented website, 16 px is a reasonable body-text reference. A dense app, code viewer, or explicit preference may use another scale. Do not make every label 16 px or shrink everything on mobile to fit.
- Adjust size, line height, reading width, and spacing together. Do not fix overflow with microscopic text or hierarchy with oversized headings everywhere.
- Preserve the project's appropriate font family. Verify that it loads and that the browser uses the expected weight. Do not replace Inter just because it is common, or copy Cascadia Code into interface text.

### Color and contrast

- Remove accidental colors, inconsistent tints in neutrals, competing accents, and states without enough contrast. Reuse the system's semantic roles.
- Preserve functional brand colors, covers, syntax highlighting, visualizations, and states. Do not apply grayscale everywhere to "remove AI slop."
- If the user requests black, white, and gray, ensure those neutrals do not accidentally introduce blue, violet, or warm tints. If a particular gray surface was approved, do not automatically turn it black.
- Check light and dark themes separately: the same functional hierarchy, with contrast and elevation appropriate to each theme.

### Icons and alignment

- Detect accidental mixtures of families, strokes, fills, and visual sizes; excessive internal space, incorrect baselines, and icons that sit off-center beside labels.
- Preserve an established, coherent family. Use its shared renderer. Installing a particular icon library in every project is not a correction; icon-library choices belong to the product.
- Fix boxes, flex/grid layout, line height, and viewBox before using offsets. Distinguish geometric from optical centering. Check the logo too.
- An icon should help identify an action or content. Remove repetitive, functionless icons, such as an AI sparkle on every block, when they add noise. Preserve accessible names for controls without text.

### Composition, surfaces, and consistency

- Look for unrelated padding and gaps, elements that should align but do not, cramped content, excessive empty space, and ambiguous grouping.
- Detect accidental differences across the same product: fonts, scales, buttons, radii, borders, states, and materials. Correct them through the existing system; do not rebuild every view using one screen's layout.
- Review redundant wrappers and cards, uninformative badges, accumulated shadows and borders, gradients, and glows competing with content. Remove them when they serve no purpose. Cards, gradients, and three-item grids are not defects by themselves.
- Preserve navigation and architecture that work. Do not turn categories into cards, add a sidebar, duplicate sections, or move actions just to resemble another reference.

### Effects and content

- For glass, check background transparency and blur while keeping text and controls sharp. When something should be a background, verify that it fills the intended space. Do not add glass or animated backgrounds where they are unnecessary.
- Detect motion that delays frequent actions, reanimates already-read content, moves data, or restarts an interaction. Preserve focus, selection, continuity, and motion/transparency preferences.
- Remove test data presented as real, empty claims, redundant titles, and technical explanations inserted into user flows. Preserve status information that helps understanding or action.
- Verify that buttons, filters, and tabs do what they promise. Visual polish with dead controls still feels unfinished.

## Scope and delivery

Apply the criteria to the project's platform, reusing its components, tokens, and materials. Respect its technical instructions. Do not change frameworks, introduce libraries, or delete working components unless the correction requires it.

A request to clean up design does not authorize publishing, pushing, or modifying other projects. For a new interface, first identify its purpose and visual language; these criteria prevent mistakes while building, rather than selecting the same design every time.

Validate proportionally: visual review for small changes, existing checks for behavior changes, and targeted tests when a real risk exists. Avoid tests that merely repeat CSS sizes or colors.

Summarize the problems corrected and verification performed. Do not assign an arbitrary "AI slop" score or present a difference from Nibble as a defect.