Skip to content
Security
Skill

/ai-slop

Operational rubric that turns "don't make AI slop" into observable properties, severity levels, evidence requirements, and repair actions for interface design. Use as the reference rubric when building or reviewing marketing sites, product interfaces, dashboards, portfolios, or

BOOST
From plugin
opencode-power-pack
53955 skills
Install
$ npx -y skills add waybarrios/opencode-power-pack --skill ai-slop --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/ai-slop

Context preview

The summary Claude sees to decide when to auto-load this skill.

Operational rubric that turns "don't make AI slop" into observable properties, severity levels, evidence requirements, and repair actions for interface design. Use as the reference rubric when building or reviewing marketing sites, product interfaces, dashboards, portfolios, or

SKILL.md

ai-slop.SKILL.md
name: ai-slop
description: Operational rubric that turns "don't make AI slop" into observable properties, severity levels, evidence requirements, and repair actions for interface design. Use as the reference rubric when building or reviewing marketing sites, product interfaces, dashboards, portfolios, or e-commerce pages, especially alongside frontend-design.
license: MIT (modified; see UPSTREAMS.json)

Scope: marketing sites, product interfaces, dashboards, portfolios, editorial pages, and e-commerce. Complements `frontend-design`: that skill builds the interface, this one is the detailed rubric for judging whether the result is generic ("AI slop") or genuinely fit for the product.

This is not a universal style guide. It does not ban a visual style merely because AI systems use it often — a gradient, card grid, serif headline, glass surface, or dark theme may be appropriate. It becomes a slop signal when used by reflex rather than because the product, audience, content, interaction, or brand requires it.

MUST/MUST NOT are required for acceptance; SHOULD/SHOULD NOT are default rules whose deviations need a written rationale; MAY is optional and context-dependent.

1. Core definition

**AI slop is superficially competent output that lacks sufficient intention, grounding, specificity, coherence, truthfulness, or product fit.** It usually shows up as one or more of:

1. **Default-driven** — recognizable model/template reflexes replace deliberate decisions. 2. **Interchangeable** — could be relabeled for another product with minimal change. 3. **Ungrounded** — content, claims, visuals, or features aren't supported by the brief or evidence. 4. **Incoherent** — polished elements that don't form one consistent system. 5. **Decorative without purpose** — effects attract attention without clarifying hierarchy, meaning, state, or action. 6. **Quantity-over-value** — extra sections/cards/copy exist mainly to look complete. 7. **Unreviewed** — obvious responsive, accessibility, factual, or interaction defects remain. 8. **Overfitted to current AI aesthetics** — follows the fashionable model output distribution rather than the project's needs.

Output is **not** slop merely because AI helped produce it — a result can be AI-assisted and still strong when it's grounded in real product/user context, deliberately art-directed, specific, factually honest, coherent, accessible, edited, browser-validated, and hard to transplant unchanged to another product. Human-made work can also be slop; the classification concerns the output, not proof of authorship.

2. Two quick tests

  • **Substitution test**: could the product name, logo, and accent color be swapped while 80% of the page stays equally plausible for another product? Yes = strong slop risk; No = likely meaningfully tied to the product.
  • **Rationale test**: every prominent decision MUST answer at least one of: what user need does this serve, what product truth does it express, what hierarchy does it clarify, what brand trait does it embody, what interaction state does it communicate, what constraint made it appropriate? If the only answer is "it looks modern" or "AI suggested it," it's a slop candidate.

3. Evaluation dimensions (score each 0-4: 0 excellent, 1 minor, 2 noticeable, 3 serious, 4 blocking)

  • **Product grounding & specificity** — generic value props, checklist-driven sections, invented features/personas, visual metaphors unrelated to the product. *Evidence:* a `PRODUCT.md` (or equivalent) with explicit users, jobs, constraints, and a traceable reason per section. *Repair:* cut unsupported sections, rewrite around concrete user tasks.
  • **Truthfulness & evidence** (blocking) — invented prices, metrics, testimonials, logos, citations, or controls that imply unavailable functionality. Use `[NEEDS INPUT]`, "Price on request," or clearly labeled sample data instead; keep an evidence ledger for verifiable claims; mark fictional demo data as demo data.
  • **Information architecture & narrative** — default hero → logo cloud → cards → metrics → testimonials → pricing → FAQ; shuffleable section order; front-loaded slogans. *Repair:* define the reader's questions in order, give each section a unique job, cut sections that don't advance understanding.
  • **Composition & layout** — everything centered, identical repeated cards, uniform spacing, excessive pills, desktop merely stacked on mobile, heading overflow at mid widths. *Repair:* content-led layouts, intentional density variation, a spatial system broken only for a reason, test real content at multiple widths.
  • **Visual system coherence** — inconsistent radii/shadows/icon weights, unrelated surface treatments per section, tokens defined but bypassed. *Evidence:* a `DESIGN.md` with semantic tokens (color, type, spacing, radius, elevation, motion) that components actually consume, and a documented exception when something breaks the system.
  • **Color & material** — unexplained purple/violet "tech" gradients, cyan glows on dark backgrounds, gradient headline text without purpose, glassmorphism everywhere, palette chosen from category stereotype alone. None of these are automatically forbidden — flag them when repeated, unsupported by the brand concept, or chosen as a reflex.
  • **Typography** — same popular default typefaces everywhere, one weight pattern for every role, oversized display type for "editorial" feel, tiny tracked eyebrow labels, flat hierarchy, hero text that fails on mobile. *Repair:* select type from brand attributes and reading conditions, define role-based type tokens, test long words/localization/zoom.
  • **Copy & voice** — "revolutionize/unlock/seamless/elevate," "not just X, but Y," empty claims ("built for the future"), repetitive cadence and em dashes, "Learn more" buttons with a predictable destination. *Repair:* concrete nouns/verbs, state what the product does for whom and why, remove undemonstrable claims.
  • **Imagery & iconography** — generic gradient bl
Read more
Ships withopencode-power-pack

54 rigorous skills for Codex, OpenCode, and Pi: code review, security audit, feature development, frontend design, MCP tools, Hugging Face ML/training, and more.

Get the whole plugin

Other skills on opencode-power-pack.