Problem or Use Case

Hermes has a YAML skin system that supports custom colors, branding, banner logo/hero art, spinner settings, tool emojis, and tool prefixes. The pure YAML skin path works well for basic visual customization, but there are two limitations today that affect any non-trivial custom skin:

1. The CLI and TUI skin support are not fully aligned.

   The Python skin engine exposes fields such as spinner, tool_emojis, status bar colors, completion menu colors, selection_bg, and shell_dollar, but the TUI gateway payload and TUI theme types only consume a subset of those fields. This means a skin can define values that are valid at the skin-engine layer but are ignored or hardcoded in the TUI.

2. The startup/session panel is not configurable.

   Both CLI and TUI currently render a fixed default Tools + Skills style panel. That default is useful, but it is hardcoded. There does not appear to be a supported way to choose a different panel type for users who want startup/session context oriented around a different workflow, such as operational agent status, project status, recent sessions, MCP state, or a minimal focused panel.

The result is that deeper skin and startup/session customization currently requires local source patches. Those patches are fragile because they need to be reapplied or repaired after hermes update. This seems like a general theming/configuration gap rather than something specific to one skin.

Proposed Solution

Add a configurable startup/session panel slot and improve the TUI skin bridge so it consumes the same skin semantics as the Python skin engine.

1. Add a startup/session panel slot

Make the current panel explicit as the default, while allowing users to select alternate built-in panel types.

Simple form:

─ yaml startup_panel: default

Example alternate form:

─ yaml startup_panel: agent_stats

default would preserve current behavior: Tools + Skills + optional MCP details.

agent_stats is just one example of a possible built-in panel type. It could render operational state useful for users running multiple Hermes profiles/gateways, such as:

• active profile / agent roster • gateway health • session count, message count, and tool-call count • channel/source distribution, such as cli, cron, discord, telegram, etc. • active model/provider/context signal • recent skills, if available

The broader idea is not limited to stats. The goal is to make the startup/session panel a configurable slot rather than a hardcoded layout. Future built-in panel types could include examples like:

─ yaml startup_panel: minimal startup_panel: sessions startup_panel: mcp startup_panel: project

A future more extensible shape could also be considered:

─ yaml startup_panel: type: agent_stats

That would leave room for section-level options later, for example:

─ yaml startup_panel: type: agent_stats sections: - profiles - gateway_health - channels - session_counts - model_signal

But a simple string enum would be enough as a first step.

Unknown values should gracefully fall back to default.

1. Improve TUI skin parity

Extend the TUI skin payload/types/mapping to cover the fields the skin engine already supports or documents. In particular:

• spinner • tool_emojis • status_bar_dim • status_bar_good • status_bar_dim • status_bar_good • status_bar_good • status_bar_critical • status_bar_critical • status_bar_critical

Implementation-wise, this likely means updating:

Implementation-wise, this likely means updating: Implementation-wise, this likely means updating: • ui-tui/src/gatewayTypes.ts so the payload is typed • ui-tui/src/gatewayTypes.ts so the payload is typed • ui-tui/src/gatewayTypes.ts so the payload is typed • Data collection should be best-effort and degrade gracefully. • CLI and TUI should remain aligned in behavior where possible.

────────────────────────────────────

• CLI and TUI should remain aligned in behavior where possible.

────────────────────────────────────

• CLI and TUI should remain aligned in behavior where possible.

Alternatives Considered

Local source patches

I tested local patches that added an alternate startup/session dashboard behind a skin flag. This proved the use case, but it is not a good long-term approach because local source patches are overwritten or broken by updates.

A boolean such as show_stats: true

This works for a single local experiment, but it is not the right upstream API. It sounds like a small display toggle, while the actual behavior is selecting a different startup/session panel layout. A string enum like startup_panel: agent_stats is clearer and leaves room for future panel modes, such as minimal, sessions, mcp, or project.

A fully custom user-defined panel system immediately

A fully pluggable panel system would be powerful, but it may be too large for a first implementation. A small set of built-in panel types behind a stable startup_panel option would solve the immediate problem while keeping the design open for future extensibility.

A skill

This does not seem like a good fit for a skill. The feature affects first-class CLI/TUI rendering, typed TUI JSON-RPC payloads, and the skin/theme system itself. It cannot be implemented cleanly as instructions or shell commands.

Feature Type

CLI improvement

Scope

Medium (few files, < 300 lines)

Contribution

• I'd like to implement this myself and submit a PR

Debug Report (optional)

I am happy to test and review the behavior. I may be able to help with a PR, but I wanted to confirm the desired upstream API before implementing.

This is a feature request based on source inspection rather than a runtime crash.

Relevant upstream files inspected:

• hermes_cli/skin_engine.py
• hermes_cli/banner.py
• tui_gateway/server.py
• ui-tui/src/gatewayTypes.ts
• ui-tui/src/theme.ts
• ui-tui/src/components/branding.tsx

I also searched existing issues and did not find an obvious duplicate for configurable startup/session panels or TUI skin parity.