How Taste-Skill Enforces an Em-Dash Ban: A Two-Layer Defense Strategy

Taste-Skill enforces an em-dash ban through a rigid two-layer defense combining an authoritative design contract stored in SKILL.md with an automated Pre-Flight Check that validates every LLM output for forbidden Unicode characters.

The Leonxlnx/taste-skill repository treats the em-dash (—) as a non-negotiable anti-pattern in UI generation. Understanding how taste-skill enforces an em-dash ban provides a blueprint for maintaining typographic consistency through both specification and automated validation, ensuring that no em-dash ever reaches the final product.

The Authoritative Design Contract in SKILL.md

At the foundation of the enforcement strategy sits the master design contract located in skills/taste-skill/SKILL.md. This document explicitly enumerates the prohibition, making the rule unambiguous for any contributor or consuming system.

At line 649, the specification states:

"NO em-dash (—) as a design element OR anywhere else. See Section 9.G below for the complete, non-negotiable ban."

The same guarantee is reiterated at lines 687-699, where the document mandates that any output containing even a single em-dash (U+2014) or en-dash (U+2013) automatically fails the Pre-Flight Check and must be rewritten. This design-time specification applies to all user-visible text, including headlines, body copy, captions, button labels, and alt text.

Runtime Validation: The Pre-Flight Check

While the SKILL.md establishes the policy, the skill.sh runtime harness provides the mechanical enforcement. Before any generated UI is emitted, Taste-Skill executes a lightweight sanity filter that scans raw LLM output for prohibited characters.

The validation layer specifically hunts for:

• Unicode U+2014 (em-dash: —)
• Unicode U+2013 (en-dash: –)

If the Pre-Flight Check detects either character, the request is marked as failed. The system then automatically triggers a regeneration request, forcing the LLM to rewrite the content without the offending punctuation. This guard operates as part of the core skill execution pipeline, ensuring that downstream skills only receive compliant output.

Implementation Examples

Below are practical patterns illustrating how the ban functions in code, derived from the repository's validation logic.

Detecting Forbidden Characters

This Python function mirrors the logic used in the Pre-Flight Check to identify violations:

def has_em_dash(text: str) -> bool:
    """Return True if the text contains any em-dash or en-dash."""
    return "—" in text or "–" in text

Aborting Generation on Violation

The runtime harness implements rejection logic similar to this bash pseudo-code, which executes immediately after LLM generation completes:

# Executed in skill.sh after LLM response

output=$(llm_generate ...)
if grep -q "[—–]" <<<"$output"; then
    echo "Pre-Flight Check failed: em-dash detected → request regeneration"
    exit 1
fi

# Continue with publishing only if validation passes

UI Component Compliance

Developers must replace em-dashes with standard hyphens in frontend code. Compare these Tailwind examples:

/* ❌ Pre-Flight Check will reject this */
<button className="px-4 py-2">Read—Now</button>

/* ✅ Compliant implementation */
<button className="px-4 py-2">Read-Now</button>

Handling Violations and Regeneration

When the Pre-Flight Check encounters a violation, the pipeline does not merely warn—it blocks publication. The system generates a failure signal that forces the LLM to reprocess the request. This hard failure mechanism ensures that no manual review bottleneck is required to catch typographic errors, as the automation guarantees zero em-dashes in production builds.

Summary

• Policy Documentation: The em-dash ban is explicitly codified in skills/taste-skill/SKILL.md at lines 649 and 687-699, applying to all user-facing text.
• Automated Enforcement: The skill.sh runtime harness executes a Pre-Flight Check that validates Unicode characters U+2014 and U+2013.
• Zero-Tolerance Behavior: Detection triggers automatic failure and regeneration, preventing non-compliant content from reaching the final product.
• Developer Pattern: Replace em-dashes and en-dashes with standard ASCII hyphens (-) in all UI components and copy.

Frequently Asked Questions

What specific characters does the Taste-Skill em-dash ban cover?

The ban covers Unicode U+2014 (em-dash: —) and Unicode U+2013 (en-dash: —). While the primary prohibition targets the em-dash, the Pre-Flight Check treats both characters as violations according to the specification in SKILL.md lines 687-699.

Where is the em-dash ban documented in the repository?

The authoritative source is skills/taste-skill/SKILL.md. Line 649 contains the explicit prohibition statement, while lines 687-699 detail the consequences for violating the rule during the Pre-Flight Check phase.

What happens if the Pre-Flight Check detects an em-dash?

The system marks the generation request as failed and automatically requests a regeneration from the LLM. This process repeats until the output contains no forbidden characters, ensuring that only compliant content proceeds to the final build stage.

Can the em-dash ban be disabled or overridden?

No. The SKILL.md explicitly designates the ban as "non-negotiable" (line 649). There is no configuration option or override mechanism in the skill.sh runtime harness that permits em-dashes in production output.

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