How Anti-Patterns Are Parsed and Categorized from the Frontend-Design Skill in Impeccable

The frontend-design skill encodes design anti-patterns as **DON'T**: statements under semantic headings, which downstream skills parse by scanning source/skills/frontend-design/SKILL.md for these markers and categorizing them by their nearest preceding level-2 heading.

The pbakaus/impeccable repository implements a structured approach to design quality by treating anti-patterns as machine-readable rules. This article explains how the frontend-design skill stores these rules and how downstream automation parses and categorizes them for use in auditing, distilling, and delight workflows.

How Anti-Patterns Are Stored in the Frontend-Design Skill

The frontend-design skill defines anti-patterns as explicit prohibitions within a markdown source file. Each rule follows the syntax **DON'T**: (or **DON’T**: with a curly apostrophe) and appears beneath a level-2 heading that serves as its semantic category.

The eight categories defined in source/skills/frontend-design/SKILL.md are:

• Typography – Rules about overused fonts, monospace misuse, and decorative clutter
• Color & Theme – Prohibitions against pure black/white, gray-on-color text, and AI-style neon palettes
• Layout & Space – Avoidance of card-grid uniformity and excessive centering
• Visual Details – Restrictions on glass-morphism abuse and generic dropshadows
• Motion – Limits on animating layout properties and bounce easing
• Interaction – Guidance against redundant copy and over-primary buttons
• Responsive – Preventing functionality hiding on mobile
• UX Writing – Eliminating verbose repetition of visible information

Parsing Algorithm and Categorization Logic

When downstream skills such as audit, distill, or delight need to validate designs against these rules, they execute a four-step parsing process:

1. Load the markdown source from source/skills/frontend-design/SKILL.md

2. Scan each line for the pattern **DON'T**: using case-insensitive matching

3. Track the most recent level-2 heading (## Category Name) to assign a category

4. Collect the remaining text on the line as the anti-pattern description

This state-machine approach ensures that every anti-pattern is automatically categorized according to its document structure, requiring no manual tagging or external metadata files.

Reference Implementation: Extracting Anti-Patterns with JavaScript

A minimal parser that implements this logic reads the skill file line-by-line, tracks the current category via regex matching on headings, and extracts rules using a case-insensitive match for the DON'T marker:

// Example: extract anti-patterns from the frontend-design skill
import fs from 'fs';
import path from 'path';

const skillPath = path.resolve(
  __dirname,
  '..',
  'source/skills/frontend-design/SKILL.md'
);
const lines = fs.readFileSync(skillPath, 'utf8').split('\n');

const antiPatterns = {};
let currentCategory = 'Uncategorized';

for (const line of lines) {
  // Detect a heading that introduces a category
  const headingMatch = line.match(/^##\s+(.*)/);
  if (headingMatch) {
    currentCategory = headingMatch[1].trim();
    continue;
  }

  // Detect a DON'T rule
  const dontMatch = line.match(/^\*\*DON'T\*\*:\s*(.+)/i);
  if (dontMatch) {
    const rule = dontMatch[1].trim();
    if (!antiPatterns[currentCategory]) antiPatterns[currentCategory] = [];
    antiPatterns[currentCategory].push(rule);
  }
}

console.log(JSON.stringify(antiPatterns, null, 2));

Running this script yields a structured JSON map where each key corresponds to a design domain and each value contains an array of specific prohibitions:

{
  "Typography": [
    "Use overused fonts—Inter, Roboto, Arial, Open Sans, system defaults",
    "Use monospace typography as lazy shorthand for \"technical/developer\" vibes",
    "Put large icons with rounded corners above every heading—they rarely add value and make sites look templated"
  ],
  "Color & Theme": [
    "Use gray text on colored backgrounds—it looks washed out; use a shade of the background color instead",
    "Use pure black (#000) or pure white (#fff)—always tint; pure black/white never appears in nature",
    "Use the AI color palette: cyan‑on‑dark, purple‑to‑blue gradients, neon accents on dark backgrounds",
    "Use gradient text for \"impact\"—especially on metrics or headings; it's decorative rather than meaningful",
    "Default to dark mode with glowing accents—it looks \"cool\" without requiring actual design decisions"
  ]
}

Downstream Consumption in Audit and Distill Skills

Once parsed, the categorized anti-patterns enable automated design review. The audit skill consumes this data to flag violations in content, while the distill skill references the rules when extracting design principles.

The following example demonstrates how a downstream skill might import the parsed anti-patterns and check content against the Color & Theme category:

import { getAntiPatterns } from './utils/antiPatterns.js'; // the parser above

export function auditDesign(content) {
  const antiPatterns = getAntiPatterns(); // map of category → rules
  const violations = [];

  // Example: flag any occurrence of a known gradient‑text anti‑pattern
  if (/gradient\s+text/i.test(content)) {
    violations.push({
      category: 'Color & Theme',
      rule: antiPatterns['Color & Theme'].find(r => /gradient text/i.test(r))
    });
  }

  return violations;
}

For user-facing reports, the structured data can be rendered into markdown summaries:

function renderAntiPatternReport(violations) {
  let md = '# Anti‑Pattern Report\n\n';

  for (const { category, rule } of violations) {
    md += `- **${category}** – ${rule}\n`;
  }
  return md;
}

Key Files in the Anti-Pattern Pipeline

Several files in the pbakaus/impeccable repository implement and consume the parse-and-categorize workflow:

• source/skills/frontend-design/SKILL.md – Central definition of anti-patterns (DON'T rules) organized under each design domain heading
• scripts/screenshot-antipatterns.js – Utility to capture visual examples of anti-patterns for documentation and sharing
• source/skills/audit/SKILL.md – Consumes the anti-patterns list to check designs for violations during automated review
• source/skills/distill/SKILL.md – References anti-patterns when extracting and condensing design principles
• scripts/generate-og-image.js – Tracks anti-pattern counts for repository statistics and OG image generation

Summary

• Anti-patterns in the frontend-design skill are defined as **DON'T**: statements within source/skills/frontend-design/SKILL.md
• Categorization is determined by the nearest preceding level-2 heading (Typography, Color & Theme, Layout & Space, Visual Details, Motion, Interaction, Responsive, UX Writing)
• A line-by-line parser using regex matching extracts these rules into a structured JSON map for programmatic access
• Downstream skills including audit, distill, and delight consume this data to enforce high-quality, non-AI-slop frontend design standards

Frequently Asked Questions

What file format stores the frontend-design anti-patterns?

The anti-patterns are stored in standard markdown format within source/skills/frontend-design/SKILL.md. Each rule is written as a list item beginning with **DON'T**: (or **DON’T**:) beneath a level-2 category heading, making the rules human-readable while remaining easily parsable by automated tools.

How does the parser distinguish between different anti-pattern categories?

The parser maintains state by tracking the most recent level-2 heading (matched via ^##\s+(.*)). When it encounters a **DON'T**: statement, it assigns the current heading value as the category. This approach ensures that rules are automatically grouped according to the document structure without requiring inline metadata tags.

Which downstream skills consume these parsed anti-patterns?

According to the repository structure, the audit skill uses the parsed rules to validate designs for violations, the distill skill references them when extracting design principles, and the delight skill checks against them during design enhancement workflows. The scripts/screenshot-antipatterns.js utility also processes these rules to generate visual documentation.

Can the anti-pattern detection handle different apostrophe styles?

Yes, the parser implementation uses case-insensitive regex matching (/^\*\*DON'T\*\*:\s*(.+)/i) that recognizes both straight apostrophes (') and curly typographic apostrophes ('), ensuring that rules are captured correctly regardless of which character encoding appears in the markdown source.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}