메뉴
Create distinctive, production-grade terminal user interfaces. Use when building TUI components with ratatui, CLI output styling, or xterm.js terminal rendering. Triggers: 'design TUI', 'terminal UI', 'TUIデザイン', 'ターミナルUI', 'ratatui widget'
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | tui-design |
| description | Create distinctive, production-grade terminal user interfaces. Use when building TUI components with ratatui, CLI output styling, or xterm.js terminal rendering. Triggers: 'design TUI', 'terminal UI', 'TUIデザイン', 'ターミナルUI', 'ratatui widget' |
| allowed-tools | Bash, Read, Glob, Grep, Edit, Write |
Create distinctive, production-grade terminal user interfaces with high design quality. Use this skill when building TUI components, CLI tools, or terminal-based interfaces. Generate creative, polished code that avoids generic terminal aesthetics.
frontend-design skill insteadBefore coding, understand the context and commit to a BOLD aesthetic direction:
Choose a clear conceptual direction and execute it with precision. A dense information dashboard and a zen single-focus interface both work — the key is intentionality, not intensity.
Choose border styles that match your aesthetic:
┌─┐│└┘ — Clean, modern╔═╗║╚╝ — Bold, formal, retro-mainframe╭─╮│╰╯ — Soft, friendly, modern┏━┓┃┗┛ — Strong, industrial┄┆ — Light, airy, informal+-+| — Retro, universal compatibility█▀▄▌▐ — Chunky, bold, brutalist◢◣◤◥, ●○◐◑, ▲▼◀▶ for unique framesAvoid defaulting to simple single-line boxes. Consider asymmetric borders, double-thick headers, or decorative corners like ◆, ◈, ✦, ⬡.
Commit to a cohesive palette. Terminal color strategies:
Create atmosphere with:
░▒▓█Palette examples (invent your own):
#ff00ff, electric cyan #00ffff, deep purple #1a0a2e background#ffb000 on black, like vintage CRTsThe terminal is ALL typography. Make it count:
H E A D E R→ • ◆ ★ ⚡ λ ∴ ≡ ⌘- with ▸ ◉ ✓ ⬢ › or themed symbolsASCII Art Styles:
Block: ███████╗██╗██╗ ███████╗
Slant: /___ / / // / / ____/
Small: ╔═╗┌─┐┌─┐
Minimal: [ HEADER ]
Break free from single-column output:
Terminals support dynamic content:
|/-\. Use Braille patterns ⠋⠙⠹⠸⠼⠴⠦⠧⠇⠏, dots ⣾⣽⣻⢿⡿⣟⣯⣷, custom sequences▓░, █▒, [=====> ], or creative alternatives like ◐◓◑◒▁▂▃▄▅▆▇█ for inline mini-charts├── └── │ for hierarchies● green, ○ empty, ◐ partial, ✓ complete, ✗ failed[████████░░] with percentageAdd character without clutter:
───── ═════ •••••• ░░░░░░ ≋≋≋≋≋≋▶ SECTION, [ SECTION ], ─── SECTION ───, ◆ SECTION· ∙ ░NEVER use generic terminal aesthetics like:
[INFO], [ERROR] prefixes without styling---- dividers| Framework | Language | Notes |
|---|---|---|
| ratatui | Rust | gwt terminal rendering |
| xterm.js v6 | TypeScript | gwt GUI terminal emulation (WebView) |
| Rich, Textual | Python | General purpose |
| Bubbletea, Lipgloss | Go | General purpose |
| Ink, Blessed | Node.js | General purpose |
\x1b[1m Bold
\x1b[3m Italic
\x1b[4m Underline
\x1b[31m Red foreground
\x1b[38;2;R;G;Bm True color
\x1b[2J Clear screen
The terminal is a canvas with unique constraints and possibilities. Don't just print text — craft an experience.
Match implementation complexity to the aesthetic vision. A dense monitoring dashboard needs elaborate panels and live updates. A minimal CLI needs restraint, precision, and perfect alignment. Elegance comes from executing the vision well.
Use when execution should start from a GitHub Issue, gwt-spec Issue, or approved standalone task through one build/test/verify loop.
Use when implementation should proceed from an approved SPEC or approved standalone task, and the work should run through the build/test/verify loop.
Use when the user wants to create, inspect, update, or unblock a pull request and expects one visible entrypoint for the PR lifecycle.
Use when implementation needs verification before completion or before opening a PR. Defines a project-agnostic Generic Verification Contract: classify changed surfaces, autodetect the project's test runners from manifests (Cargo.toml / package.json / pyproject.toml / go.mod / ProjectSettings / *.sln / etc.), run the appropriate unit / integration / E2E / visual tests for the project, emit an evidence bundle that lists exactly which tests were executed, then hand off to the user with a 4-step 導線 (build → launch → navigate → observe) and check items before declaring Overall: PASS. Triggers: 'verify', 'run tests', 'pre-PR check', 'gwt-verify'.
Use when an idea, spec question, or implementation gap needs investigation and discussion before deciding how work should proceed.
Use when the user wants to resolve an existing GitHub Issue by number or URL, especially when the workflow should continue through a direct fix unless a SPEC is needed.