From tui-designer
This skill should be used when the user asks to "design a TUI", "build a terminal UI", "create a TUI for X", "improve this CLI into a TUI", "make this interface feel like a modern dev tool", "design a dashboard like k9s", "build something like lazygit", "make a TUI like htop", or describes wanting a fast, keyboard-first, professional terminal interface. Apply this skill whenever the user wants to design, plan, or build a Terminal User Interface at any fidelity — from rough layout to full implementation plan. <example> Context: User wants to build a terminal UI for their tool user: "Design a TUI for a Kubernetes resource explorer" assistant: "I'll apply the TUI Builder skill to design a production-grade k9s-style TUI." <commentary> User is asking for a TUI design. Use TUI Builder to produce all 8 sections: UX philosophy, layout, interaction model, design system, components, performance, tech recommendation, and implementation plan — all grounded in the research report. </commentary> </example> <example> Context: User wants to modernise an existing CLI user: "Make my log viewer CLI feel like a modern dev tool" assistant: "I'll use the TUI Builder skill to redesign it as a professional terminal UI." <commentary> User wants to upgrade a CLI to a full TUI. Apply TUI Builder to produce a complete design with keyboard-first interaction, semantic colour system, and LogView component specification. </commentary> </example>
How this skill is triggered — by the user, by Claude, or both
Slash command
/tui-designer:tui-designerThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Design and build production-grade Terminal UIs grounded in research-backed principles. This skill operates as a senior TUI engineer + product designer: decisive, opinionated, and optimised for speed, clarity, keyboard efficiency, and low cognitive load.
Design and build production-grade Terminal UIs grounded in research-backed principles. This skill operates as a senior TUI engineer + product designer: decisive, opinionated, and optimised for speed, clarity, keyboard efficiency, and low cognitive load.
The primary research source is references/deep-research-report.md (bundled with this skill). All design decisions must trace back to its principles. Consult the specialised reference files in references/ for domain-specific detail.
Extract principles, patterns, and heuristics from the research before designing. Apply them through decisions, not by citing text. When something falls outside the research, use best judgment and mark it clearly as an extension.
Reference files to consult:
references/deep-research-report.md — Full primary research (ecosystem, design, security, performance)references/library-comparison.md — Framework trade-offs (Rust/Go/Python/Node), selection criteria, comparison tablereferences/design-system.md — Color tokens, accessibility, typography, icon systemreferences/interaction-patterns.md — Keyboard-first design, keymaps, components, layout patternsreferences/performance-security.md — Rendering models, performance presets, terminal compatibility, securityreferences/configuration-state.md — Config persistence (XDG), signal handling, async data architecture, debuggingIf the request is underspecified, ask 1–2 sharp questions before proceeding:
Skip questions if the request is already clear enough to produce a useful design.
Always produce all 8 sections below. Be decisive. Avoid hedging.
State the TUI archetype and the mental model it imposes on the user.
Archetypes (choose one):
State which research principles are driving the design. Examples:
Produce an ASCII layout diagram. Label every panel.
┌─────────────────────────────────────────────────┐
│ Header: title + mode indicator + status │
├──────────────┬──────────────────────────────────┤
│ │ │
│ Navigation │ Main Content │
│ Panel │ (primary focus) │
│ │ │
├──────────────┴──────────────────────────────────┤
│ Footer: context-sensitive keybinding hints │
└─────────────────────────────────────────────────┘
Describe:
Design keyboard-first. Every action must have a keyboard binding. Mouse is an optional assist.
Produce the keymap table using the action-first DSL pattern from the research:
| Action | Keybinding | Description |
|---|---|---|
action.quit | q / Ctrl+C | Quit application |
action.help | ? | Toggle help overlay |
action.search | / | Open search/filter |
action.focus_next | Tab | Advance focus ring |
action.focus_prev | Shift+Tab | Reverse focus ring |
action.nav_down | j / ↓ | Move down in list |
action.nav_up | k / ↑ | Move up in list |
action.nav_top | g | Jump to top |
action.nav_bottom | G | Jump to bottom |
action.select | Enter | Activate item |
action.back | Esc | Close modal / go back |
Add domain-specific actions relevant to the use case. Define keybindings for all dangerous operations behind a confirmation modal (action.confirm / action.cancel).
Design using semantic tokens, not hardcoded colours. Consult references/design-system.md for the full token system.
Core design principles from the research:
fg.default, fg.muted, fg.danger, bg.panel, border.focused, border.inactiveNO_COLOR support mandatorySpecify:
Select and specify the components needed. Consult references/interaction-patterns.md for component behaviour, states, and performance notes.
For each component, specify:
Standard components available (from research):
| Component | Use when |
|---|---|
List | Primary navigation, item selection |
Table | Structured data with sortable columns |
Tree | Hierarchical data (files, processes, configs) |
LogView | Streaming or historical log display |
Form | Structured data entry with validation |
Modal | Confirmations, dangerous actions, prompts |
HelpBar | Context-sensitive keybinding hints (always visible) |
CommandPalette | Fuzzy search over actions/navigation |
Progress | Async operation feedback |
Tabs | Multiple views within a panel |
Security rule: Any component displaying untrusted content (logs, remote data, git objects, resource names) must pass through the sanitisation layer — strip ESC (\x1b) and C0 control characters. This directly addresses CWE-150 terminal injection.
State the rendering model and performance preset based on the target environment.
Presets from the research:
local_default: 30–60 FPS for animations, 10 TPS background tick, truecolourssh_safe: 10 FPS max, low TPS (4), no full-screen gradients, 256-colour fallbacklow_cpu: Render on events only; animations replaced with discrete state stepsArchitecture principles:
Choose the best stack. Be decisive. Justify with performance, ecosystem, and developer experience.
Consult references/library-comparison.md for the full trade-off matrix.
Quick selection heuristic:
State the chosen stack, the primary reason, and one alternative with trade-offs.
Produce a concrete step-by-step build plan.
Architecture layers (always apply this structure):
Suggested module/file structure — adapt to chosen language:
src/
main.{rs,go,py,ts} # Entry point, terminal setup, event loop
app.{rs,go,py,ts} # Application state model
ui/
layout.{rs,go,py,ts} # Panel layout and focus manager
components/ # Reusable widgets (list, table, logs, modal)
theme.{rs,go,py,ts} # Semantic token definitions
data/
fetcher.{rs,go,py,ts} # Async data loading
sanitize.{rs,go,py,ts} # Untrusted content sanitisation
keymaps.{rs,go,py,ts} # Action DSL and keybinding table
Build sequence (incremental, each step produces a runnable artifact):
| File | Contents |
|---|---|
references/deep-research-report.md | Full primary research: ecosystem, design, security, performance (authoritative source) |
references/library-comparison.md | Full framework comparison, selection guide, trade-off matrix |
references/design-system.md | Token system, colour palettes, accessibility, typography, icon registry |
references/interaction-patterns.md | Component catalogue, layout archetypes, keyboard patterns, exemplary TUIs |
references/performance-security.md | Rendering models, performance presets, terminal compatibility, CWE-150 security |
references/configuration-state.md | Config persistence (XDG), signal handling, async data patterns, debugging, state design |
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub fabio-ribeirob/tui-designer --plugin tui-designer