tty-design
Skill4 starsChanged 6 months agoMITView on GitHub
Design and refine terminal TTY/TUI command flows for CLIs, especially pickers, menus, status screens, and interactive prompts. Use when work involves raw terminal mode, ANSI styling, session or symbol selectors, keyboard-driven CLI menus, or making terminal UX more scannable and reliable across terminal emulators.
In this repository10 other files it gives its agents.
- clean-commitSkill
- clean-merge-pushSkill
- cleanSkill
- evolutionary-5-stepSkill
- investigate-fixSkill
- owner-checkSkill
- owner-cleanSkill
- stateful-planning-protocolSkill
- technical-design-dossierSkill
- writing-ticksSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
21 rules. About 0 are common, 20 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈20
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 10
Use this skill when a CLI flow needs an interactive terminal surface rather than plain prompts.
- Distinctive: line 24
Put raw-mode input, alternate-screen lifecycle, redraw behavior, scrolling, and width handling in a shared shell.
- Distinctive: line 25
Keep layouts strictly left-aligned.
- Distinctive: line 26
Do not place independent bits of information across the screen.
- Distinctive: line 32
Always show the current symbol, entity, or target in the title or status line.
- Distinctive: line 43
start with nothing selected
- Distinctive: line 48
Do not silently switch between single-select and multi-select semantics without changing the flow or making the scope obvious.
- Distinctive: line 52
Never show options that cannot actually be acted on.
- Distinctive: line 56
when only one eligible upstream entity exists, skip that selection step
- Distinctive: line 57
when skipping an upstream step, make the downstream picker clearly state the scope
- Distinctive: line 69
Prefer short labeled lines over dense inline tables.
- Distinctive: line 89
Use ANSI styling sparingly:
- Distinctive: line 97
Do not rely on color alone to communicate state.
- Distinctive: line 101
If the user must type freeform input inside a TTY flow:
- Distinctive: line 104
avoid long wrapped instruction sentences
- Very specific: line 106
keep the actual input line visually distinct, for example with >
- Distinctive: line 118
Every TTY flow should still have a non-interactive fallback:
- Distinctive: line 124
Do not let the fallback path drift into different semantics from the TTY path.
- Distinctive: line 129
If more than one eligible upstream entity exists, pick one.
- Distinctive: line 132
Keep output-writing and execution outside the TTY module.
- Distinctive: line 136
When changing a TTY flow, verify:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
TTY Design
Use this skill when a CLI flow needs an interactive terminal surface rather than plain prompts.
Goal
Produce TTY flows that are:
- consistent across commands
- readable at a glance
- safe in raw terminal mode
- compatible with common ANSI terminals, tmux panes, and narrow widths
Core Rules
- Separate terminal mechanics from workflow semantics. Put raw-mode input, alternate-screen lifecycle, redraw behavior, scrolling, and width handling in a shared shell. Keep command-specific logic limited to option eligibility, row formatting, filters, and post-selection execution.
- Keep layouts strictly left-aligned. Do not place independent bits of information across the screen. Use vertical grouping: title, status, controls, examples, body, footer.
- In raw mode, render lines with
\r\n, not bare\n. Bare linefeeds can drift horizontally in raw-mode redraws. - Make ANSI styling width-safe. Trim, indent, and wrap based on visible width, not raw string length. ANSI escape sequences must not affect width math.
- Scope the screen explicitly. Always show the current symbol, entity, or target in the title or status line. Do not assume the user remembers upstream context.
Selection Semantics
Single-select
entermay accept the highlighted row- preselecting the first option is acceptable
Multi-select
- start with nothing selected
spaceshould feel additiveentermust require at least one marked option- provide
afor select all visible andufor clear
Do not silently switch between single-select and multi-select semantics without changing the flow or making the scope obvious.
Eligibility Rules
Never show options that cannot actually be acted on.
- symbol pickers should only show symbols with eligible downstream sessions
- session pickers should respect the current minimum-duration or other filter
- when only one eligible upstream entity exists, skip that selection step
- when skipping an upstream step, make the downstream picker clearly state the scope
Header Design
Headers should be grouped into short lines:
- title
- status line
- blank spacer
- controls
- examples or filter syntax
Prefer short labeled lines over dense inline tables.
Good:
Select BTC sessionsBTC 6 visible 2 selected filter noneMove j/k Mark spaceConfirm enterBulk a all, u clearFilter f durationQuit q
Avoid:
- one-line control dumps
- right-aligned fragments
- explanatory paragraphs inside the picker
Styling
Use ANSI styling sparingly:
- bold title
- emphasized active cursor marker
- clear selected state
- dim secondary metadata
- limited accent color for scope or active state
Do not rely on color alone to communicate state.
Prompt Design
If the user must type freeform input inside a TTY flow:
- show examples on their own line
- avoid long wrapped instruction sentences
- include the current value when useful
- keep the actual input line visually distinct, for example with
>
Example:
Minimum duration for visible sessions
Examples: 300, 15m, 1h, 1h30m | blank clears | current none
>Fallback Contract
Every TTY flow should still have a non-interactive fallback:
- numbered plain-text listing
- explicit input prompt
- same eligibility rules as the TTY path
Do not let the fallback path drift into different semantics from the TTY path.
Recommended Implementation Pattern
- Resolve eligible entities first.
- If more than one eligible upstream entity exists, pick one.
- Open the shared picker for downstream selection.
- Return typed selections to the command code.
- Keep output-writing and execution outside the TTY module.
Verification
When changing a TTY flow, verify:
- raw-mode redraw stays left-aligned
- ANSI styling does not break trimming
- narrow widths still keep key information visible
- multi-select preserves multiple marks
- single-select and multi-select
entersemantics differ correctly - omitted upstream arguments still produce the intended flow
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

