Writing Anti-Slop Design Review Rules for Taste Skill Checklists
This skill teaches you how to author concrete, testable checklist rules inside SKILL.md files that catch the most common AI-generated UI anti-patterns, such as oversized padding, default border-radius, and bland color choices, before code ships to production.
Define each rule as a concrete, testable assertion in your SKILL.md file. Target the most common taste skill anti slop patterns: oversized padding, default border-radius values, bland neutral-only palettes, and uniform font sizing. State the anti-pattern, the threshold that triggers a violation, and the corrective action. Structure rules so an AI agent or human reviewer can evaluate pass/fail without subjective judgment.
Outcome: You produce a SKILL.md checklist of 10-25 concrete, testable anti-slop rules that an AI coding agent or human reviewer can evaluate as pass/fail, catching the most frequent AI-generated UI quality issues before they reach production.
Prerequisites
- Basic understanding of CSS properties (padding, margin, border-radius, font-size, color)
- Familiarity with the SKILL.md file format used in the Taste Skill Frontend Design Framework
- Experience reviewing AI-generated frontend output in at least one agent tool (Cursor, Claude Code, v0, or similar)
- Working knowledge of your project's design system or design tokens, if one exists
Overview
AI coding agents produce functional frontends quickly, but they converge on a narrow band of visual defaults. Padding is uniformly generous, border-radius lands on the same safe value, color palettes stay in the gray-blue-white corridor, and typography flattens into a single weight at a single scale. The result is what practitioners in the Taste Skill Frontend Design Framework call "slop": UI that technically works but looks like every other AI-generated page on the internet. Writing anti-slop design review rules is the skill of translating visual taste into explicit, testable assertions that live inside SKILL.md checklist files.
The core problem this skill solves sits at the intersection of two workflows inside the Taste Skill Frontend Design Framework. First, you need rules that are precise enough for an autonomous AI agent to self-check its own output before presenting it to a human. Second, you need those same rules to be legible enough for a human design reviewer to scan quickly during a pull-request review. The artifact you produce is a section of your SKILL.md file, typically titled something like ## Anti-Slop Review Checklist, containing 10-25 rules. Each rule names the anti-pattern, specifies the threshold or condition that constitutes a violation, and prescribes the corrective action.
This skill sits upstream of auditing AI-generated frontends and downstream of authoring portable SKILL.md files. You write the rules first, then the audit process uses those rules as its scoring rubric. Success looks like a checklist that catches at least 80% of the visual sameness in AI-generated output on the first pass, without producing so many false positives that reviewers learn to ignore the list. A well-authored anti-slop checklist transforms vague feedback like "this looks generic" into specific, actionable items like "hero section padding exceeds 64px on all sides, reduce to 40px vertical / 24px horizontal."
How It Works
The mental model behind anti-slop rules is borrowed from linting. A CSS linter catches syntax problems. An anti-slop rule catches taste problems. The difference is that taste problems are contextual, so each rule needs to encode not just a threshold but the reasoning behind that threshold, because the AI agent reading the SKILL.md file needs to generalize the rule to novel layouts it has never seen before.
Every anti-slop rule has three components. The first is the pattern identifier: a plain-language description of the visual anti-pattern, written so that both a human and an LLM can recognize it in generated code. For example, "uniform padding on all four sides of a card component." The second is the violation threshold: the specific condition that makes this instance a problem rather than a reasonable design choice. "Padding exceeds 48px on any side of a card, or all four sides use the same value." The third is the corrective directive: what the agent or reviewer should do instead. "Use asymmetric padding with vertical padding 1.5-2x horizontal padding, and keep the largest value under 40px for cards at standard viewport widths."
The reason this three-part structure works is that AI agents respond well to constraints stated as boundaries rather than as aspirations. Telling an agent "use tasteful spacing" produces the same default output every time. Telling it "vertical padding must be 1.25-2x horizontal padding, and no single padding value should exceed 48px on a card" gives it a concrete envelope to operate within while still allowing creative variation. This is the core insight of the taste skill anti slop philosophy: taste is not the absence of rules, it is the presence of the right constraints.
Rules also need a severity level. Not every violation is equally damaging. A bland color palette might be a "warning" that suggests improvement, while a hero section with 120px of padding on every side is a "blocker" that should prevent shipping. Encoding severity prevents checklist fatigue, where reviewers see so many flags that they stop reading. Aim for no more than 3-5 blocker-level rules and 7-15 warning-level rules in a single SKILL.md checklist section.
Finally, rules should reference your design tokens or system values when they exist. A rule that says "padding must not exceed var(--space-8)" is more maintainable and portable than one that says "padding must not exceed 32px," because the token carries the design intent across themes and breakpoints. The Taste Skill Frontend Design Framework encourages token-referenced rules wherever possible, falling back to pixel thresholds only when no token system is in place.
Step-by-Step
Step 1: Catalog the Most Frequent AI-Generated Anti-Patterns
Before writing any rules, you need a concrete inventory of what "slop" looks like in your specific project context. md constraints active. Screenshot each output. Then annotate the screenshots, circling every element that looks generic, oversized, or visually flat.
Common findings include: uniform padding on all sides of containers, border-radius values that are all 8px or 12px, color palettes limited to gray-50 through gray-900 with one blue accent, typography that uses only two font sizes with no weight variation, and buttons that are all the same size regardless of hierarchy. Write each anti-pattern as a one-line description. You should end this step with a list of 12-20 raw anti-pattern observations.
Tip: Run the same prompt through two different AI agents (e.g., Cursor and v0) and compare their outputs. The anti-patterns they share are the highest-priority targets because they represent the strongest defaults in current LLMs.
Step 2: Group Anti-Patterns into Categories
Take your raw list from Step 1 and group the observations into 4-6 categories. The standard categories in the Taste Skill ecosystem are: Spacing (padding, margin, gap), Typography (font-size, font-weight, line-height, letter-spacing), Color (palette breadth, contrast, accent usage), Shape (border-radius, borders, shadows), Layout (visual density, whitespace distribution, alignment variety), and Motion (transitions, hover states, micro-interactions). Some observations will fit multiple categories. Assign each to the category where the corrective action is most clear.
For example, "buttons all look the same" is a Shape/Color issue if the problem is visual, or a Layout issue if the problem is sizing hierarchy. md file will organize rules by category, making it easier for agents to apply the right rules to the right components.
Tip: If more than half your anti-patterns fall into a single category, that is a signal you need to invest more design thinking into that area before writing rules. The rules will be shallow if your understanding of the problem space is shallow.
Step 3: Define Violation Thresholds for Each Anti-Pattern
For each anti-pattern, define the specific condition that constitutes a violation. This is the hardest step because it requires you to translate aesthetic judgment into a numeric or structural boundary. 25-2x horizontal padding). For typography, require a minimum number of distinct font-size steps (at least 3) and a minimum number of font-weight values (at least 2).
For color, require at least one non-gray, non-blue accent color and a minimum of 4 distinct hues across the full page. , no radius above 16px except for avatar circles and pills). Write each threshold so that it could be evaluated by reading the CSS or Tailwind classes alone, without needing to render the page.
Tip: When in doubt, make the threshold slightly stricter than you think is necessary. It is easier to relax a rule after testing than to tighten one that agents have already learned to work around.
Step 4: Write the Corrective Directive for Each Rule
For each violation threshold, write a clear directive that tells the agent or reviewer what to do instead. The directive must be specific enough to act on without further clarification. " Good example: "Reduce card padding to 16-24px horizontal and 20-32px vertical. " Each directive should suggest a range rather than a single value, because a range preserves creative latitude while eliminating the worst defaults.
If your project has design tokens, reference them by name.
Tip: Read each directive out loud. If it sounds like it could apply to any project, it is too generic. The best directives reference your actual components, your actual tokens, or your actual viewport targets.
Step 5: Assign Severity Levels
" A blocker is a violation so visually damaging that the component should not ship until it is fixed. A warning is a taste improvement that should be addressed but does not prevent shipping. The distinction is critical for agent behavior: if everything is a blocker, the agent will either fix everything (slow) or ignore everything (useless). Limit blockers to 3-5 rules that address the most egregious anti-patterns: typically uniform oversized padding, single-weight typography, and monochrome color palettes.
Everything else is a warning. Document the severity inline in each rule using a consistent format such as
[BLOCKER]or[WARNING]at the start of the rule line.Tip: If you are unsure whether a rule should be a blocker, apply this test: would a non-designer stakeholder notice this problem in a 3-second glance at the page? If yes, it is a blocker. If it takes a trained eye to spot, it is a warning.
Step 6: Format Rules into SKILL.md Syntax
md conventions of the Taste Skill ecosystem. Use a level-2 heading like
## Anti-Slop Review Checklist. ,### Spacing,### Typography). Under each category, list rules as markdown checklist items using- [ ]syntax so that reviewers can check them off during a review.Each checklist item should follow the format:
[SEVERITY] Anti-pattern description. Threshold: [violation condition].Keep each rule to 1-3 lines. If a rule needs a code example, indent it as a fenced code block beneath the checklist item.Place the most critical blockers at the top of each category section so they are seen first.
Tip: Use consistent terminology across all rules. If you call it "padding" in one rule and "inner spacing" in another, an AI agent may treat them as different concepts. Pick one term per property and stick with it throughout the file.
Step 7: Test the Checklist Against AI-Generated Output
md checklist in the agent's context. Compare the new output against the old screenshots. For each rule, record whether the agent followed it, partially followed it, or ignored it. Rules that the agent consistently ignores need rewriting: they are likely too vague, too complex, or contradicted by another instruction in the prompt.
, a padding rule that makes the agent eliminate all padding) need their thresholds adjusted. Aim for at least 80% compliance on the first generation. Document any rules that need revision and iterate. This testing step typically takes 2-3 rounds before the checklist stabilizes.
Tip: Test with at least two different component types (e.g., a landing page hero and a settings form) to ensure your rules generalize. Rules that only work for one layout pattern are too narrow.
Step 8: Add Contextual Exceptions
Some rules need exceptions for specific contexts. A border-radius rule that caps at 16px should explicitly exempt avatar images and pill-shaped tags. A padding rule designed for cards should not apply to full-bleed hero sections. Document exceptions inline with each rule using a "Exception:" note.
For example:
Exception: Full-bleed hero sections may use up to 80px vertical padding.Without explicit exceptions, the agent will either apply the rule everywhere (creating new problems) or learn to circumvent it everywhere (defeating the purpose). Limit exceptions to 1-2 per rule. If a rule needs more than 2 exceptions, it is too broad and should be split into multiple narrower rules.Tip: Frame exceptions in terms of component names from your design system rather than abstract descriptions. "Exception: Avatar component" is clearer to an agent than "Exception: small circular imagery."
Step 9: Document Rule Rationale for Human Reviewers
Add a brief rationale comment beneath each rule or category explaining why this rule exists. The rationale is not for the AI agent (which follows rules regardless of reasoning) but for human teammates who might question or modify the checklist later. A good rationale is 1-2 sentences: "Uniform padding makes every card look like a Bootstrap default. " Store rationales as markdown block quotes or HTML comments depending on whether you want them visible in rendered documentation.
This step is easy to skip but prevents rule decay over time, where team members remove rules they do not understand and the checklist gradually loses its teeth.
Tip: Write rationales as if explaining to a junior developer who asks "why can't I just use p-8 on everything?" If you cannot articulate the taste reasoning, the rule may be arbitrary and should be reconsidered.
Examples
Example: Solo Developer Building a SaaS Dashboard
A solo developer uses Cursor to generate a SaaS analytics dashboard. They have no design system and no design tokens. The AI-generated output uses p-8 (32px) uniformly on all cards, a single gray palette with blue-500 as the only accent, border-radius-lg (8px) on every element, and two font sizes (14px and 16px) throughout the entire interface.
md constraints and screenshots them. They annotate 14 anti-patterns across the three views, grouped into Spacing (5), Color (4), Typography (3), and Shape (2). For Spacing, they write: "[BLOCKER] Card components must not use uniform padding. Threshold: all four padding values are identical AND any value exceeds 24px.
" For Color, they write: "[BLOCKER] Page must use at least 2 hue families beyond gray. Threshold: all non-gray colors are variants of a single hue. " They test the 10-rule checklist against the same prompts. Cursor now generates cards with px-4 py-5, introduces an amber accent for warning states, and uses 3 font sizes.
Compliance hits 90% on the first generation. md.
Example: Design Team at a B2B Startup with an Existing Design System
A 4-person product team uses Claude Code to scaffold new feature pages. They have a Tailwind-based design system with tokens for spacing, color, and typography. The AI output mostly follows their Tailwind config but defaults to the safest values: always space-4 or space-8, never space-3 or space-5, and ignores their secondary and tertiary brand colors entirely.
The design lead generates 5 feature pages and catalogs 18 anti-patterns. Because they have tokens, their rules reference config values directly. Example Spacing rule: "[WARNING] Components should use the full spacing scale. Threshold: a page uses fewer than 4 distinct spacing tokens from the project's Tailwind config.
Fix: Introduce at least space-3, space-5, or space-6 in addition to space-4 and space-8. " Example Color rule: "[BLOCKER] Feature pages must use at least one instance of the secondary brand color (brand-secondary-500 through brand-secondary-700). Threshold: zero instances of any secondary brand token on a page with more than 3 sections. " They assemble 15 rules, test across 5 component types, find 2 rules that conflict with their modal component's intentionally uniform padding, add exceptions, and ship the checklist.
After two sprints, the team observes that Claude Code's output requires 40% fewer design revision comments in pull requests.
Example: Agency Producing Marketing Sites for Multiple Clients
A digital agency uses v0 to prototype marketing landing pages for clients. Each client has a different brand, so the anti-slop checklist needs to be portable across projects. The agency notices that v0 output converges on the same hero layout: centered text, large padding, rounded button, stock gradient background.
The agency's lead developer creates a base anti-slop checklist with 12 rules that are brand-agnostic. They avoid pixel values entirely and use relative constraints. Example Layout rule: "[BLOCKER] Hero sections must not center-align all text elements. Threshold: hero heading, subheading, and CTA are all text-center with no left-aligned or asymmetric element.
" Example Shape rule: "[WARNING] Button border-radius must vary by hierarchy level. Threshold: primary, secondary, and tertiary buttons all share the same border-radius value. -- customize: -->` comment where project-specific values can be inserted. When onboarding a new client, the developer copies the base checklist, fills in the customize comments with the client's brand tokens, and tests against 2 sample pages.
The base checklist catches 75% of slop patterns out of the box, and client-specific customizations bring coverage to ~90%. The agency reduces design iteration cycles from 4 rounds to 2 on average.
Example: Open-Source Maintainer Publishing a Community SKILL.md
An open-source maintainer wants to publish a general-purpose anti-slop checklist that any developer can drop into their AI coding agent. The checklist must work without any design system, any specific Tailwind config, or any project context beyond "this is a web UI."
The maintainer collects anti-pattern screenshots from 20 different AI-generated pages shared in community forums and Discord servers. They identify the 8 most universal anti-patterns that appear in 75%+ of samples: uniform padding above 32px, single border-radius value across all elements, fewer than 3 font sizes, fewer than 2 font weights, monochrome palette (gray only), identical button styling for all hierarchy levels, no hover state differentiation, and centered-everything layouts. They write 8 blocker rules and 5 warning rules using only pixel thresholds and plain CSS property names (no framework-specific classes). -- if-using-tailwind: -->` annotation showing the Tailwind equivalent.
They test the checklist across Cursor, Claude Code, and Gemini CLI by generating a blog homepage, a pricing page, and a settings form with each agent. Rules that fail on one agent but pass on others are reworded for clarity. The final 13-rule checklist is published to GitHub with a CC0 license. Within a month, 200+ developers have forked the file and 15 have submitted pull requests adding framework-specific annotations for Chakra UI and Shadcn.
Best Practices
Write rules as falsifiable assertions, not aspirations. Every rule should be evaluable as pass or fail by reading the generated code. "Use interesting colors" is not falsifiable. "Page must include at least 3 distinct hue families beyond gray" is falsifiable. If you cannot describe how to check a rule, rewrite it until you can.
Keep the total rule count between 10 and 25 for a single SKILL.md checklist section. Fewer than 10 rules will miss important anti-patterns. More than 25 rules overwhelms both AI agents (which have finite context windows) and human reviewers (who will stop reading). If you have more than 25 rules, split them across multiple SKILL.md files organized by concern area.
Reference your design tokens or Tailwind config values in rules whenever possible. Token-referenced rules like "padding must not exceed var(--space-6)" survive design system updates automatically, while pixel-hardcoded rules like "padding must not exceed 24px" silently drift out of sync when your spacing scale changes.
Update the checklist quarterly or whenever you notice a new category of AI-generated slop appearing in reviews. LLM defaults shift as model weights change, and a checklist written for GPT-4 output may miss patterns introduced by newer models. Treat the checklist as a living document, not a one-time artifact.
Test every rule against at least two distinct component types before shipping it to the team. A rule that works perfectly for cards but breaks navigation bars is not ready for production. Broad testing surfaces overly specific thresholds and missing exceptions before they cause frustration.
Place blocker-level rules at the top of each category section in the SKILL.md file. Both AI agents and human reviewers process content top-down, and the most critical violations should be encountered first. If a reviewer only reads the first three rules per category, those three should be the ones that matter most.
Include at least one concrete before/after code snippet in your checklist. Abstract rules are interpreted more consistently when accompanied by a specific example showing the anti-pattern CSS and the corrected CSS side by side. One good example anchors the interpretation of all surrounding rules.
Version your SKILL.md checklist files using a simple date stamp or semver comment at the top of the section (e.g.,
<!-- anti-slop-checklist v1.2 | 2025-06-15 -->). This makes it possible to correlate changes in AI output quality with specific checklist revisions and to roll back if a new rule introduces regressions.
Common Mistakes
Writing rules that describe desired outcomes instead of observable violations
Correction
Rules like "the UI should feel polished" or "typography should have good hierarchy" are not actionable for an AI agent because they contain no testable condition. The agent has no way to evaluate "feel" or "good." Rewrite every rule to reference a specific CSS property, a numeric threshold, or a structural condition. Instead of "typography should have good hierarchy," write "the page must use at least 3 distinct font-size values and at least 2 distinct font-weight values." You can spot this mistake by searching your checklist for subjective adjectives: "good," "better," "nice," "clean," "modern." Every one of those words signals a rule that needs rewriting.
Setting thresholds so tight that every AI generation fails the entire checklist
Correction
This happens when you write the checklist based on your ideal design rather than on realistic AI output. If every generation fails 90% of the rules, the agent either gives up and ignores the checklist or enters an infinite revision loop. The signal to watch for is the agent producing wildly different output on successive retries without converging on a solution. Calibrate by testing your thresholds against 3-5 unconstrained AI generations and setting blockers only for violations that appear in 80%+ of those generations.
Everything else starts as a warning. You can always promote warnings to blockers after the agent demonstrates consistent compliance.
Omitting exceptions, causing rules to break valid edge cases
Correction
A maximum border-radius rule that does not exempt circular avatars will force the agent to render square profile pictures. A maximum padding rule that does not exempt hero sections will produce cramped landing pages. This mistake is especially insidious because the rule appears to work during initial testing on simple components and only breaks when applied to a full page with diverse component types. Prevent it by testing each rule against at least one "exception-likely" component (heroes, avatars, modals, full-bleed sections) and adding explicit exceptions before shipping.
Writing too many rules in a single pass without testing incrementally
Correction
Teams often try to catalog every possible anti-pattern in one session and produce a 40-rule checklist before testing any of them. The result is rules that conflict with each other, thresholds that do not match real AI output, and a checklist so long that neither agents nor humans engage with it fully. Instead, write 5-8 rules, test them, iterate, then add the next batch. Each batch should be tested in isolation and then in combination with all previous rules.
The incremental approach surfaces conflicts early, when they are cheap to resolve.
Duplicating rules that belong in sibling SKILL.md files
Correction
If you are writing a spacing rule that duplicates what already exists in your typography and spacing SKILL.md file, you create a maintenance burden and risk contradictions when one file is updated but not the other. Before writing a new rule, check the sibling skill files in your project, especially those covering typography and spacing standards and layout density constraints. Your anti-slop review checklist should reference those files for detailed thresholds and add only the review-oriented pass/fail framing that those files lack.
Neglecting to specify which components or scopes a rule applies to
Correction
A rule that says "padding must not exceed 32px" without specifying whether it applies to cards, sections, modals, or the entire page will be interpreted differently by different agents and reviewers. Some agents will apply it globally, creating cramped layouts in places where generous padding is appropriate. Others will apply it only to the component they are currently generating, missing violations in surrounding context. Every rule should state its scope explicitly: "For card and list-item components, padding must not exceed 32px on any side." Unscoped rules are the most common source of false positives in anti-slop checklists.
Other Skills in This Method
Enforcing Typography and Spacing Standards in AI-Generated UI
Teaches how to write and apply SKILL.md rules that govern font sizing, line height, letter spacing, whitespace, and visual density to eliminate generic-looking layouts.
Adding Motion and Interaction Taste Rules
How to specify animation timing, easing curves, hover states, and transition guidelines in SKILL.md files so AI-generated interfaces feel polished and intentional.
Configuring Layout and Visual Density Constraints for AI Agents
Teaches how to define grid, container, and density rules inside skill files so AI agents produce tighter, more intentional page compositions instead of loosely spaced defaults.
Auditing AI-Generated Frontends for Design Quality
A structured review workflow for evaluating AI-produced React and Next.js interfaces against Taste Skill criteria covering hierarchy, contrast, alignment, and component consistency.
Installing SKILL.md Files in AI Coding Agents
How to set up and configure Taste Skill instruction files in tools like Cursor, Claude Code, Codex, Gemini CLI, and v0 so your agent follows design-quality rules.
Authoring Portable SKILL.md Files for Design Systems
Teaches how to create reusable, framework-agnostic SKILL.md instruction files that encode your team's design-system tokens, component conventions, and aesthetic judgment for any AI agent.
Frequently Asked Questions
How many anti-slop rules should a single SKILL.md checklist contain?
Aim for 10-25 rules total, with no more than 3-5 marked as blockers. Fewer than 10 rules will miss important patterns, while more than 25 will overflow the context window of some AI agents and cause human reviewers to skim rather than read. If you have more rules than 25, split them into separate SKILL.md files organized by concern (spacing, color, typography).
Should I write anti-slop rules before or after installing SKILL.md files in my AI coding agent?
Write rules after you have generated at least 3-5 sample outputs from your agent without any constraints. You need to see what the agent's defaults actually produce before you can write targeted rules against those defaults. Once you have your initial catalog of anti-patterns, write the rules, then install them following the steps in the [installing SKILL.md files](/skills/installing-skill-files-in-ai-coding-agents) guide. The two skills are sequential, not interchangeable.
How do I write anti-slop rules for a project that uses a component library like Shadcn or Chakra UI?
Target the component library's default prop values rather than raw CSS. For example, instead of "border-radius must not exceed 12px," write "Button component must not use the default 'md' radius variant on all instances. Primary buttons should use 'lg' or 'full', secondary buttons should use 'sm' or 'none'." Reference the library's variant names in your thresholds. This makes rules more readable for agents that understand the library's API and prevents conflicts with the library's internal styles.
How often should I update my anti-slop checklist?
Review the checklist at least quarterly and after any major model update from your AI agent provider. LLM defaults shift as model weights change, so patterns that were common in GPT-4 output may not appear in GPT-4.1 output, and new patterns may emerge. Also update whenever your design system or Tailwind config changes, because token-referenced thresholds may need to be adjusted to match new scale values.
Why does my anti-slop checklist produce different results in different AI agents?
md instructions slightly differently based on its underlying model, system prompt, and context window handling. A rule that Cursor follows precisely may be partially ignored by Claude Code if the wording is ambiguous. Fix this by writing rules with zero ambiguity: use exact property names, exact threshold values, and explicit scope. Test each rule across at least two agents before finalizing. Rules that one agent ignores consistently likely need rephrasing, not removal.
Can I auto-enforce anti-slop rules with a linter instead of a SKILL.md checklist?
Partially. Some rules (maximum padding values, minimum font-size count, border-radius variety) can be implemented as Stylelint or ESLint rules that run in CI. This is ideal for blocker-level rules. , "hero sections may use larger padding than cards") and require layout awareness that current linters do not have. md for agent and human review.
How do I handle team disagreements about what counts as slop?
Ground the debate in observable evidence rather than personal preference. Generate 5 sample pages without constraints, have each team member independently annotate the anti-patterns they see, then compare annotations. Patterns that 80%+ of the team flags are consensus blockers. Patterns that only one person flags are either personal preferences (drop them) or genuine issues that need educating (add them as warnings with a rationale comment explaining the reasoning). The annotation exercise usually resolves 90% of disagreements because most slop is objectively repetitive rather than subjectively ugly.