Glyph

Glyph

Render the answer as ASCII art plus semantic emojis, inline, immediately. All output renders in a monospace terminal with no external tools.

Core principle: Encode information into structure, not decoration. Every diagram element should communicate something meaningful.

Execution (run this, do not ask first)

A human asking "how do I use this" gets a URL, not a paraphrase: https://orchestkit.yonyon.ai/docs/reference/skills/glyph#examples (what it draws, the two picks, three real renders, the exact invocation; generated from this skill's examples/_featured.md, so it cannot drift from the skill).

The whole point is speed, so there is no setup phase.

With no argument, the topic is the current conversation. Measured over a real 13-prompt session: zero asks supplied a self-contained topic, and the one direct invocation passed nothing at all. /ork:glyph on its own means "render where we are right now" — the open work, the decision just reached, the state of the thing being discussed. Render that; do not ask what to draw.

Given a topic (or the conversation, when none is given):

1. Render immediately. Do NOT call AskUserQuestion to pick a format, do NOT call TaskCreate, do NOT spawn an Agent. Choose the form yourself from the topic shape and draw it. Asking first defeats the skill.

2. Pick the form from the shape of the data, using the pattern library below:

   Topic shape	Form
   state / progress / health	status box + bar meters
   A vs B, options, trade-offs	comparison table or side-by-side boxes
   steps, pipeline, hand-offs	left-to-right flow with ──▶
   containment, layers, layout	nested boxes / tree
   ranked list, scores, counts	table + bar meters
   over time	sparkline or milestone track

3. Emit inline in the reply. Never write a file unless the user asked for one. This is a chat answer, not an artifact.

4. Use the 12-emoji semantic set and box-drawing vocabulary defined in rules/visual-style.md (shipped with this skill). Semantic, never decorative: an emoji must mean something (✅ pass, ❌ fail, ⚠️ risk, 🔴 blocked).

5. Stay inside the budget: ≤ 12 visual lines, and ≤ 40% of the reply. Block count within that is free — two 5-line blocks are fine, four 10-line blocks are not. This skill renders on request, it does not render without limit (#3558). Full derivation of the numbers is in rules/visual-style.md.

6. State the point in prose first, in one or two sentences, then show the visual. The visual supports the answer; it is never the answer. If the reader has to parse a diagram to find out what happened, the reply failed.

7. Stay honest. If a number is unknown, print ? rather than inventing one. A confident-looking chart built on guesses is worse than prose.

When NOT to use this skill: if the deliverable is a multi-section HTML playground, a persisted plan artifact, or anything needing file output, use visualize-plan instead. Glyph is the cheap inline path; visualize-plan is the full pipeline.

Over budget is the same signal. If the honest rendering needs more than ~12 lines, that is not a bigger chat answer, it is a different deliverable: write the playground or file, then hand the human a URL with /ork:page-serve <path> (a port-free https://<name>.localhost/ route, with a stop) instead of a bare file path or a hand-started python3 -m http.server. The old escape hatch fired on artifact TYPE only, so a 40-line inline reply never tripped it.

Box-Drawing Character Reference

This block intentionally shows multiple sets together as a key. Authors should use ONE set per real diagram; the single-set lint rule enforces this on production diagrams.

default:   ┌─┐ │ └─┘  ├─┤ ┬ ┴ ┼
emphasis:  ┏━┓ ┃ ┗━┛  ┣━┫ ┳ ┻ ╋
title:     ╔═╗ ║ ╚═╝  ╠═╣ ╦ ╩ ╬
soft:      ╭─╮ │ ╰─╯
portable:  +-+ | +-+  +-+ + + +
Arrows:    → ← ↑ ↓ ─> <─ ──> <──
Blocks:    █ ▓ ░ ▏▎▍▌▋▊▉
Status:    ● ○ ✓ ✗ ⚠ ◆ ◇ ▶ ▷  ↑↓→ ▓▒░  (closed-set vocab — see rules)

Set Conventions (D8: intent-driven naming)

Tokens live in tokens.json. Names describe USE not APPEARANCE.

Rename codemod (D8): old light/heavy/double/rounded/ascii-fallback → new names above. Old names accepted with warning for one minor release.

Status Glyph Vocabulary

Closed-set v1 of 11 semantic glyphs (●○✓✗⚠◆◇▶▷ ↑↓→ ▓▒░). Single source of truth — see rules/status-glyph-vocabulary.md. Add-a-glyph process in CONTRIBUTING.md.

Diagram Patterns

Architecture Diagrams

┌──────────────┐      ┌──────────────┐
│   Frontend   │─────>│   Backend    │
│   React 19   │      │   FastAPI    │
└──────────────┘      └───────┬──────┘
                              │
                              v
                      ┌──────────────┐
                      │  PostgreSQL  │
                      └──────────────┘

File Trees with Annotations

src/
├── api/
│   ├── routes.py          [M] +45 -12    !! high-traffic path
│   └── schemas.py         [M] +20 -5
├── services/
│   └── billing.py         [A] +180       ** new file
└── tests/
    └── test_billing.py    [A] +120       ** new file

Legend: [A]dd [M]odify [D]elete  !! Risk  ** New

Progress Bars

[████████░░] 80% Complete
+ Design    (2 days)
+ Backend   (5 days)
~ Frontend  (3 days)
- Testing   (pending)

Swimlane / Timeline Diagrams

Backend  ===[Schema]======[API]===========================[Deploy]====>
                |            |                                ^
                |            +------blocks------+             |
                |                               |             |
Frontend ------[Wait]--------[Components]=======[Integration]=+

=== Active work   --- Blocked/waiting   | Dependency

Blast Radius (Concentric Rings)

            Ring 3: Tests (8 files)
       +-------------------------------+
       |    Ring 2: Transitive (5)      |
       |   +------------------------+   |
       |   |  Ring 1: Direct (3)     |   |
       |   |   +--------------+      |   |
       |   |   | CHANGED FILE |      |   |
       |   |   +--------------+      |   |
       |   +------------------------+   |
       +-------------------------------+

Comparison Tables

BEFORE                          AFTER
┌────────────┐                  ┌────────────┐
│  Monolith  │                  │  Service A │──┐
│  (all-in-1)│                  └────────────┘  │  ┌──────────┐
└────────────┘                  ┌────────────┐  ├─>│  Shared  │
                                │  Service B │──┘  │  Queue   │
                                └────────────┘     └──────────┘

Reversibility Timeline

Phase 1  [================]  FULLY REVERSIBLE    (add column)
Phase 2  [================]  FULLY REVERSIBLE    (new endpoint)
Phase 3  [============....]  PARTIALLY           (backfill)
              --- POINT OF NO RETURN ---
Phase 4  [........????????]  IRREVERSIBLE        (drop column)

Key Rules

When to Use Each Pattern

Related Skills

• brainstorm — Design exploration where diagrams communicate ideas
• architecture-patterns — System architecture that benefits from ASCII diagrams
• code-review-playbook — Review comments with inline diagrams