terminal-ux

Solid

Behavior rules for command-line and terminal programs: exit codes, stdout versus stderr, TTY detection, NO_COLOR and palette choice, progress output, help conventions, destructive-action confirmation, signal and panic handling, plus TUI keyboard and screen-reader concerns. Use when writing or reviewing a CLI, a TUI, argument parsing, terminal output, prompts, or terminal color handling.

Web & Frontend 5 stars 0 forks Updated today MIT

Install

View on GitHub

Quality Score: 80/100

Stars 20%
26
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# Terminal UX How a terminal program should behave. Two different things live here and their rules diverge: - **CLI**: a command that runs, prints, and exits. No persistent screen. State is communicated by printing what changed. - **TUI**: a full-screen interactive app that owns the terminal until it quits. A grid that redraws. Every rule below says which it applies to. A CLI rule does not automatically hold for a TUI, and the sources differ: `clig.dev`, the 12-factor CLI writeup, GNU, and POSIX are CLI-first, while the TUI material comes from ratatui, Bubble Tea, Textual, and accessibility practitioners. How solid a rule is: - **convention**: documented in a widely-adopted guide or standard. - **house style**: one project's stated choice. Reasonable, not universal. - unmarked: reasoning by analogy from graphical UI, with nothing behind it. Weigh it lower. Terminal accessibility gets its own file, `references/accessibility.md`. There is no WCAG equivalent for terminals, so nothing there is a conformance floor. Read it anyway: it holds the one rule most likely to make a TUI unusable for someone. --- ## 1. Output Streams **CLI, convention.** stdout carries the program's actual output. stderr carries everything about the run. **Do:** - Put primary output, the thing another program would consume, on stdout. - Put logs, warnings, errors, and human-watched progress on stderr, so a pipe does not swallow them and they do not corrupt the data stream. - Surface a subpro...

Details

Author
uwuclxdy
Repository
uwuclxdy/agenticat
Created
5 months ago
Last Updated
today
Language
TypeScript
License
MIT

Bundled in these plugins

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Listed

sota-cli-ux

State-of-the-art CLI and developer-tool UX guidance (2026) covering command and flag design, output and interaction (stdout/stderr, --json, TTY detection, exit codes, prompts), runtime behavior and lifecycle (signals, dry-run, idempotency, XDG paths, completions, telemetry), and distribution (packaging, checksums, docs). Use when designing or building any command line tool, subcommand, TUI, or developer tool — in any framework (argparse, click, typer, clap, cobra, oclif, commander) — AND when auditing an existing CLI for usability, scriptability, and compatibility. Not for shell-script correctness or security — use sota-shell-scripting. Trigger keywords: CLI, command line tool, flags, subcommands, terminal output, TUI, developer tool, argparse, clap, cobra, exit code, shell completion, man page, stdin, stdout.

8 Updated 3 days ago
martinholovsky
Web & Frontend Listed

tui-design

Design and build clean, professional, minimal terminal UI (TUI) applications and command-line tools. Use this skill whenever the user is building, designing, refactoring, reviewing, or asking about terminal interfaces — full-screen TUIs (file managers, dashboards, monitors, git/k8s tools, REPLs), interactive CLI prompts, or simple command-line utilities. Use it for library questions ("Bubble Tea vs Ratatui vs Textual vs Ink"), design questions ("how should I lay out this dashboard"), and concrete build requests ("build me a TUI for X"), even when the user doesn't say "TUI" explicitly — phrases like "terminal app", "ncurses-style", "interactive shell tool", "CLI dashboard", "fzf-like picker", or naming a known TUI app (lazygit, k9s, btop, helix, yazi) all qualify.

1 Updated 2 days ago
gfargo
Web & Frontend Solid

ux-patterns

Interaction-design knowledge pack for how a UI behaves: the five screen states (loading, success, error, empty, partial), form validation and submission, error copy, undo versus confirmation, progressive disclosure, plus the accessibility wiring each needs. Use when building a screen's states, wiring validation, choosing a spinner or skeleton, wording an error, or deciding between a confirmation and an undo.

5 Updated today
uwuclxdy