TUI Expert

This skill provides the architectural and interaction foundation for terminal user interfaces across Rust, Ruby, Go, and other ecosystems. It owns the interactive surface; the separate cli-design skill owns scriptable command contracts.

Compose the TUI with a CLI

When a tool has both interfaces, load cli-design and keep them as sibling presentation adapters over shared application behavior.

• Preserve an established bare-command TUI when compatibility requires it; for new automation-first tools, prefer an explicit <tool> tui entry.
• Make important TUI reads and mutations available through documented non-interactive commands unless the operation is inherently visual or continuous.
• Keep auth, configuration, validation, permissions, dry-run behavior, and result semantics consistent across both interfaces.
• Keep rendering, keyboard state, and navigation out of the CLI layer; keep stdout/stderr formatting and pipe behavior out of the TUI state model.
• Test parity for the same operation through the shared application layer, then test each adapter's terminal contract separately.

Do not duplicate a domain-specific CLI tree here. Use the CLI skill to derive commands from the product's actual resources and workflows.

Core Architectural Pattern: The "Orchestrated State"

Regardless of the language, modern TUIs follow a state-driven approach where the UI is a pure function of the application state.