Menu
Visual language and UX patterns for Textual TUI applications in dlab
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | TUI Design System |
| description | Visual language and UX patterns for Textual TUI applications in dlab |
Design decisions for all Textual TUI apps in this project. Follow these patterns when creating or modifying TUI screens.
monokai (set on App class: theme = "monokai")align: left bottom — content anchors to bottom-left, where terminal users lookwidth: 66% — two-thirds of terminalheight: auto — only as tall as content. Add max-height: 80% on VerticalScroll containers to preserve scrollabilityHeader() or Footer() — the terminal stays dark above and to the right of the contentEvery interactive element gets a colored left border + surface background:
Input {
border: none;
border-left: tall $accent;
height: 1;
padding: 0 1;
background: $surface;
&:focus { border: none; border-left: tall $accent; }
}
OptionList {
border: none;
border-left: tall $accent;
background: $surface;
scrollbar-size: 1 1;
}
Checkbox groups use a .cb-group wrapper with the same treatment:
.cb-group {
border-left: tall $accent;
background: $surface;
padding: 0 1;
}
Use DpackCheckbox (subclass of Checkbox) with custom glyphs:
▢▣BUTTON_LEFT = "", BUTTON_RIGHT = ""_button property to swap glyph based on self.valueCSS for visibility on dark backgrounds:
Checkbox > .toggle--button { color: $text-muted; }
Checkbox.-on > .toggle--button { color: $success; }
App-level bindings for field navigation:
Binding("down", "focus_next", show=False),
Binding("up", "focus_previous", show=False),
Binding("left", "focus_previous", show=False),
Binding("right", "focus_next", show=False),
These only fire when the focused widget doesn't consume the key (Input consumes left/right for cursor, OptionList consumes up/down for selection).
.cb-group: Tab jumps OUT of the container to the next element outside. Implemented via DpackCheckbox.action_tab_out() which walks ancestors to find the .cb-group parent, then focuses the first widget after it in screen.focus_chain:focus-within:.option-hint { display: none; color: $text-muted; text-style: italic; height: 1; }
.selection-group:focus-within .option-hint { display: block; }
dock: right:#next-btn, #create-btn, #done-btn, #skip-btn, #keep-btn { dock: right; }
Horizontal(classes="nav-bar") with height: 1When user selects an item in an OptionList (e.g. package manager), auto-advance focus to the next element via on_option_list_option_selected → self.screen.focus_next().
[b]Step N of M[/b] — Title as .field-label.field-label with margin-top: 1.field-hint and .cb-desc with color: $text-muted; text-style: italic.error-label with color: $error.section-divider with color: $accentButton {
min-width: 10;
border: none;
background: $surface;
&:hover { background: $primary; }
&.-success { background: $success-muted; &:hover { background: $success; } }
}
All variants have border: none. No special styling for -primary variant (buttons look uniform).
When user input might conflict with existing state (e.g. decision-pack name already exists):
variant="error", with color: $text CSS override for visibility)Horizontal(id="collision-bar") so they sit side by sideFor long-running operations (e.g. generating files, downloading):
@work(thread=True) methodon_progress: Callable[[str], None] callbackapp.call_from_thread(label.update, message)Uses monokai hex colors for consistency:
| Role | Color | Hex |
|---|---|---|
| Process start | monokai cyan | #66D9EF |
| Completion | monokai green | #A6E22E |
| Action/tool | monokai orange | #FD971F |
| Error | monokai red | bold #F92672 |
| Selection/identity | monokai purple | #AE81FF |
| Background info | monokai comment | #75715E |
| Main text | monokai foreground | #F8F8F2 |
Guide a human through creating a dlab decision-pack by asking questions and then calling generate_dpack(). Use this skill whenever the user wants to create, set up, or scaffold a new decision-pack, agent environment, or Docker-sandboxed config for dlab — even if they don't use the word "decision-pack" explicitly. Trigger on phrases like "set up a new agent", "create an environment for X", "I want to run opencode for Y", "scaffold a project", or "make a new config".
How to create a dlab decision-pack directory using generate_dpack() from Python code
Complete reference for decision-lab (dlab). Use when the user asks about creating decision-packs, designing data science agents, running sessions, analyzing results, or anything related to dlab CLI, agent architecture, parallel subagents, or decision-pack configuration. Covers the full workflow from scaffolding to analysis.
Methodology for probabilistic forecasting of when and whether a future event will occur. Covers Bayesian survival models, reference class reasoning, driver threshold models, leading indicator models, scenario decomposition, and causal mechanism models. Use for any question of the form "When will X happen?" or "What is the probability that Y occurs by date Z?"
Design agent system prompts, parallel architectures, and methodological guardrails for data science decision-packs. Use when creating orchestrator, subagent, or parallel agent systems for analytical workflows. Covers anti-fabrication rules, epistemic humility, when to stop, conflict detection, uncertainty reporting, retry protocols, prompt design principles, and the decision-lab runtime mechanics.
Navigate and analyze completed dlab session directories. Use when pointed at a work directory to understand what happened during a run — explore logs, outputs, parallel agent results, and the skills/prompts that shaped the analysis.