# How Anti-Patterns Are Parsed and Categorized from the Frontend-Design Skill in Impeccable > Learn how Impeccable parses and categorizes frontend-design anti-patterns. Discover the DON'T: marker system and level-2 heading categorization for efficient analysis. - Repository: [Paul Bakaus/impeccable](https://github.com/pbakaus/impeccable) - Tags: deep-dive - Published: 2026-03-09 --- **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`](https://github.com/pbakaus/impeccable/blob/main/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`](https://github.com/pbakaus/impeccable/blob/main/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`](https://github.com/pbakaus/impeccable/blob/main/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: ```javascript // 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: ```json { "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: ```javascript 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: ```javascript 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`](https://github.com/pbakaus/impeccable/blob/main/source/skills/frontend-design/SKILL.md)** – Central definition of anti-patterns (DON'T rules) organized under each design domain heading - **[`scripts/screenshot-antipatterns.js`](https://github.com/pbakaus/impeccable/blob/main/scripts/screenshot-antipatterns.js)** – Utility to capture visual examples of anti-patterns for documentation and sharing - **[`source/skills/audit/SKILL.md`](https://github.com/pbakaus/impeccable/blob/main/source/skills/audit/SKILL.md)** – Consumes the anti-patterns list to check designs for violations during automated review - **[`source/skills/distill/SKILL.md`](https://github.com/pbakaus/impeccable/blob/main/source/skills/distill/SKILL.md)** – References anti-patterns when extracting and condensing design principles - **[`scripts/generate-og-image.js`](https://github.com/pbakaus/impeccable/blob/main/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`](https://github.com/pbakaus/impeccable/blob/main/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`](https://github.com/pbakaus/impeccable/blob/main/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`](https://github.com/pbakaus/impeccable/blob/main/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.