The Slop Epidemic

Every AI coding agent ships the same interface. Centered headline. Three feature cards with icons. A purple gradient somewhere. A “Get Started” button. The pattern is so predictable that developers have a name for it: slop. The term captures the visual mush that emerges when large language models, trained on a median of the web, default to the safest, most common denominator of design.

Taste Skill, a repository of SKILL.md files maintained by Leonxlnx, exists to interrupt this loop. It is not a framework in the conventional sense—no runtime, no components, no npm install. It is a set of portable constraints, a design sensibility encoded as agent instructions, meant to be consumed by Cursor, Claude Code, Codex, Gemini CLI, and any other tool that reads SKILL.md files [1][7]. The project calls itself “The Anti-Slop Frontend Framework for AI Agents,” and the framing is deliberate: it treats visual taste as a system that can be specified, versioned, and injected into agent context [1].

The repository has accumulated enough attention to register on curated lists of agent skills and marketplace directories, with install counts tracked in the hundreds of thousands across its skill bundle [12]. What makes it notable is not technical complexity but the specificity of its intervention. It targets a genuine failure mode in current AI-assisted development and attempts to correct it through prompt engineering at scale.

How Agent Skills Work

The mechanism depends on a format originally developed by Anthropic and now adopted across the ecosystem: Agent Skills [2][7]. A skill is a folder containing a SKILL.md file with YAML frontmatter (name and description) and a body of instructions. Agents load skills through progressive disclosure—metadata at startup, full instructions only when a task matches the skill description, additional resources on demand [2][7]. This keeps context windows manageable while allowing agents to carry extensive specialized knowledge.

Taste Skill bundles thirteen distinct skills in a single repository, each addressing a different facet of the slop problem [1][9]. The default design-taste-frontend skill (now v2 experimental) underwent a substantial 2026 rewrite. It reads project briefs, infers design direction from cues like “minimalist” or “editorial” or “SaaS,” and maps those inferences to actual design systems—Material, Fluent, Carbon, Polaris, Atlassian, Primer, GOV.UK, USWDS, Bootstrap, Radix, shadcn, Tailwind—rather than approximating them poorly [9].

The v2 skill introduces adjustable dials at the top of its instruction file: DESIGN_VARIANCE, MOTION_INTENSITY, and VISUAL_DENSITY, each on a 1-10 scale [1][9]. This is a pragmatic recognition that different projects need different postures. A fintech dashboard and a portfolio site should not share the same layout aggression. The skill also ships canonical GSAP code skeletons for common animation patterns, a hard pre-flight checklist that must pass before output ships, and what the documentation calls a “complete em-dash ban”—a telling detail that suggests the author has spent too much time watching agents punctuate like nineteenth-century novelists [9].

The Ban System and the Locks

Section 9 of the core skill contains what Taste Skill calls its “Anti-Slop Ban System”—a strict list of patterns that make generated frontends look identical [9]. The documentation does not enumerate every ban in the sources, but the framing is clear: these are not suggestions. The agent enforces them on every output.

More structurally interesting are the “locks” in Section 4: Color Consistency Lock, Shape Consistency Lock, and Page Theme Lock [9]. These prevent the common agent failure mode where a page begins with one visual language and drifts into another three sections down. A warm-grey site does not suddenly acquire a blue CTA. Corner radii do not vary arbitrarily. Light and dark modes do not flip mid-page. These are coherence rules, and they address a real problem: agents, working section by section, often lose track of global design decisions.

The hero discipline rules are similarly specific. Headline maximum two lines on desktop. Subtext maximum twenty words and four lines. Primary CTA visible without scroll. Navigation single line at desktop, height maximum 80px [9]. These constraints read like the output of watching hundreds of agent-generated landing pages and cataloging where they go wrong.

The Skill Catalog: From Brutalism to Output Discipline

Beyond the default skill, the repository offers specialized variants. gpt-taste tightens rules for GPT and Codex models with stronger layout variance and motion direction [1]. redesign-existing-projects performs six-category audits before touching code. soft-skill targets “calm, expensive-looking interfaces.” minimalist-ui channels Notion and Linear. brutalist-skill goes for Swiss typography and raw structure [1][9].

The image-generation skills—imagegen-frontend-web, imagegen-frontend-mobile, brandkit—produce reference frames rather than code, intended for use with ChatGPT Images or Codex image mode before handoff to implementation agents [1]. The image-to-code-skill wraps this into a single pipeline: generate, analyze, implement. The stitch-skill bridges to Google Stitch with optional DESIGN.md export [9].

An output-skill exists solely to prevent agents from shipping half-finished work—placeholder comments, skipped sections, truncated files [1]. This is a revealing inclusion. It suggests that even when taste is solved, execution remains unreliable, and the project treats both as design problems.

Position in the Ecosystem

Taste Skill sits at an interesting intersection. The broader agent skills ecosystem includes official skills from Anthropic, Google Labs, Vercel, Stripe, Cloudflare, and others, collected in directories like VoltAgent’s awesome-agent-skills [4]. Most of these address functional domains—document processing, API integration, testing. Taste Skill is among the few focused on aesthetic output, and it has found enough traction to be featured in marketplace listings alongside these official offerings [12].

The project also connects to a larger conversation about AI and design practice. At Faire, product designer Jess Brown has documented using LLMs for interview synthesis, support ticket analysis, and content generation—tools that augment rather than replace human judgment [3]. The Nielsen Norman Group has examined the tension between design taste and technical skills in an AI era, though the source content is obscured by cookie consent infrastructure [11]. Taste Skill essentially attempts to encode taste into technical infrastructure, making it portable and repeatable.

Limits and Open Questions

The project is explicit about its experimental status. v2 is “genuinely better than v1 and we recommend it, but it is still iterating” [1][9]. Section numbering and rule wording may change before a stable v2.0.0. The v1 skill remains available for projects depending on its exact behavior. This is responsible versioning for a format that agents consume programmatically.

What remains unclear from the sources is how well the skills generalize across frameworks. The documentation claims framework agnosticism—“Rules target design intent, not a single framework API” [1]—but the GSAP animation skeletons and Tailwind references suggest a web-centric, React-adjacent default. Whether the same discipline transfers cleanly to native mobile, desktop, or emerging platforms is not addressed.

The project also does not solve the deeper problem: agents still generate code, and generated code still needs maintenance. Taste Skill improves the first impression but does not address what happens in month six when requirements change and no human ever internalized the design logic. It is, by its nature, a surface-level intervention.

The Outlook

Taste Skill represents a plausible future for AI-assisted development: not bigger models or more context, but better constraints. The insight is that agent output quality may depend less on raw capability than on the specificity of the instructions fed into it. A well-written SKILL.md might outperform a larger model with vaguer guidance.

The repository’s trajectory suggests continued specialization. More visual styles, tighter integration with image generation pipelines, and possibly industry-specific variants. The changelog and active v2 iteration indicate a maintainer engaged with real usage feedback [1].

Whether this approach scales beyond individual developers to design teams and organizations depends on whether taste can truly be specified—or whether the project becomes its own form of slop, a different uniform replacing the purple gradient. For now, it is one of the more thoughtful attempts to make AI-generated interfaces look like someone cared.