--- name: professional-ascii-art description: | Design monospace ASCII art that doesn't look like a 1990s BBS sig file. Covers the difference between crude novelty art and pieces that hold their own in product surfaces — terminal banners, install pitches, README headers, MCP tool responses, dev-tool first-runs. Decisions on character density, line weight, silhouette, scale, mood variants, and where ASCII fails (you'll know when to use a real image instead). argument-hint: "[banner | mascot | logotype | divider | mood-set]" user-invocable: true --- # Professional ASCII Art ASCII art has two tiers. The first is **novelty** — `=^.^=`, `(\__/)`, three lines of dashes called "MY COMPANY". The second is **product** — art that *belongs* in the surface it ships in. Same characters, completely different craft. This skill is about the second. ## When to use ASCII art at all ✅ Right context: - Terminal-first products (CLI tools, MCP servers, dev tools) - First-install pitches, banner headers, mascots in tool output - Dev surfaces where graphics aren't an option (postinstall logs, `--help`) - Mood / personality conveyance where a real image would feel out of place ❌ Wrong context: - Web UIs that can render images — use SVG instead - Marketing material outside terminal contexts - When the art would be larger than the message it accompanies - When the art doesn't actually evoke the subject (a "dragon" that reads as a blob is worse than no dragon at all) ## The ten principles ### 1. Silhouette beats detail Mono lacks anti-aliasing, sub-pixel rendering, color depth. **Silhouette is your only true tool.** A clear, recognizable outline at 10 lines beats an ambiguous detailed piece at 30. Squint at your art — if you can't read what it is at squint, simplify the silhouette before adding more detail. ### 2. Side-profile reads better than 3/4 or front view For figures (dragons, animals, people), side-profile is the most parseable silhouette in mono. Front view requires symmetric facial features that fight the rectangular character grid; 3/4 views need subtle perspective the grid can't honor. **Use side-profile by default.** ### 3. Character density should match visual mass Heavier characters convey mass and shadow: ``` █▓▒░ (heavy → light shading — full block, dark, medium, light) ``` Lighter characters convey outline and form: ``` ─━│┃┌┐└┘╱╲ (box-drawing — clean lines) ,.;'`~"_ (negative-space punctuation — soft edges) ^v<> (directional pointers) /|\-_= (slope and weight) ``` **Don't mix tiers**. A piece using `█▓▒░` shading with `/_\` outlines looks like two different drawings glued together. Pick a register and stay in it. ### 4. Width discipline Terminals are 80 columns. Phones (Termux operators) are 60-72 columns. **Cap at 72 columns** for anything that needs to render on a phone; cap at 60 for embedded responses (like MCP tool outputs that have prefixes / indentation already eating columns). Lines over budget get chopped — kills the silhouette faster than anything. ### 5. Vertical economy Every line costs scroll. Banners are ~6-10 lines. Mascots / characters ~10-15 lines. Anything past 20 lines starts to feel like a screen-saver demo. **Aim for the smallest line count that still preserves silhouette clarity** (principle 1). When in doubt, shrink. ### 6. Negative space is a feature What you *don't* draw is half the design. ASCII art that fills every cell looks like static. Leave room — characters need air around them to read as shape. **Roughly 40-60% of the bounding box should be whitespace** for clean mascots; tighter for dense banners, looser for ethereal pieces (a wyrm in mist needs more space than a stone golem). ### 7. Anchor with one strong feature The reader needs **one unmistakable anchor** to lock onto. For a face: the eye. For a building: a clear roof line or arch. For a creature: head + horn silhouette. Make the anchor the most detailed part; everything else can be suggestion. Crude pieces try to detail everything equally; professional pieces hierarchize. ### 8. Test in the actual font What looks good in your editor's font can be unreadable in the user's terminal. **Test in:** - A monospace terminal at 1.0 line-height - A phone terminal (Termux is the test bed) - A web markdown renderer (some collapse repeated spaces) If line spacing or character width differs from your design, redraw at the target's metrics. Don't ship art that only works in Cascadia Code. ### 9. Mood is in the eye, not the body If you need mood variants (default / celebratory / stuck / alert), **change only the face / eye region**, not the whole figure. Keeps recognition consistent across moods; the reader instantly sees "same character, different state." Common eye sets: | Mood | Eyes | Mouth | Aura | |---------------|-------|---------|------| | Default | `o o` | `___` | — | | Celebratory | `^ ^` | `\_/` | `*` | | Stuck | `- -` | `___` | `?` | | Alert | `* *` | `O` | `!` | | Tired | `~ ~` | `___` | — | ### 10. Sign your style Recurring product mascots benefit from one signature flourish — a curl, a glint, a particular wing shape. Makes the mascot recognizable across contexts (banner, mood variants, future iterations). For Wyrm, the signature is the **`=`-segmented body** suggesting scales / a coiled spine. ## Common amateur tells (avoid these) - Mixing `/` and `\` as if they're symmetric — they're not in most fonts; `/` is heavier-right, `\` heavier-left. Pair them only when the figure is symmetric and the fight cancels out. - Using `oOoOo` for "scales" — they read as bubbles, not scales. Use `===` or `~~~` instead. - Drawing fire with `^^^^^` — reads as upward arrows, not flame. Use `({)(} ` or `~*~` for flame. - Adding text inside the figure (`"Hi I'm a dragon"`) — that's the joke art signature of the 90s. - Over-using emoji as substitute eyes — `(👁️ 👁️)` is wider than the surrounding mono and breaks alignment. Stay in ASCII or commit fully to emoji, never mix. - Trailing whitespace — strips out in some renderers (Discord, some MCP clients), breaking the right side of the figure. Hard-pad with `.` or trim and accept the asymmetry. ## A walkthrough — designing the Wyrm mascot Brief: "iconic wyrm dragon for the Wyrm MCP buddy. Mythic, sleek, not cute. Mood variants. Fits in ~12 lines, ≤60 cols. Default `wyrm` persona only; other personas skip the art." ### Step 1: pick view + silhouette Side-profile (principle 2). Coiled / flying serpentine wyrm — body curves suggest scale + motion (principle 7 anchor: the head + eye). ### Step 2: bounding box + line budget 12 lines tall × 50 cols wide. Reserves 10 cols of breathing room either side when rendered in a 70-col MCP response. ### Step 3: draft the silhouette ``` ,_ _, |\\___//| |====| \ V / \ ~ / ||| .===._/|||\_.===. \\\\\\=' | '=////// `==._ | _.==' `'._|_.'` ||| ''' ``` Read it: horns (`,_ _,`), head with eye (``), nose ridge (`V`), mouth/breath (`~`), neck (`|||`), wings (`===._ _.===` and `\\\\\\=' '=//////`), body (`|||`), feet (`'''`). 12 lines, 50 cols. Clear silhouette at squint. ### Step 4: mood variants — change only the eye line ``` Default: |====| Celebratory: |==<^>==| * (with sparkle at row above) Stuck: |==<->==| (with "?" trailing) Alert: |==<*>==| Tired: |==<~>==| ``` Keeps the figure recognizable across moods (principle 9). ### Step 5: signature flourish The `===._` / `_.===` wing motif + the `=`-segmented neck are the signature. Future Wyrm mascot iterations (smaller versions for emoji-equivalent contexts, larger banner versions) reuse the same scale motif. ### Step 6: ship + test - Build the project. - Run the actual tool that emits the art. - View in **Termux** (phone terminal — the strictest test environment). - View in **markdown renderer** (GitHub README, MCP client). - Adjust if any line wraps or any character mis-aligns. ## When ASCII fails Be honest about it. If your art is for: - **High-fidelity branding** (logo, marketing site header) - **Animated state** (loading spinners are usually better as `⠋⠙⠹⠸⠼⠴⠦⠧⠇⠏` unicode braille sequences than ASCII frame animation) - **Color-critical communication** (severity badges, status indicators) …use SVG / Unicode / native widgets. ASCII is the right tool when the constraint is *the medium itself* (terminal, postinstall log, plain-text MCP response). When you have other options, ASCII is a stylistic choice, not a default. ## Verification checklist before shipping - [ ] Renders in monospace terminal at 1.0 line height - [ ] Renders in Termux (phone, 60-72 col width) - [ ] Renders in GitHub markdown (paste into a gist, verify) - [ ] Renders in the actual MCP client / tool the art will appear in - [ ] No trailing whitespace - [ ] Width ≤ 72 cols (60 for embedded contexts) - [ ] Height fits the line budget for the surface - [ ] Silhouette readable at squint - [ ] Anchor feature (eye, ridge, peak) is unmistakable - [ ] Mood variants preserve the figure's identity - [ ] No mixed character-density tiers - [ ] No amateur tells (see "Common amateur tells" above) If any of these fail, the art isn't ready. Re-draw at the target.