菜单
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.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/yonatangross/orchestkit --skill glyph命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Chain patterns for multi-phase pipelines: MCP detection, handoff files, checkpoint-resume, worktree agents, CronCreate monitoring. Use when building or debugging a pipeline skill.
OrchestKit doctor for health diagnostics across manifest integrity, hook configuration, skill validation, agent frontmatter, MCP server connectivity, CC version compatibility, and permission rules. Reports issues with severity levels and auto-remediation suggestions. Validates component counts, detects orphaned entries, and checks CC version matrix compliance. Use when diagnosing plugin health, troubleshooting configuration issues, or running pre-release checks.
Inspects the OrchestKit telemetry pipeline for the current project — lists all known telemetry files with write counts, sizes, schema status, growth trend, and orphan detection. Use when verifying the observability pipeline is healthy, debugging a missing writer, or auditing which files have schema locks vs. which are drift-vulnerable. Read-only — never modifies telemetry files.
正在显示 SKILL.md
基于 SOC 职业分类
| 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"} |
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.
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):
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.
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 |
Emit inline in the reply. Never write a file unless the user asked for one. This is a chat answer, not an artifact.
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).
Lead with the answer. The visual comes first; prose after it only if it adds something the diagram cannot carry.
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.
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)
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.
Closed-set v1 of 11 semantic glyphs (●○✓✗⚠◆◇▶▷ ↑↓→ ▓▒░). Single source of truth — see rules/status-glyph-vocabulary.md. Add-a-glyph process in CONTRIBUTING.md.
┌──────────────┐ ┌──────────────┐
│ Frontend │─────>│ Backend │
│ React 19 │ │ FastAPI │
└──────────────┘ └───────┬──────┘
│
v
┌──────────────┐
│ PostgreSQL │
└──────────────┘
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
[████████░░] 80% Complete
+ Design (2 days)
+ Backend (5 days)
~ Frontend (3 days)
- Testing (pending)
Backend ===[Schema]======[API]===========================[Deploy]====>
| | ^
| +------blocks------+ |
| | |
Frontend ------[Wait]--------[Components]=======[Integration]=+
=== Active work --- Blocked/waiting | Dependency
Ring 3: Tests (8 files)
+-------------------------------+
| Ring 2: Transitive (5) |
| +------------------------+ |
| | Ring 1: Direct (3) | |
| | +--------------+ | |
| | | CHANGED FILE | | |
| | +--------------+ | |
| +------------------------+ |
+-------------------------------+
BEFORE AFTER
┌────────────┐ ┌────────────┐
│ Monolith │ │ Service A │──┐
│ (all-in-1)│ └────────────┘ │ ┌──────────┐
└────────────┘ ┌────────────┐ ├─>│ Shared │
│ Service B │──┘ │ Queue │
└────────────┘ └──────────┘
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)
| Rule | Description |
|---|---|
| Font | Always monospace — box-drawing requires fixed-width |
| Weight | Standard for normal, Heavy for emphasis, Double for titles |
| Arrows | ─>, ──>, or │ with v/^ for direction |
| Alignment | Right-pad labels to match column widths |
| Annotations | !! for risk, ** for new, [A/M/D] for change type |
| Width | Keep under 80 chars for terminal compatibility |
| Nesting | Max 3 levels of box nesting before readability degrades |
| Pattern | Use Case |
|---|---|
| Layered boxes | System architecture, deployment topology |
| Concentric rings | Blast radius, impact analysis |
| Timeline bars | Reversibility, migration phases |
| Swimlanes | Execution order, parallel work streams |
| Annotated trees | File change manifests, directory structures |
| Comparison tables | Cross-layer consistency, before/after |
| Progress bars | Status tracking, completion metrics |
brainstorm — Design exploration where diagrams communicate ideasarchitecture-patterns — System architecture that benefits from ASCII diagramscode-review-playbook — Review comments with inline diagrams