/glyph
Render an answer as ASCII art plus semantic emojis inline, right now, with no setup questions. Use for a fast visual take on status, comparisons, trade-offs, architecture, or any ad-hoc 'show me X visually' ask. For a full multi-artifact plan playground, use visualize-plan
$ npx -y skills add yonatangross/orchestkit --skill glyph --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/glyph
Context preview
The summary Claude sees to decide when to auto-load this skill.
Render an answer as ASCII art plus semantic emojis inline, right now, with no setup questions. Use for a fast visual take on status, comparisons, trade-offs, architecture, or any ad-hoc 'show me X visually' ask. For a full multi-artifact plan playground, use visualize-plan
SKILL.md
glyph.SKILL.mdname: glyph
license: MIT
compatibility: "Claude Code 2.1.220+."
description: "Render an answer as ASCII art plus semantic emojis inline, right now, with no setup questions. Use for a fast visual take on status, comparisons, trade-offs, architecture, or any ad-hoc 'show me X visually' ask. For a full multi-artifact plan playground, use visualize-plan instead."
tags: [ascii, diagrams, visualization, box-drawing, terminal, quick]
version: 2.0.0
author: OrchestKit
user-invocable: true
disable-model-invocation: false
context: inherit
allowed-tools: [Read, Grep, Glob]
argument-hint: "[topic-to-render]"
complexity: low
persuasion-type: reference
effort: low
metadata:
category: document-asset-creation
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)
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. **Lead with the answer.** The visual comes first; prose after it only if it adds something the diagram cannot carry. 6. **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.
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.
<!-- ascii-lint-disable: single-set,single-arrow-style,density-min -->
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.
| Set | Characters | Use For | |-----|-----------|---------| | `default` `─│` | Normal boxes and connectors | Most diagrams | | `emphasis` `━┃` | Headers, focus, draw the eye | Key components, outer frames | | `title` `═║` | Document titles | §0-style banners only | | `soft` `╭╮╰╯ ─│` | Status cards, ambient UI | Diff blocks | | `portable` `+-\|` | NO_COLOR / CI / bare TTY | Fallback |
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 ** NewProgress 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 | DependencyBlast Radius (Concentric Rings)
Ring 3: Tests (8 files)
+-------------------------------+
| Ring 2: Transitive (5) |
| +------------------Read more
name: glyph license: MIT compatibility: "Claude Code 2.1.220+." description: "Render an answer as ASCII art plus semantic emojis inline, right now, with no setup questions. Use for a fast visual take on status, comparisons, trade-offs, architecture, or any ad-hoc 'show me X visually' ask. For a full multi-artifact plan playground, use visualize-plan instead." tags: [ascii, diagrams, visualization, box-drawing, terminal, quick] version: 2.0.0 author: OrchestKit user-invocable: true disable-model-invocation: false context: inherit allowed-tools: [Read, Grep, Glob] argument-hint: "[topic-to-render]" complexity: low persuasion-type: reference effort: low metadata: category: document-asset-creation
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)
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. **Lead with the answer.** The visual comes first; prose after it only if it adds something the diagram cannot carry. 6. **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.
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.
<!-- ascii-lint-disable: single-set,single-arrow-style,density-min -->
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.
| Set | Characters | Use For | |-----|-----------|---------| | `default` `─│` | Normal boxes and connectors | Most diagrams | | `emphasis` `━┃` | Headers, focus, draw the eye | Key components, outer frames | | `title` `═║` | Document titles | §0-style banners only | | `soft` `╭╮╰╯ ─│` | Status cards, ambient UI | Diff blocks | | `portable` `+-\|` | NO_COLOR / CI / bare TTY | Fallback |
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 ** NewProgress 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 | DependencyBlast Radius (Concentric Rings)
Ring 3: Tests (8 files)
+-------------------------------+
| Ring 2: Transitive (5) |
| +------------------The Complete AI Development Toolkit for Claude Code — 114 skills, 37 agents, 212 hooks. Production-ready patterns for full-stack development.
Repo: yonatangross/orchestkit
Other skills on orchestkit.
- /ork-assess
Assess a code change, design, architecture, workflow, or competing options against explicit criteria and evidence. Use when a request asks to assess, rate, compare, identify trade-offs, evaluate readiness, or decide whether an approach is good enough. Do not use for a full
Open skill - /ork-brainstorm
Compare plausible implementation, architecture, product, or operational approaches before committing to one. Use when a request asks to brainstorm, think through options, choose an approach, evaluate trade-offs, or resolve significant uncertainty before implementation. Do not
Open skill - /ork-explore
Map an unfamiliar codebase, feature, architecture, data flow, or operational path with file-backed evidence. Use when a request asks how a system works, where behavior lives, what changed, which dependencies matter, or for onboarding before a change. Do not use to implement or
Open skill - /ork-review-pr
Review a pull request or branch for correctness, regressions, security, operational risk, and missing evidence. Use when a request asks to review a PR, review a diff, find real bugs, assess merge risk, or provide evidence-backed review findings. Do not use for implementation or
Open skill - /ork-verify
Verify that existing work is ready to merge, release, or hand off using an explicit evidence contract. Use when a request asks to verify, validate, prove, check readiness, run the relevant tests, or distinguish a claimed result from an observed one. Do not use to write missing
Open skill - /accessibility
Accessibility patterns for WCAG 2.2 compliance, keyboard focus management, React Aria component patterns, cognitive inclusion, native HTML-first philosophy, and user preference honoring. Use when implementing screen reader support, keyboard navigation, ARIA patterns, focus
Open skill

