All docs
Concepts · Symbols

Symbols

Caret ships ten glyphs that carry brand identity across every component. The manifesto lists them as one of the seven hard rules: "Never customize Caret symbols. They are the brand." A user who has seen ^ and and in one Caret CLI should recognize them in every other Caret CLI.

Brand mark

GlyphTokenWhere used
^symbols.anchorBanner heads, prompt frames, splash logos. The mark.

State indicators

GlyphTokenMeaning
symbols.state.successOperation completed successfully
symbols.state.failureOperation failed
symbols.state.warningSoft problem — attention but not error
symbols.state.infoInformational message
symbols.state.cancelledUser cancelled (Esc on a prompt)

Selection markers

GlyphTokenMeaning
symbols.marker.selectedSelected radio / multi-select item
symbols.marker.unselectedUnselected radio / multi-select item
symbols.progress.arrowFocus indicator, list arrow variant

Structure

GlyphTokenWhere used
symbols.structure.gutterQuote, error, alert left gutter
symbols.rulerBanner rule, divider, section separator

Why "do not customize"

Two reasons. First, recognizability: a CLI users identify as "Caret-built" gives them confidence about the rest of the interaction — they know means done, means failed, no need to relearn.

Second, spec portability: the spec for error says "prefix with symbols.state.failure". A Go port reads the spec, renders the same glyph, and the result feels like the same product. If symbols were customizable, the spec would have to say "the concept of failure", and ports would diverge.

If you really need to change them
You can override symbols via setTheme. Caret won't stop you. But it stops being a Caret CLI at that point — that's the point of the rule.

ASCII fallback

On dumb terminals or when NO_COLOR is set, glyphs that rely on Unicode (✓ ✗ ⚠ ℹ ● ○ ▸ ─ │) fall back to ASCII equivalents (+ x ! i [x] [ ] > - |) automatically. The capability layer makes this decision; you don't opt in. See Capability detection.