com um clique
tui-design-system
// Visual language and UX patterns for Textual TUI applications in dlab
// Visual language and UX patterns for Textual TUI applications in dlab
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.
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.
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".
| 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 |