command-center/agent/managed-skills/omp-tui-live-visual-verify/SKILL.md

name, description

name	description
omp-tui-live-visual-verify	Verify omp TUI config changes (status line, composer, theme) live: edit watched config, niri screenshot, PIL crop, restore — with the flag and race pitfalls.

Live visual verification of omp TUI config

When

Changing ~/.omp/agent/config.yml (statusLine., composer., theme) on a Frank workstation and needing PROOF of how it renders — not inference from the bundle. The status-line/composer knobs are file-watched: edits repaint the RUNNING session; no restart.

Loop (per trial)

1. Read the live config line(s) first; edit with edit (never batch trials — one state per screenshot).
2. Capture: sleep 2 && niri msg action screenshot-screen --path /tmp/x.png --show-pointer false — flag is --path (-o is invalid); the write lands asynchronously, so sleep 1.5 before touching the file.
3. Crop+scale with PIL to the bar/composer region (known good crop for blankpad right monitor: (2267,1240,3440,1440), 1.3x LANCZOS), then read the PNG absolute path.
4. For pixel facts (rule colors, meter lengths) don't eyeball alone: scan rows with Image.load() counting dominant colors; sample every 2px and lower thresholds before concluding "nothing found".
5. After the matrix, RESTORE the original values and re-screenshot the baseline.

Pitfalls

• Read a downscaled FULL-screen shot first: Frank's screens carry multiple terminals + a browser; a fixed crop can silently capture a different window's bars (happened during the contextLine audit — two omp windows on one screen).
• Session-accent rules/borders share colors with meters; color presence alone proves nothing. Compare states against each other, and settle ambiguous pixels from the bundle code path (grep dist/cli.js for the render function).
• Live config drifts (other sessions own files there): never git add -A the main checkout to promote a trial; commit from a separate git worktree add off the target ref.
• read the absolute /tmp/... path for screenshots.
• Multi-value enums: one screenshot per value; identical renders (e.g. claude shape contextLine: off vs embedded) are themselves a finding — record them as such.