| name | bridge-greeting |
| description | Context-aware terminal greeting (MOTD) for Bridge instances — renders a per-instance logo, palette, today's filtered calendar, the instance's "Doing" board and uncommitted work, resolved from which org folder the terminal was opened in. Includes gen-logo.py (ANSI-Shadow logo generator from a word) and the branding convention that feeds every Bridge UI. Trigger: "/bridge-greeting", "terminal greeting", "motd", "startup logo", "instance logo", "terminal greeting", "fastfetch logo", "branding", "generate logo", "per-folder terminal", "folder logo". |
| metadata | {"scope":"core"} |
Bridge Greeting
A login-shell greeting that is instance-aware: the org folder you open the
terminal in resolves to a Bridge instance, and the greeting then shows that
instance's identity — logo, colours, calendar tags, task board, and repos.
Home / unknown dirs → the full system dashboard (fastfetch cascade + global
board). Inside an org tree → a focused panel for the resolved instance.
The model — branding belongs to the Bridge, not the script
The greeting reads its visual identity from the resolved instance's theme
(themes/<theme>.yaml → branding: block), so a logo "comes from" its Bridge
instance the same way identity/agent/ and vocabulary do. Three layers:
| Layer | Owns | Tier |
|---|
Engine (scripts/render-motd.sh) | discovery, rendering, board parsing — no instance literals | CORE → open-bridge |
Theme branding (themes/<theme>.yaml branding:) | logo path, logo_color_1/2, calendar_tags per instance | per-instance |
Local override (~/.config/fastfetch/bridge-motd.local.sh) | per-org fallbacks for instances whose theme has no branding: yet; the org→instance machine map | USER (machine-local, never committed) |
Discovery scans ~/Developer/*/*/bridge-config.yaml to build the
org-folder → instance map automatically — no hardcoded instance names in the engine.
Purpose tagline — the instance's north-star under the logo
When the resolved instance's bridge-config.yaml has a non-empty
purpose.statement, render it as the subtitle / tagline directly under the
logo, alongside the theme-derived identity the greeting already shows — so the
terminal opens reading as what this Bridge is for, not a bare wordmark. Empty
purpose.statement → no tagline line (today's behaviour). This is display only; the
purpose never changes what the greeting can show.
gen-logo.py — make an instance its logo
uv run --with pyfiglet python scripts/gen-logo.py --top ACME --bottom CORP > assets/logos/acme.txt
uv run --with pyfiglet python scripts/gen-logo.py --top ACME --umlaut 1 > assets/logos/acme.txt
--umlaut N re-adds a diaeresis over the N-th letter of --top (figlet drops
non-ASCII glyphs, so an umlaut would otherwise be lost). Output carries fastfetch
$1/$2 colour placeholders; the actual colours are applied at render time
from the theme's logo_color_1/2.
--pipe false is mandatory when fastfetch output is captured — a plain
--pipe strips every SGR code, leaving the logo uncoloured.
Setup — advise, don't assume
Branding is taste. When setting up (or reconfiguring) an instance's greeting —
during onboarding or on /bridge-greeting — consult the user, propose,
let them decide (Bridge house style: advise, don't act). Ask, per instance:
- Wordmark + subtitle — top word, optional second line (e.g. a unit/role).
- Colour mode — one of:
monochrome — no colour, renders in the terminal's own foreground
(set logo_color_1/2: none). For users who want a plain, uncoloured logo.single — one uniform colour, no two-tone alternation
(logo_color_1 == logo_color_2).two-tone — distinct logo_color_1/logo_color_2 (gradient feel).
- Calendar tags — which calendars surface for this instance.
Write the chosen values into that instance's theme branding: block (or the
machine-local override). Never hardcode a palette — default to asking.
Deploy (thin-shim pattern)
scripts/render-motd.sh is the single source of truth. .zshrc calls a
one-line shim at ~/.config/fastfetch/bridge-motd.sh that execs the repo engine
— so it auto-follows git pull, no copy to re-deploy:
ENGINE="$HOME/Developer/<org>/<your-bridge>/skills/bridge-greeting/scripts/render-motd.sh"
[[ -r "$ENGINE" ]] && exec bash "$ENGINE" "$@"
Per-machine data stays out of the repo: logo files in
~/.config/fastfetch/logos/, per-org overrides in
~/.config/fastfetch/bridge-motd.local.sh (USER, never committed).
Two renderers, one concept (macOS + Windows)
The greeting is platform- and provider-pluggable. The same three-layer
model (generic engine · instance config · branding asset) has two engines:
| macOS arm | Windows arm |
|---|
| Engine | scripts/render-motd.sh (bash + fastfetch) | scripts/render-greeting.ps1 (PowerShell + ANSI) |
| Data source | GitHub Projects V2 (gh) | Azure DevOps — WIQL / pipelines / commits (az) |
| Instance config | bridge-motd.local.sh (BRIDGE_MOTD_*) | $BridgeGreetingConfig hashtable |
| Branding | theme branding: block | same assets/logos/*.txt + colour |
| Deploy | .zshrc shim → repo engine | $PROFILE shim → dot-source engine + config |
render-greeting.ps1 is generic — no instance literals. A profile dot-sources
it plus an instance config, then calls Show-BridgeGreeting -Config $cfg. The
config is a hashtable: Label, Logo (a assets/logos/*.txt reused as-is —
the PS renderer decodes the same $1/$2 + \u{} format), Color1/Color2,
Provider, an Ado block (Org, Project, RepoId, ResourceId, Branch),
and an ordered Sections array (Kind ∈ workitems/pipelines/commits,
with per-section Wiql, Title, Empty). No config → it greets with just the
header. Results cache to JSON (default 1 h TTL).
Provider = 'azure-devops' is implemented; github is a documented extension
point (add a Get-GhSection dispatch — the rest of the engine is
provider-agnostic).
Windows deploy mirrors the thin-shim idea but dot-sources by $PSScriptRoot
(a dev-box typically has no Bridge clone, so the engine + config + profile ship
as siblings in the PowerShell profile folder, e.g. a cloud-synced one):
# Microsoft.PowerShell_profile.ps1 (thin shim)
. "$PSScriptRoot\render-greeting.ps1"
. "$PSScriptRoot\bridge-greeting.config.ps1" # defines $BridgeGreetingConfig
Show-BridgeGreeting -Config $BridgeGreetingConfig
The instance config + its logo + the deployed profile are USER scope and
live in that instance's own Bridge repo, never here — exactly like the macOS
local override. The engine is the only CORE/promotable piece.
Branding everywhere
branding.logo_* is the terminal rendering of one brand identity that also
feeds the web UIs (bridge-deck, the :8790 ops dashboard, the :8793 control
center, bridge-explorer). The shared SoT for web surfaces is DESIGN.md
(palette + wordmark tokens). See references/architecture.md.
Layering (core / org overlay / instance)
- open-bridge: engine +
gen-logo.py + a generic OPEN BRIDGE logo + neutral palette. Discovery, no literals.
- your org overlay (
<your-org>/<your-bridge>): a sample logo + palette as the default branding:.
- per-instance (USER): each instance's own logo, org→instance map, calendar tags — local, never promoted.
