tui.md

 1# Go TUIs
 2
 3Read [../tui.md](../tui.md), [baseline.md](baseline.md), [mise.md](mise.md),
 4[cli.md](cli.md), [testing.md](testing.md), and
 5[preferred-libraries.md](preferred-libraries.md) before applying these Go TUI
 6specifics.
 7
 8This file captures Amolith-specific Go TUI setup choices only. Load `golang-tui`
 9after this file for Bubble Tea, Lip Gloss, Bubbles, Elm Architecture, layout,
10keymap, terminal-compatibility, testing, and performance details.
11
12TUIs are still command-line binaries. Keep the Cobra/Fang setup, command
13ergonomics, completions, and version-policy guidance from [cli.md](cli.md) in
14force.
15
16## Amolith-specific deltas
17
18- Use the Charm v2 stack through `golang-tui` unless the project has already made
19  a different good choice.
20- Do not copy Taskfile examples from `golang-tui`; translate useful commands into
21  `mise.toml` and keep the baseline tasks from [mise.md](mise.md).
22- Keep the CLI surface consistent with [cli.md](cli.md): stdlib for tiny tools,
23  Cobra/Fang for user-facing commands, and one project-owned version policy when
24  exact versions matter.
25- Use the regular race-enabled Go test task from [mise.md](mise.md). Add
26  snapshot/golden update tasks only when the project actually has snapshot tests.
27- Terminal apps should use the same pure-Go static release-build shape as CLIs
28  when their dependencies allow it. Drop static-only flags for terminal
29  integrations that require CGO or native libraries.
30
31If `golang-tui` and this skill conflict, keep `golang-tui` for library/API
32details and keep this skill for Amolith-specific tooling, task-runner,
33packaging, CLI, and release-build policy.