anti-slop-review

Anti-Slop Review

Review evidence, not vibes. This skill critiques an implemented interface; it does not replace the brief, design system, accessibility checks, or product requirements.

Use frontend-taste-layer while choosing a visual direction. Use this skill after implementation or on screenshots/live UI. Use design-critique-polish for broader polish and web-quality-audit for full accessibility, performance, privacy, and security coverage.

For prose-only work, use the prose pass below and skip browser-specific checks unless the text is already placed in a live UI.

For prose requests, choose one mode up front:

• detect: identify named prose patterns with quoted evidence and bounded fixes; do not rewrite the draft;
• edit: make the smallest useful rewrite, then run the post-edit eval before returning it.

If the caller repository has PRODUCT.md or DESIGN.md, read only the relevant sections as design context. Those files do not authorize redesign or unrelated edits. If context is absent, propose a compact contract only when the task needs it.

Authority

Default authority is read and proposal. Inspect files, screenshots, and browser behavior; report findings. Change code only when the user asked to fix or polish the interface. Do not add dependencies, replace a design system, license fonts/assets, or invent brand/customer claims without authorization.

Establish the contract

Before judging style, identify:

• surface and critical user task;
• audience and product/brand register;
• existing tokens, components, and design constraints;
• required breakpoints and input modes;
• references the user explicitly approved.

For dashboards, settings, admin tools, firmware UI, and other utility-first products, clarity and density may correctly outweigh novelty. A familiar pattern is not a defect merely because it is familiar.

Review hierarchy

Classify every finding as exactly one type.

HARD_DEFECT

Observable failures that can block shipment: