Brand Identity System

Status: Open — design proposal and implementation plan

Problem

jackin’ already has a strong product vocabulary: Operator, Construct, hardline, isolated agents, terminal-first control. The visual identity does not yet have an equally strict contract. The current apostrophe wordmark, bright green docs treatment, CLI logo, favicons, Open Graph images, README, and future app/package icons can drift unless the project defines one canonical mark, color relationship, typography stack, terminal treatment, and migration plan before assets are replaced piecemeal.

This roadmap item captures the proposed terminal-native identity. It should become a short-lived implementation program: once the rebrand ships, durable usage rules move into normal brand/docs surfaces and this page is retired or reduced to a completed summary.

Research Inputs

The live site at jackin.tailrocks.com already has the right world: dark terminal surfaces, phosphor green, digital rain, the Operator/Construct vocabulary, and copy centered on the boundary between host and agent. The brand work should sharpen those signals, not replace them with a generic SaaS mark.
The Launch Progress TUI roadmap is the product-surface foundation for future launch work. It defines the compact launch cockpit, stage vocabulary, digital-rain lifecycle, diagnostics boundary, and shared jackin load / console launch visualization. Brand identity work should layer onto that surface after it lands; it must not redesign or displace the launch experience.
GitHub says the README is often the first thing a repository visitor sees and supports relative image paths that resolve per branch. That makes a committed README hero banner a high-value brand surface, not decoration: it can carry the same lockup and frozen-rain treatment as the website without remote asset dependencies.
Mature brand systems separate a wordmark, iconmark, product/partner lockups, clear-space rules, typography, and color. Ory’s public brand guidelines are a useful software-company reference because they explicitly define wordmark/iconmark roles, clear space, product lockups, and a technical typography split.
Textless marks usually earn recognition over time. Even Apple, Nike, and Mastercard-style logo shorthand started or lived alongside a word/name lockup until the mark alone carried enough memory. jackin❯ should therefore ship a wordmark/lockup first, then let j❯ become the standalone sigil as repeated terminal exposure builds recognition.
Terminal banners work because terminals are monospace; however, practical guidance points toward bounded art around 60-80 columns, width detection to prevent wrapping, and Unicode/block characters only where the environment supports them. That maps directly to a frozen-rain --help banner plus a plain fallback.

Design Thesis

The mark is a shell prompt. The product’s core action is dropping an AI agent through a boundary into an isolated Construct, and the brand should show that action in the medium operators already use: monospace terminal text.

The working full wordmark is:

jackin❯
by tailrocks

The working monogram is:

j❯

The chevron is the constant. It reads as a shell prompt, as forward motion, and as the boundary crossing that jackin’ exists to make safe. Any mark that requires gradients, glows, illustration detail, or sub-pixel rendering fails the terminal-first requirement.

The company lockup is part of logo artwork:

jackin❯
by tailrocks

Use by tailrocks when the mark is drawn as a logo, banner, image, card, icon source, splash, README hero, or help banner. Do not append the byline to ordinary prose sentences, command examples, binary names, package names, paths, or environment variables.

Recognition Strategy

The brand needs two connected pieces:

A standalone mark that works on the website, README hero, favicon, social card, app icon, sticker, and future package-manager surfaces.
A prompt system that makes the mark appear constantly inside real terminal sessions.

The prompt system is the distribution engine. Starship, Oh My Zsh, and Powerline proved that a prompt is some of the most-stared-at real estate in a developer’s day. If an active jackin❯ shell replaces a generic $ prompt with j❯, then every screenshot, demo, bug report, and recorded session repeats the mark naturally.

The risk is that j❯ alone is quiet as a static billboard. The implementation should pair it with a stronger standalone logo treatment for web and README surfaces, but the sigil itself stays inline: j and ❯ share one baseline and must never be stacked.

Target relationship:

WEBSITE / README / SOCIAL

  j❯
  jackin❯
  by tailrocks

TERMINAL

  j❯ load agent-smith
    cloning construct...
  j❯ hardline agent-smith
    attaching to session...
  j❯ _

The exact website composition is still open. The invariant is that the large visual mark, the README hero, the favicon, and the shell prompt must be recognizably the same inline j❯ object at different levels of detail.

Launch Surface Relationship

The brand identity system is sequenced after the Launch Progress TUI work. Launch progress owns the operator’s live launch experience: compact stage layout, identity panel, diagnostics handle, failure dialog rules, reduced-motion behavior, and the boundary-rain lifecycle. Branding should supply the mark, color tokens, wordmark/byline rules, prompt sigil, static help/README/OG treatments, and reusable visual assets on top of that foundation.

The implementation must not turn the launch cockpit into a logo splash, marketing hero, full-screen brand animation, or generic digital-rain scene. In live launch flows, brand changes are limited to consistent wordmark/sigil rendering, phosphor token alignment, and any launch-progress-approved rain strip or hardline motif. The launch TUI remains operational first: stages, status, diagnostics, and failure clarity outrank brand decoration.

Candidate Directions

The implementation PR should prototype several logo directions before choosing one. Do not assume the first j❯ sketch is enough just because it is semantically right.

Direction	Shape	Best surface	Strength	Risk
A. Prompt sigil	`j❯` as the primary monogram	Terminal prompt, favicon, package icons	Native to shells; copyable; high distribution through screenshots	Quiet as large standalone artwork unless paired with a richer lockup
B. Boundary gate	A minimal doorway/portal made from a vertical boundary plus `❯`, with `j` as the operator entering	Website hero, README banner, social card	Makes the “drop through a boundary into a Construct” idea visible without extra copy	Must stay text-renderable in terminal; easy to overcomplicate
C. Hardline connector	`j` shaped as a cable/line feeding into `❯`	README hero, app icon, sticker	Ties the Matrix vocabulary to a concrete connection image	Could become generic cable/plug tech branding if not constrained
D. Rain-cut wordmark	Frozen digital rain field with `jackin❯` cut out or locked bright in the center	`--help`, README hero, OG card	Distinctive, terminal-native, already aligned with the current site	Too noisy for favicon/app icon; should be environment treatment, not the only mark
E. Wordmark-first lockup	`jackin❯` over `by tailrocks`, with `j❯` as the small-size extraction	Docs header, README top, website nav	Clear for a young brand; teaches the sigil before using it alone	Less iconically unique until repeated prompt exposure builds memory

The likely answer is a system, not a single drawing: E teaches the name, A distributes it in terminals, D gives the brand a recognizable atmosphere, and B or C may supply the stronger standalone website/icon mark if they survive sketches.

Brand Invariants

There are exactly four valid text forms: j❯, j>, jackin❯, and jackin>. No other text representation is part of the brand system.
The primary wordmark is jackin❯: lowercase letters followed immediately by ❯ with no space.
The full logo lockup is jackin❯ over by tailrocks, with the byline smaller or dimmer than the mark wherever the medium supports that hierarchy.
The primary monogram is j❯: lowercase j followed immediately by ❯ with no space.
The chevron is ❯ (U+276F, HEAVY RIGHT-POINTING ANGLE QUOTATION MARK ORNAMENT). Use it everywhere the surface can render Unicode: website, docs, README, terminal output, help text, screenshots, SVG/PNG assets, favicons, app icons, package metadata, and social cards.
The ASCII fallback > is an exception for constrained environments only: plaintext systems that cannot render ❯, terminals with broken glyph coverage, legacy metadata fields, package registries that reject Unicode, search snippets, or copy channels where Unicode loss is proven. When fallback is required, use only j> or jackin>. Never use fallback just because it is easier to type in source.
Never substitute another fancy chevron, arrow, bracket, prompt glyph, apostrophe, capitalization, or decorated spelling.
The chevron is always bright jackin❯ green. The jackin word or j letter is always white on dark backgrounds or black on light backgrounds. If the chevron and letters are the same color, or if the letters use gray, green, or another accent, the logo is wrong.
Rendered documentation should treat jackin❯ and j❯ as brand marks where the renderer supports styling: white or black letters chosen by background contrast, bright green ❯, monospace font, and copyable text. Markdown-only or code-block contexts may use plain unstyled jackin❯, but HTML/MDX components, docs headers, README banners, command output examples with ANSI captures, and generated assets should preserve the color split.
Icon/favicons use only the short form (j❯ or j> fallback). Do not squeeze the full wordmark into icon surfaces.
Wordmark/logotype surfaces use the full form (jackin❯ or jackin> fallback), with separate light and dark colorways: black letters on white/light backgrounds, white letters on black/dark backgrounds, and the same bright green chevron in both.
The proposed rebrand retires the trailing-apostrophe wordmark. The implementation PR must update the agent-only spelling rule in AGENTS.md at the same time it updates public docs and assets, so the repository does not mix old and new brand rules indefinitely.
Rich-text prose should use jackin❯ when referring to the product or project by name. Plaintext-only environments may use jackin>. Compact logo surfaces may use j❯, and compact plaintext fallback surfaces may use j>. Literal commands, binaries, crates, packages, environment variables, config keys, file paths, labels, selectors, URLs, and code identifiers stay jackin only where the reader must type or match the literal identifier.
The wordmark and monogram use one monospace font and one weight across all official surfaces. Do not split the j and ❯ into different fonts or weights.

Quality Bar

Every candidate mark must pass these tests before implementation:

Terminal fidelity: render legibly in a monospace terminal as plain text, with and without ANSI color.
Fallback restraint: prove each > fallback is needed by the target surface; otherwise use ❯.
Color recognition: every rendered logo/documentation treatment that supports styling must show the word or j in white/black according to the background and the chevron in #5CF07A, not merely spell the mark as text.
Website parity: the website mark must be recognizably the same shape as the terminal prompt mark, not a separate illustration that only shares a name.
Small-size survival: the mark must remain identifiable at 16x16 favicon size and 22-24px nav size.
Large-size confidence: the mark must not feel empty or accidental at README/OG/hero scale.
Copyability: the textual lockup can be copied from terminal/help/docs without turning into image-only branding.
One-move recognition: the brand should reduce to one memorable move: a j crossing through or into ❯.
No generic tech drift: if the mark could belong to any terminal app, cloud CLI, or AI wrapper, reject it.

Color System

Token	Hex	Use
Bright chevron green	`#5CF07A`	Canonical chevron color on dark and light brand surfaces
Muted accent	`#1D9E75`	Optional UI-layer accent when pure phosphor is too loud; not for the logo chevron
Logo white	`#FFFFFF`	Letters on dark logo surfaces
Dark canvas	`#0A0A0A`	Default background
Logo black	`#0A0A0A`	Letters on light, cream, and other non-dark logo surfaces
Cream optional	`#F4F1E8`	Sticker/print-only retro-manual surface

Official colorways:

Name	Background	Letters	Chevron	Use
Dark	`#0A0A0A`	`#FFFFFF`	`#5CF07A`	Default terminal, website, dark-mode docs, dark app chrome
Light	`#FFFFFF`	`#0A0A0A`	`#5CF07A`	Light-mode docs, README surfaces, print contexts
Cream	`#F4F1E8`	`#0A0A0A`	`#5CF07A`	Optional sticker-only variant

Do not place the official mark directly on a bright green field if doing so would force the chevron to become black or disappear. Green backgrounds may be used elsewhere in the UI, stickers, or CTAs, but logo artwork must preserve the white/black word plus green chevron relationship.

Forbidden treatments:

No gradients on the mark.
No drop shadows, glow effects, neon effects, or blurred aura treatments.
No second brand accent color. Status colors and chart colors belong to the UI layer, not the mark.
No seasonal, joke, or cause-based recolors. Values statements belong in writing, not logo swaps.

Typography

The mark is monospace because it should look like terminal text. The primary recommendation is JetBrains Mono Medium (500). Acceptable alternates are Berkeley Mono, IBM Plex Mono, Geist Mono, and Commit Mono. The fallback chain should be "JetBrains Mono", "Berkeley Mono", ui-monospace, "SF Mono", Menlo, Consolas, monospace.

Supporting copy should stay in a clean sans-serif such as Inter or Geist with the fallback chain Inter, Geist, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif. The mono/sans contrast is intentional: the mark comes from the terminal, the surrounding copy explains it.

Sizing rules:

Asset	Rule
Wordmark	Use down to 14px cap height; below that, switch to monogram
Monogram	Minimum 16x16 px
Favicon	Short form only (`j❯`), with light and dark generated variants where the target platform supports theme-aware icons
App icon	Dark or light monogram variant finalized in the icon sketch pass, 1024x1024 source, rounded corners at roughly 22% of edge length

Spacing rules:

Wordmark letter-spacing: -0.03em at display sizes, -0.02em below.
Monogram letter-spacing: -0.04em.
Clear space around the mark equals at least the rendered width of the chevron.

Terminal Surfaces

The terminal is the primary brand surface, not a degraded fallback. The implementation should make the prompt and jackin-owned output carry the monogram consistently without taking over host shells or unrelated commands.

Prompt target:

j❯ _

Agent shell prompt target:

agent-smith j❯ cargo build --release
the-architect j❯ git status

Output prefix target:

j❯ jackin v0.1.0 · operator console
j❯ Pulling construct:trixie       OK
j❯ Cloning agent-smith            OK
j❯ Building derived image         OK
✓  Agent loaded. You're inside.

The j and agent name use the terminal default foreground. The chevron uses phosphor green or the user’s terminal-theme green when the terminal exposes one. For boxes and progress, Unicode box-drawing characters and block characters are preferred, with --no-unicode as the explicit fallback path.

The shared Clap --help banner should use frozen brand rain, not animation. The rain field should be built from the brand vocabulary (j, a, c, k, i, n, ❯, and the box/block drawing glyphs the CLI already uses) and should frame the jackin❯ / by tailrocks lockup without overwhelming the command list. This is a static documentation/help surface, not the live launch progress rain. The live launch rain behavior remains owned by the Launch Progress TUI lifecycle.

The optional first-run or --version banner may use a short ASCII wordmark with a right-side green chevron rail, but it must stay under six lines and must not appear on routine command output.

Website and docs work should replace the old apostrophe wordmark with the proposed wordmark and tokenized brand colors in one coordinated PR. The current docs title override in docs/src/components/overrides/SiteTitle.astro and theme tokens in docs/src/styles/docs-theme.css are likely first-touch files.

Docs should make the brand visually recognizable without sacrificing copyability. Where MDX/HTML is available, jackin❯ should render as one inline brand component with white or black jackin text, chosen by background contrast, and a #5CF07A chevron; the copied text should still be jackin❯. In plain Markdown/code contexts, write jackin❯ directly and reserve jackin> only for documented fallback surfaces.

Hero target:

Large wordmark on #0A0A0A, 84–96px desktop and 56–64px mobile.
Wordmark centered horizontally, near 30% viewport height.
No tagline directly under the mark. Leave roughly two cap heights of breathing room before supporting copy.
Optional faint 24x24 grid at rgba(255,255,255,0.03).
No particles, gradients, mark animation, or scroll-triggered mark effects.

Header target:

Wordmark in the top-left at 22–24px, always linking home.
Chevron retains accent color in both light and dark themes.

Required asset outputs:

GitHub README hero banner as a committed static asset. Use a frozen digital-rain field and the jackin❯ / by tailrocks lockup. GitHub README rendering should be treated as static: do not depend on JavaScript, CSS animation, or remote asset generation. Provide SVG plus PNG fallback if GitHub rendering or social previews need raster certainty.
favicon.ico with 16, 32, and 48 px sizes, using the short j❯ form.
Apple touch icon at 180 px.
PWA/Android icon at 512 px.
SVG favicon using the actual monogram.
Open Graph image at 1200x630 using dark canvas, optional faint grid, wordmark in the top-left quadrant, supporting tagline, site URL, and preview version tag.

The existing public assets under docs/public/favicon.svg, docs/public/apple-touch-icon.png, docs/public/icon-192.png, docs/public/icon-512.png, docs/public/og-image.png, and docs/public/og-image-github.png should be regenerated together once the spec is accepted.

App and Package Surfaces

The CLI is the first implementation target, but the identity should be ready for future desktop and mobile surfaces. Desktop and mobile app icons need their own sketch pass because OS docks and home screens are visually crowded, but they must still preserve the white/black letter plus green chevron relationship. Package-manager metadata that supports icons should receive the dark monogram as SVG and 256x256 PNG.

Inside future desktop/mobile apps, the default surface stays dark, the chevron shape informs primary accents, and inactive states use restrained neutrals rather than new brand colors.

Voice

The visual identity and copy should share the same register: terse, terminal-native, slightly formal in the style of an old computing manual. Keep Matrix-coded vocabulary where it is already product language: Operator, Construct, hardline, load, eject, exile, agent-smith, the Architect. Avoid exclamation marks, emojis in marketing copy, “delightful”, “magical”, and “AI-powered” as a generic modifier.

After the rebrand lands, prose should use the new wordmark where rich text reliably renders ❯; plaintext-only contexts may use jackin>. Until that implementation PR updates the repository’s agent rules, contributors should continue following the current spelling rule in AGENTS.md outside this roadmap proposal.

Implementation Plan

Research and sketch: prototype the candidate directions above as terminal text, website SVG/HTML, favicon-size raster previews, and README/OG-size static banners.
Align with the Launch Progress TUI: treat its launch cockpit, rain lifecycle, stage vocabulary, diagnostics model, and reduced-motion behavior as the live launch surface the brand must fit into rather than replace.
Choose the system: decide which direction owns the standalone website/icon mark, which owns the prompt, and which owns environmental treatments such as frozen rain.
Freeze the final spec: confirm the mark, chevron character, colors, typography, prohibited treatments, prompt shape, byline lockup, and asset list.
Update repository rules and published docs together: agent spelling policy, README, docs navigation, landing page, public docs references, and any user-facing pages that describe the product name or terminal output.
Run the global brand text sweep: find every prose occurrence of jackin', Jackin, Jackin', and JACKIN and replace product/project mentions with jackin❯. Use jackin> only after confirming the target surface cannot render ❯. Do not rewrite literal commands, code identifiers, paths, package names, env vars, URLs, or examples where the operator must type jackin.
Replace docs/site visual assets: Starlight title, landing hero, README hero banner, favicons, app/PWA icons, Open Graph card, and any social-card generation code.
Update CLI and terminal output: frozen --help banner, version/splash treatment, jackin-owned status prefixes, Capsule chrome, prompt setup inside role containers, and tests for ANSI color output where practical.
Update package/distribution surfaces: Homebrew metadata, release artifacts, GitHub social preview, and any future desktop/mobile icon source files.
Sweep old assets and screenshots: remove or replace apostrophe-era images, stale docs snippets, and vendor-facing material. Do not leave both brands active except inside historical changelog/release context after the first release.

Host-Side Effects

Prompt and shell branding are subject to the host-mutation rule in AGENTS.md. The implementation must not silently edit the operator’s host shell files, dotfiles, terminal profile, Git config, repository metadata, or GitHub CLI config. Prompt changes belong inside role containers, jackin-owned runtime scaffolding, or an explicitly surfaced operator opt-in.

If any future implementation offers to update host-side prompt snippets, shell themes, app icons, repo badges, social metadata, or package-manager metadata in operator-owned repositories, it must show the exact write before applying it and require explicit consent.

