# Ascii Schemas

> Generate ASCII schemas, diagrams, and UI wireframes using Unicode box-drawing characters (wiretext conventions). Use when creating architecture diagrams, entity-relationship models, database schemas, flow charts, deployment topologies, sequence diagrams, data flow visualizations, UI wireframes, screen mockups, or any visual schema in plans, documents, or conversations. Trigger on: "diagram", "schema", "ASCII art", "draw", "visualize", "architecture diagram", "ER diagram", "flow chart", "topology", "sequence diagram", "data flow", "wireframe", "mockup", "screen layout", "UI sketch", "page layout". Do NOT use for: code formatting, markdown tables, or image-based diagrams. If @wiretext/mcp server is connected, prefer its create_wireframe/render_wireframe tools for UI wireframes — they produce higher-fidelity output with 30+ components.

- Skill: `awinogradov/ascii-schemas` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add awinogradov/ascii-schemas`
- Raw SKILL.md: https://api.skillmd.com/api/skills/awinogradov/ascii-schemas/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: awinogradov (https://skillmd.com/u/awinogradov)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/awinogradov/ascii-schemas

---


# ASCII Schemas

Generate ASCII schemas, diagrams, and UI wireframes using Unicode box-drawing characters following wiretext conventions. Output renders correctly in any monospace environment — terminals, markdown, code blocks, GitHub PRs, and plain text documents.

## When to Use

**Technical schemas:**

- Architecture diagrams in implementation plans
- Entity-relationship models for database design
- Deployment and infrastructure topologies
- Data flow and component interaction diagrams
- Sequence and timeline diagrams

**UI wireframes:**

- Screen mockups for feature planning
- Page layout prototypes
- Mobile app screen flows
- Dashboard and admin panel wireframes
- Component library documentation

## MCP Integration

If the `@wiretext/mcp` server is connected, prefer its tools for UI wireframes — they handle component positioning and rendering automatically:

- **`create_wireframe`** — returns an editable wiretext.app URL from wire objects
- **`render_wireframe`** — returns ASCII art from wire objects

Wire object format:

```json
{
  "type": "component",
  "componentType": "navbar",
  "position": { "col": 0, "row": 0 },
  "width": 50,
  "navItems": ["Home", "Products", "About"]
}
```

Available component types: `button`, `input`, `select`, `checkbox`, `radio`, `toggle`, `table`, `modal`, `browser`, `card`, `navbar`, `tabs`, `progress`, `avatar`, `divider`, `breadcrumb`, `list`, `stepper`, `rating`, `skeleton`, `alert`, `image`, `icon`.

Primitives: `box`, `text`, `line`, `arrow`.

Fall back to hand-drawn ASCII when the MCP server is not connected or for technical schemas (architecture, ER, topology, sequence diagrams).

## Core Rules

1. **Width guideline: 80 characters** for technical schemas. Wireframes may extend wider when layout requires it, but aim for minimal width
2. **Default border style: single** — use `┌─┐│└┘` as the default. Use rounded `╭─╮│╰╯` for mobile frames, chat bubbles, and softer cards. Use double `╔═╗║╚╝` for emphasis (invoices, highlighted pricing). Use heavy `┏━┓┃┗┛` for critical elements (deploy targets, warnings)
3. **Annotation-free diagrams** — never overlay prose on diagram borders or arrows. Put explanations in a separate "Flow Legend" section below the diagram
4. **Strip trailing whitespace** — no trailing spaces on any line
5. **Monospace assumed** — every character occupies exactly one grid cell
6. **Wrap in code block** — always present diagrams inside triple-backtick fenced code blocks

## Character Quick Reference

### Box Drawing

| Style   | Corners         | Horizontal | Vertical | Tees                |
| ------- | --------------- | ---------- | -------- | ------------------- |
| Single  | `┌` `┐` `└` `┘` | `─`        | `│`      | `├` `┤` `┬` `┴` `┼` |
| Double  | `╔` `╗` `╚` `╝` | `═`        | `║`      | `╠` `╣`             |
| Rounded | `╭` `╮` `╰` `╯` | `─`        | `│`      | `├` `┤`             |
| Heavy   | `┏` `┓` `┗` `┛` | `━`        | `┃`      | `┣` `┫`             |

### Arrows and Connectors

| Character       | Usage                    |
| --------------- | ------------------------ |
| `→` `←` `↑` `↓` | Directional flow         |
| `▶` `◀` `▼` `▲` | Emphasized flow          |
| `↗` `↘`         | Trend indicators         |
| `──▶`           | Horizontal arrow line    |
| `◀──▶`          | Bidirectional connection |
| `──→`           | Screen-to-screen flow    |

### Flow References

Circled numerals for labeling flows — explain each in a legend below:

`①` `②` `③` `④` `⑤` `⑥` `⑦` `⑧` `⑨` `⑩`

### UI Symbols

| Character   | Usage                                     |
| ----------- | ----------------------------------------- |
| `░`         | Image/content placeholder fill            |
| `▓`         | Progress bar filled portion               |
| `⌕`         | Search icon                               |
| `≡`         | Hamburger menu                            |
| `⍥`         | User/avatar icon                          |
| `▾`         | Dropdown arrow                            |
| `×`         | Close button                              |
| `⊕`         | Add/plus button                           |
| `✓`         | Checkmark / success                       |
| `●` `○`     | Filled/empty dot (status, ratings, radio) |
| `★`         | Star / logo placeholder                   |
| `♡` `¶`     | Like, comment icons                       |
| `◀` `▶` `■` | Media controls (prev, play, stop)         |

## Border Style Selection

| Style   | When to Use                                               |
| ------- | --------------------------------------------------------- |
| Single  | Default for technical schemas and most UI elements        |
| Rounded | Mobile frames, chat bubbles, cards, modals, soft UI       |
| Double  | Highlighted/featured elements (pricing, invoices, alerts) |
| Heavy   | Critical deployment targets, warnings, emphasis           |

**Mixing rule**: one alternative style per diagram to highlight a single element. Exception: wireframes may use rounded for the outer frame with single for inner components.

## Pattern References

Worked patterns live in reference files — read the one matching the request before drawing:

- Technical schema (architecture, ER, sequence, topology, pipeline) and construction guidelines (box sizing, spacing, flow legends) → read [`references/technical-diagrams.md`](./references/technical-diagrams.md)
- Page or screen wireframe → read [`references/ui-wireframes.md`](./references/ui-wireframes.md)
- Individual UI widgets inside a wireframe (toggle, checkbox, progress, stepper, …) → read [`references/component-patterns.md`](./references/component-patterns.md)

## Anti-Patterns

**Do not:**

- Place text annotations overlapping box borders
- Mix more than two border styles in one diagram
- Use diagrams for simple tabular data — prefer markdown tables
- Add purely decorative elements — keep diagrams functional
- Use full-width Unicode characters — they break grid alignment
- Forget code block wrapping — naked diagrams lose alignment
- Use inconsistent spacing between same-level elements

## Reference formatting

Before writing any output that mentions a file, standard, section, commit, or issue, read [`reference-formatting.md`](../shared-rules/references/reference-formatting.md) (RFC-0001) and apply it verbatim — link files, docs, skills, agents, and sections, and never leave a reference as bare text.