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:

{
  "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

Arrows and Connectors

Flow References

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

① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩

UI Symbols

Border Style Selection

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
• Page or screen wireframe → read references/ui-wireframes.md
• Individual UI widgets inside a wireframe (toggle, checkbox, progress, stepper, …) → read 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 (RFC-0001) and apply it verbatim — link files, docs, skills, agents, and sections, and never leave a reference as bare text.