Acceptance Criteria

One canonical source describes the mark, colors, type, spacing, terminal use, web use, app/package use, and copy rules.
Logo artwork consistently includes the by tailrocks byline under jackin❯; ordinary prose and typed commands do not.
Every brand/prose/logo occurrence uses exactly one of j❯, j>, jackin❯, or jackin>, except literal code/command identifiers that must remain jackin.
The chevron uses the canonical bright green in every logo colorway; only surrounding UI accents may use muted green variants.
Favicon and app-icon assets use the short form only, never the full wordmark.
Public docs, README, docs chrome, landing page, favicons, Open Graph assets, and CLI-visible surfaces agree on the same wordmark and monogram.
At least three candidate directions have been sketched across terminal, website, README hero, and favicon constraints before the final mark is chosen.
The chosen standalone mark visibly reduces to the terminal prompt mark.
Live launch flows still follow the Launch Progress TUI roadmap: compact cockpit first, bounded rain lifecycle, stable stage vocabulary, diagnostics handle, and no logo splash replacing the launch UI.
The global text sweep has no stale apostrophe-era brand prose except historical references that are explicitly intentional.
The chevron/letter color relationship is represented in reusable tokens or helpers rather than duplicated ad hoc styling.
CLI and container prompt changes are tested or snapshot-covered enough to prevent accidental same-color marks and apostrophe regressions.
The implementation PR documents which screenshots or external assets were intentionally deferred.
Roadmap and agent rules are updated in the same PR that flips public prose to the new brand spelling.
This roadmap-only PR does not change runtime code, CLI help output, generated assets, or public prose outside the roadmap itself.

Defer

Desktop and mobile app implementation beyond source icon preparation.
Hosted analytics for Open Graph or attribution effectiveness.
Recolorable theme packs, seasonal marks, or per-runtime logo variants.
Automatic host shell prompt installation.
A public brand-kit download page until the mark and generated assets have shipped.

Open Questions

Should #5CF07A fully replace the current docs bright green, or should the old value remain only as a compatibility UI token until the redesign lands?
Should the docs site self-host JetBrains Mono as the mark font if it is not already loaded everywhere the mark appears?
Where should the post-implementation brand spec live: README, a dedicated docs reference page, or a generated brand-kit page?
Should the CLI output prefix be applied to every jackin-owned status line, or only to lifecycle/status lines where subsystem identity matters?
How much screenshot churn is acceptable in the first rebrand PR versus staged follow-ups?
Is j❯ sufficient as the standalone favicon/app icon after repeated prompt exposure, or does the website need a stronger boundary-gate/hardline symbol that contains j❯?
Should by tailrocks appear on small icons, or only on logo-sized lockups where the byline remains legible?
Should the prompt sigil appear only inside jackin-owned agent shells, or also in host-side progress/status output?

AGENTS.md — current agent-only spelling rule that must change with the rebrand implementation
README.md — public repository entry point
docs/src/pages/index.astro — landing page
docs/src/components/overrides/SiteTitle.astro — docs header wordmark
docs/src/styles/docs-theme.css — docs color and font tokens
src/tui/output.rs — CLI output helpers and terminal title
src/tui/animation.rs — current TUI logo animation
docker/runtime/entrypoint.sh — role-container shell/runtime setup surface

Launch Progress TUI — product-surface foundation for launch visualization, rain lifecycle, stage vocabulary, and diagnostics boundaries.

External References

jackin.tailrocks.com — current live visual vocabulary: Operator framing, dark/green terminal surfaces, digital rain, and product language.
GitHub README docs — README visibility and relative image-path behavior.
Ory Brand Guidelines — software-company reference for wordmark/iconmark separation, clear-space rules, product lockups, and technical typography.
Creative Bloq on textless logos — useful caution that textless marks usually need recognition time and often start alongside wordmarks.
DevToolbox terminal ASCII art notes and figlet reference — terminal banner constraints around monospace rendering, width, Unicode support, and large text banners.