---
description: Live-test an interactive CLI/TUI in observable terminal/tmux
argument-hint: "<command-or-app> :: <scenario/use-case>"
---

# Live Terminal Test

Live-test an interactive terminal app like a skeptical user.

**Scenario**:
$ARGUMENTS

Scope:

- interactive CLI/TUI apps, REPLs, prompts, installers, editors, agents when the
  agent itself is the terminal app under test
- terminal rendering, keyboard input, busy/idle states, cancel/abort, reload,
  resize, long-running output, logs/watchers when they support the terminal flow

Out of scope:

- browser UI testing; use `/live-browser-test`
- pure unit tests, deterministic functions, non-interactive API helpers
- nested agents unless the target app is an agent

## Parse Scenario

Extract:

- command/app to run
- cwd/project
- workflow/use case
- success criteria
- risks to watch

If the command, cwd, or destructive impact is ambiguous, ask one focused
question before launching.

## Skills

Load when needed:

- `tmux` — required for pane creation, pane IDs, input, capture, notes,
  readiness, and cleanup policy.
- `nushell` — if the pane shell is `nu` or `nu.exe`.
- `wezterm` — only if attaching visibly through WezTerm.

## Rules

- Use a fresh dedicated tmux socket/session/window.
- Use pane IDs (`%12`), not pane indexes.
- Keep a pane map and notes file from the start.
- Probe user shell and pane command before sending input.
- Wait for readiness; never sleep-and-hope.
- Send only user-like keystrokes to the app pane.
- Do setup, file inspection, and complex scripting from tools, not by pasting
  big shell snippets into panes.
- Do not hide `C-c` in generic send helpers. Interrupts are explicit tests.
- If input merges, goes to the wrong shell, or pollutes a pane, stop using that
  pane as product evidence.
- Leave tmux alive for inspection unless the user asks cleanup.

## Workflow

1. Inspect local docs/help for the target app.
2. Start tmux harness with one session and one window; panes OK.
3. Record socket/session/window, pane IDs, cwd, command, shell, and notes path.
4. Launch the target command.
5. Drive happy path, rough path, cancel/abort, and one busy/long-running path
   when relevant.
6. Verify claims with hard evidence: pane captures, files, logs, exit status,
   diffs, and app-owned artifacts.
7. Record bugs with steps, expected, actual, severity, and evidence.

## Report

```text
LIVE_TERMINAL_TEST_DONE
notes: /tmp/<file>.md
tmux attach: tmux -L <socket> attach -t live
tmux kill: tmux -L <socket> kill-server
command: ...
shell: user=<shell> pane=<shell>
result: pass|issues found|blocked
findings:
- [severity] title — evidence/repro
```

Ask before killing tmux.