Skip to main content
ClaudeWave
Skill490 repo starsupdated 3d ago

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 e-commerce pages, especially alongside frontend-design.

Install in Claude Code
Copy
git clone --depth 1 https://github.com/waybarrios/opencode-power-pack /tmp/ai-slop && cp -r /tmp/ai-slop/skills/ai-slop ~/.claude/skills/ai-slop
Then start a new Claude Code session; the skill loads automatically.

SKILL.md

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 blobs standing in for the product, unlicensed stock hotlinks, AI imagery with anatomy/lighting inconsistencies, mixed icon families. *Repair:* authentic product imagery, purpose-built illustration, real screenshots, or honest placeholders — define an art-direction rule before generating assets.
- **Motion & interaction** — every element fades/rises on scroll, indiscriminate bounce easing, long entrance sequences,
agents-md-improverSkill

Audit and improve project-rules files (AGENTS.md, CLAUDE.md, .agents/instructions, local overrides) so the agent keeps accurate project context. Use when the user asks to check, audit, review, update, improve, or fix their AGENTS.md or CLAUDE.md, mentions "project rules maintenance" or "agent context optimization", or when the codebase has changed enough that the rules file may be stale. Scans the repository for every rules file, grades each against a quality rubric, outputs a quality report, and applies targeted edits only after user approval.

agents-md-reviseSkill

Capture learnings from the current session into the project-rules file (AGENTS.md, CLAUDE.md, or local override) so future sessions benefit. Use when the user says "revise the rules", "update AGENTS.md / CLAUDE.md with what we just learned", "save this to project memory", "remember this for next time", or at the end of a productive session when valuable context has emerged that is not yet documented. This complements agents-md-improver — improver audits, while this one captures.

code-architectSkill

Design a feature architecture by analyzing existing codebase patterns and conventions, then provide a comprehensive implementation blueprint with specific files to create or modify, component designs, data flows, and a build sequence. Use this skill when the user asks for an architecture design, an implementation plan for a non-trivial feature, or when dispatched as a sub-task during feature-dev architecture phase.

code-explorerSkill

Deeply analyze an existing codebase feature by tracing execution paths, mapping architecture layers, understanding patterns and abstractions, and documenting dependencies. Use this skill when you need to understand how a feature works before modifying or extending it, when dispatched as a sub-task during feature-dev exploration, or when the user asks "how does X work in this codebase".

code-reviewSkill

Review a pull request or a set of code changes for bugs, logic errors, and project-convention violations using a confidence-filtered, multi-agent process. Use this skill when the user asks to review a PR, audit pending changes, or inspect a diff for problems before merging.

code-reviewerSkill

Review code for bugs, logic errors, security vulnerabilities, code quality issues, and adherence to project conventions, using confidence-based filtering to report only high-priority issues that truly matter. Use this skill when reviewing a small set of changes locally (such as unstaged diff), when dispatched as a sub-task during feature-dev quality review, or when the user wants a critique of a specific file or function.

feature-devSkill

Guide a feature implementation through a structured seven-phase workflow with deep codebase understanding, clarifying questions, parallel architecture design, and quality review. Use this skill when the user asks to build a new feature, add functionality, or wants a methodical approach to implementation rather than diving straight to code.

frontend-designSkill

Create distinctive, production-grade frontend interfaces with high design quality and accessible markup. Use this skill when the user asks to build or beautify web components, pages, applications, landing pages, dashboards, artifacts, or React/HTML/CSS UI. Generates creative, polished code that avoids generic AI aesthetics, then self-checks it against an objective accessibility and quality rubric.