# Why Em-Dashes Are Banned in taste-skill and How to Avoid Them
> Discover why em-dashes are banned in taste-skill to avoid generic LLM output and rendering issues. Learn how to replace them for better content.
- Repository: [Leon Lin/taste-skill](https://github.com/Leonxlnx/taste-skill)
- Tags: best-practices
- Published: 2026-06-05
---
**The taste-skill design system enforces a complete ban on em-dashes (`—`) in all user-facing content because they function as a primary "visual tell" identifying generic LLM-generated output while preventing Unicode rendering issues across browsers and localization pipelines.**
The Leonxlnx/taste-skill repository encodes a rigorous visual-design policy that treats the em-dash as a prohibited typographic element. Any occurrence of this character in production builds triggers an immediate pre-flight failure, requiring developers to eliminate it from headlines, body copy, button labels, and alt-text before deployment.
## Why taste-skill Considers Em-Dashes a "Signature Stylistic Crutch"
### The LLM Visual Tell
According to the taste-skill source code in [`skills/taste-skill/SKILL.md`](https://github.com/Leonxlnx/taste-skill/blob/main/skills/taste-skill/SKILL.md) (lines 649-699), the em-dash ranks as the **#1 visual indicator** that content was generated by a large language model rather than crafted by human designers. The character creates artificial pauses and decorative separators that make interfaces appear templated and low-quality. By enforcing a strict prohibition, taste-skill forces reliance on standard hyphens and approved typographic spacing, yielding cleaner, premium aesthetics.
### Technical Hygiene and Encoding Stability
Beyond design consistency, the ban addresses practical rendering concerns. The em-dash is a Unicode character (**U+2014**) that frequently causes encoding problems across CSS-generated content, browser rendering engines, and localization pipelines. Restricting punctuation to the plain hyphen (`-`) ensures assets remain compatible with SVG generation, markdown processing, and international character sets without requiring complex escape sequences.
## Scope of the Em-Dash Ban in taste-skill
The prohibition defined at line 687 of [`skills/taste-skill/SKILL.md`](https://github.com/Leonxlnx/taste-skill/blob/main/skills/taste-skill/SKILL.md) applies to **all user-visible text** without exception. This includes:
- Headlines and eyebrows
- Pills and tags
- Body copy and quotes
- Attributions and captions
- Button labels
- Image alt-text
The validation logic also extends to dependent skills such as `stitch-skill` and `soft-skill`, which inherit the em-dash restrictions from the core taste-skill policy defined at line 920.
## How to Replace Em-Dashes in taste-skill Projects
### Use Standard Hyphens
Replace every instance of `—` with a regular hyphen (`-`). This applies to decorative separators, pause indicators, and compound modifiers.
### Employ Alternative Emphasis Techniques
Rather than using em-dashes for dramatic pauses or emphasis, utilize **bold**, *italic*, or intentional whitespace within the same font family. Keep sentences concise and rely on native punctuation such as commas, periods, and colons to control rhythm.
### Pre-Flight Validation
The taste-skill build pipeline includes an automated validator that scans generated markup for Unicode character U+2014. If detected, the build aborts immediately, prompting you to edit the source text before redeployment.
## Code Examples: Correcting Em-Dash Violations
The following TypeScript/React examples demonstrate compliant replacements for common taste-skill components:
```tsx
// ❌ Bad – contains an em‑dash (will cause pre‑flight failure)
Design‑Driven — Fast, Elegant, Scalable
// ✅ Good – uses a normal hyphen
Design‑Driven – Fast, Elegant, Scalable
```
```tsx
// ❌ Bad – em‑dash inside button text
// ✅ Good – replace with hyphen or remove entirely
```
```tsx
// ❌ Bad – em‑dash in alt text (violates the rule in images)
// ✅ Good – use hyphen or split the phrase
```
## Summary
- **Em-dashes are banned** in taste-skill because they signal LLM-generated content and create encoding risks.
- The prohibition is enforced in [`skills/taste-skill/SKILL.md`](https://github.com/Leonxlnx/taste-skill/blob/main/skills/taste-skill/SKILL.md) (lines 649, 687, 699) and inherited by related skills like `stitch-skill`.
- **All user-visible text** must exclude U+2014, including headlines, buttons, and alt-text.
- Replace em-dashes with standard hyphens (`-`) and use bold or italic for emphasis.
- The pre-flight validator automatically detects violations and aborts builds containing em-dashes.
## Frequently Asked Questions
### What happens if I use an em-dash in a taste-skill project?
The build pipeline's pre-flight validator detects the Unicode U+2014 character and aborts the deployment immediately. You must remove the em-dash and replace it with a hyphen or alternative punctuation before the build will succeed.
### Can I use en-dashes or other special dashes instead?
No. The taste-skill policy specifically targets the em-dash (U+2014) as the primary "visual tell," but the design system standardizes on plain hyphens for all use cases to maintain consistency and avoid encoding complexity.
### Why does taste-skill consider em-dashes an LLM indicator?
According to the source code at line 649 of [`skills/taste-skill/SKILL.md`](https://github.com/Leonxlnx/taste-skill/blob/main/skills/taste-skill/SKILL.md), em-dashes appear repetitively in generic LLM outputs as decorative separators or artificial pause markers, creating a templated appearance that contradicts taste-skill's premium design standards.
### Does the em-dash ban apply to code comments or internal documentation?
The ban specifically targets user-visible text such as headlines, body copy, and button labels as defined at line 687. While the validator focuses on rendered markup, maintaining hyphen-only consistency across all project files aligns with taste-skill's technical hygiene principles.
// ✅ Good – use hyphen or split the phrase