/slop-eval

name: slop-eval
description: >
  Objectively evaluate a UI/web design against the pols.dev anti-slop design
  law: detect catalogued slop tells with cited evidence, score 8 weighted
  axes (color, type, components, layout, motion, execution, signature,
  cohesion), and emit a Slop Report with a 0–100 Slop Index and grade. Use
  when the user asks to "evaluate design slop", "slop report", "is this
  design AI slop", "audit this landing page design", "de-slop review", or
  wants an objective score of how generic/machine-made a design looks. To
  fix text (not design), use human-ai or humanizar skills instead.
metadata:
  author: https://ft.ia.br
  version: "1.1.0"
  date: 2026-08-24
  repository: https://github.com/fabricioctelles/skills
  license: Apache-2.0
  category: code-quality-and-review

Slop Eval

Evaluate a design the way `skill-evaluation` evaluates a skill: every finding cites concrete evidence, every axis gets a 0–100 score, arithmetic runs through a script, and the output is a structured report — never a vibe check.

The tell catalog lives in `references/tells.md`; read it before sweeping. The positive rubric (signature formula, cohesion checks, slop→premium pairs, and the "Adding Soul" guide) lives in `references/premium-markers.md`; read it before scoring Axes 7–8 and when writing fix prescriptions. The design context guide lives in `references/contexts.md`; read it to adjust priorities and tolerances based on the type of design being evaluated.

Source

• [The pols.dev anti-slop design law](https://pols.dev/slop.md) — the tell

catalog, absolute rules, and signature formula are distilled from it.

• Method modeled on

[skill-evaluation](https://github.com/fabricioctelles/skills/tree/main/skills/skill-evaluation) (cite-or-cut, weighted axes, scripted scoring, failure-mode diagnosis).

Parameters

| Parameter | Description | Default | |-----------|-------------|---------| | `target` | What to evaluate: live URL, screenshot(s), code path, or Figma export | Ask user | | `brief` | Brand brief or explicit user directions the design followed | None | | `context` | Design type: `landing`, `saas`, `editorial`, `ecommerce`, or `auto` | `auto` | | `output` | Path to write the report | `./SLOP-REPORT.md` | | `compare` | Path to a previous report for tracking mode (temporal evolution) | None |

Write the report in the language the user is speaking; keep tell IDs and names in English so they stay greppable against the catalog.

Evaluation modes

Standard mode (default)

Single evaluation of a design. Produces a Slop Report with scores, tells, section ledger, and prioritized fixes.

Comparison mode

Side-by-side evaluation of two different designs (e.g., competitor analysis, A/B variants). Add `--compare` pointing to another target or existing report.

Tracking mode

Evaluate the same design over time to measure improvement. Use when:

• Running weekly/sprint design reviews
• Measuring progress after a redesign
• Validating that fixes actually moved the score

Usage:

# First evaluation — establishes baseline
slop-eval --target https://site.com --output ./reports/baseline.md

# Later evaluation — tracks evolution
slop-eval --target https://site.com --output ./reports/week-2.md \
  --compare ./reports/baseline.md

Tracking mode adds to the report:

• Score progression table with trends (✅ improved / ⚠️ regressed)
• Tells resolved (what got fixed)
• New tells (what got introduced)
• Regressions (axes/sections that got worse)
• Section ledger evolution
• Velocity metrics (tells resolved per week, score improvement rate)
• Recommendations for next iteration

See `references/output-template.md` for the full tracking output format.

Evidence channels

What you can verify depends on what you were given. Never score a check you could not observe — mark it **Unverifiable** and exclude it (like N/A in skill-evaluation).

| Channel | Can verify | Cannot verify | |---------|-----------|---------------| | Code (CSS/JSX/HTML) | Fonts, hex values, gradients, shadows, radii, `opacity:0` gating, icon imports, layout skeletons | Optical centering, rendered contrast, seams, whether controls respond | | Screenshot(s) | Everything visual: palette, type, layout, alignment, centering, clipping, contrast, seams | Hover/scroll motion, dead controls, invisible-content trap, responsive behavior | | Live URL (browse + screenshot) | All of the above plus interactions, motion, fold ownership | Only what you didn't exercise |

With code, grep before you stare: `fonts.googleapis|next/font`, `lucide-react`, `linear-gradient`, `box-shadow`, `border-radius: *9999`, `backdrop-filter`, `opacity: *0`, `initial={{ *opacity: *0`, `overflow: *hidden`, `clip-path`, `position: *fixed`. Each hit is a lead, not a verdict — confirm against the catalog entry before recording it.

Evidence acquisition SOP

Route by what the `target` is; always end with an evidence inventory (what was captured, what is Unverifiable) — it feeds the report header.

**Live URL** — the richest channel; prefer it whenever reachable. Use whatever browser automation this session has (a browser MCP such as Playwright or Chrome DevTools, or `npx playwright screenshot` as the no-MCP fallback) and capture, saving every artifact to the scratchpad so findings can cite `file + region`:

1. Load at desktop (1440×900) and mobile (390×844); wait for network idle. 2. Full-page screenshot of both viewports **immediately after load, before any scrolling** — sections sitting at `opacity:0` waiting for a scroll reveal show up blank here (M1 evidence). 3. Scroll pass top to bottom, then a second full-page capture; diff the two mentally for reveal-gated content, seams (C11, X13), and fold ownership (L16). 4. Interaction pass: hover the primary CTA, one card, one nav link (M2–M4); click every tab, accordion, toggle, and button (M8); Tab through the page and confirm a visible focus ring (X14). 5. Zoom crops at 2