tmux-verify

The outer "is this TUI feature ACTUALLY done?" proof loop for the ainb terminal app. Use when the user asks to "verify the TUI is actually done", "prove this TUI feature works", "validate per tmux-verify", "vhs verify each journey", "frame-truth check the UI", "is the diff actually shown correctly", or to define the acceptance contract for a TUI goal. Orchestrates 6 gates — (1) comprehensive tmux-ui-tripwire passes, (2) a vhs recording per user journey whose frames are READ with /media-processing to assert the EXACT user-visible outcome (not "screen shows something"), (3) one recording per journey, (4) fix-loop until acceptance + tripwire green, (5) a continuous /explain-to-me explainer (tests + commits + GIFs) hosted on /here-now, (6) final HTML-solid validation with the human as the last gate. References (does not reimplement) tmux-ui-tripwire, /media-processing, /explain-to-me, /here-now.

Best use case

tmux-verify is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

The outer "is this TUI feature ACTUALLY done?" proof loop for the ainb terminal app. Use when the user asks to "verify the TUI is actually done", "prove this TUI feature works", "validate per tmux-verify", "vhs verify each journey", "frame-truth check the UI", "is the diff actually shown correctly", or to define the acceptance contract for a TUI goal. Orchestrates 6 gates — (1) comprehensive tmux-ui-tripwire passes, (2) a vhs recording per user journey whose frames are READ with /media-processing to assert the EXACT user-visible outcome (not "screen shows something"), (3) one recording per journey, (4) fix-loop until acceptance + tripwire green, (5) a continuous /explain-to-me explainer (tests + commits + GIFs) hosted on /here-now, (6) final HTML-solid validation with the human as the last gate. References (does not reimplement) tmux-ui-tripwire, /media-processing, /explain-to-me, /here-now.

Teams using tmux-verify should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/tmux-verify/SKILL.md --create-dirs "https://raw.githubusercontent.com/stevengonsalvez/agents-in-a-box/main/ainb-tui/.claude/skills/tmux-verify/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/tmux-verify/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How tmux-verify Compares

Feature / Agenttmux-verifyStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

The outer "is this TUI feature ACTUALLY done?" proof loop for the ainb terminal app. Use when the user asks to "verify the TUI is actually done", "prove this TUI feature works", "validate per tmux-verify", "vhs verify each journey", "frame-truth check the UI", "is the diff actually shown correctly", or to define the acceptance contract for a TUI goal. Orchestrates 6 gates — (1) comprehensive tmux-ui-tripwire passes, (2) a vhs recording per user journey whose frames are READ with /media-processing to assert the EXACT user-visible outcome (not "screen shows something"), (3) one recording per journey, (4) fix-loop until acceptance + tripwire green, (5) a continuous /explain-to-me explainer (tests + commits + GIFs) hosted on /here-now, (6) final HTML-solid validation with the human as the last gate. References (does not reimplement) tmux-ui-tripwire, /media-processing, /explain-to-me, /here-now.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# tmux-verify

## Overview

`tmux-verify` is the OUTER acceptance harness: it proves a TUI feature is *actually* done as a user would experience it. It does NOT write the automated test (that is [tmux-ui-tripwire](../tmux-ui-tripwire/SKILL.md)) and does NOT reimplement media tooling (that is `/media-processing`). It orchestrates both plus a live explainer into one repeatable contract.

Use it two ways:
- **As a contract** — a goal/plan says "validate per `/tmux-verify`" and inherits all 6 gates.
- **As a runner** — execute the gates for a feature end-to-end until green.

The non-negotiable principle: **read the frame, don't blank-check.** A passing screen is one whose pixels/text say the *correct* thing for that journey — not merely that something rendered.

## The 6 gates

```
                         ┌──────────────────────────────────────────────┐
 G1 automated  ───────▶  │ tmux-ui-tripwire: comprehensive, VT100-true,  │
 (ref skill)             │ passes in the real TUI, non-flaky ×3          │
                         └──────────────────────────────────────────────┘
 G2+G3 visual            ┌──────────────────────────────────────────────┐
 (THIS SKILL OWNS) ───▶  │ per journey:  .tape ─▶ vhs ─▶ gif+mp4         │
                         │              ─▶ ffmpeg frames ─▶ READ + assert│
                         │ one recording per journey                     │
                         └──────────────────────────────────────────────┘
 G4 fix-loop   ───────▶  acceptance(cargo test) + tripwire green; unbounded
                         until green or a genuine hard blocker (then log + go on)
 G5 explainer  ───────▶  /explain-to-me ─▶ /here-now  (stable slug, republish
                         each phase: progress · test/clippy/tripwire output ·
                         commit log · embedded per-journey GIFs)
 G6 final      ───────▶  HTML solid (fetch URL: links resolve, GIFs load,
                         no empty sections) ─▶ HUMAN validates → done
```

## Gate-by-gate playbook

### G1 — Automated gate (defer to tmux-ui-tripwire)
Write/repair the feature's `crates/ainb-core/tests/tripwire_*.rs` per [tmux-ui-tripwire](../tmux-ui-tripwire/SKILL.md). Bar to clear:
- **Comprehensive**: asserts VT100 truth (rendered cells, colors, bg attrs, exact counter text) — NOT substring-OR on chrome strings that pass while the feature is broken.
- **Green + non-flaky**: `cargo test -p ainb-core --test tripwire_<feature>` passes 3 runs in a row.
- Respect the documented traps: AMFI SIGKILL (exit 137), first-run-wizard key-swallow, EnvFilter crate-name drift, weak assertions. See that skill's `references/`.
- **tmux safety**: only ever `tmux kill-session -t <exact-name>`. Never `kill-server`, `pkill`, `killall`, or any wildcard.

### G2 + G3 — Visual gate, one recording per journey (this skill owns it)
For EACH journey (define them first — see `references/journeys.md`):
1. **Author the tape** from `scripts/journey.tape.tmpl` — isolated `HOME` (skips the wizard), window size, the exact key sequence, `Screenshot` at each settle point, `Output <journey>.gif` + `.mp4`.
2. **Record + extract + assert** with `scripts/verify-journey.sh` — runs `vhs`, pulls frames via ffmpeg, OCRs them (tesseract, best-effort), and emits the frame paths + a checklist of expected content.
3. **READ the frames** (open the PNGs) and assert the EXACT outcome for that journey — the right diff content, the right file list, word-emphasis on the changed token, the active tab actually changed, Esc landed on the main screen. Recipe + anti-patterns: `references/frame-truth.md`.
4. Keep the `<journey>.gif` (for the explainer) and `<journey>.mp4`.

A journey is unverified until a human-or-agent has *read its frames* and confirmed the content. "Non-blank == pass" is a failure of this gate.

### G4 — Fix loop
If any G1 assertion, any G2 frame-check, or any G5/G6 asset is wrong: diagnose → fix → re-run. **Unbounded** until acceptance tests + tripwire are green and every journey frame-checks clean, or a genuine hard blocker (then log the wall and continue everything parallelizable).

### G5 — Continuous explainer (defer publishing to /explain-to-me + /here-now)
Maintain ONE explainer at a **stable slug**, re-published after every phase/commit. Each republish must contain: current phase + progress, the latest `cargo test` / `clippy` / tripwire output, the commit log so far, and the embedded per-journey GIFs. Build it with `/explain-to-me` (status-report / PR-review template) and publish with `/here-now`; `scripts/publish-explainer.sh` checks the dir then prints the exact `/here-now` invocation. Cadence + required sections: `references/explainer.md`.

### G6 — Final HTML-solid validation
Before declaring done, FETCH the live URL and confirm: every link resolves, every GIF loads, no section is empty/placeholder, the test output shown is the latest green run. Then hand the human the live URL — **the human is the final acceptance gate.** Do not merge on their behalf unless the goal says so.

## Quick start

```bash
SK=ainb-tui/.claude/skills/tmux-verify
AINB=$(find ainb-tui/target -name ainb -type f -perm +111 | head -1)   # or: cargo build -p ainb-core

# 1. one journey: render tape, record, extract+OCR frames, print checklist
bash $SK/scripts/verify-journey.sh \
  --name open-g --bin "$AINB" \
  --keys 'Type "G"  Sleep 2s  Screenshot "{OUT}/open-g.png"' \
  --out /tmp/ainb-journeys --expect "Code Review" --expect "skill.rs"
# → then READ /tmp/ainb-journeys/frames/open-g*.png and assert content

# 2. publish/refresh the explainer (after building it with /explain-to-me)
bash $SK/scripts/publish-explainer.sh --dir /tmp/ainb-explainer --slug ainb-warp-diff
```

## Done checklist (all true)
- [ ] G1 tripwire comprehensive + green + non-flaky ×3
- [ ] G2/G3 every journey has its own gif+mp4 AND its frames were read + asserted (content correct)
- [ ] G4 `cargo test -p ainb-core` + `clippy -D warnings` green
- [ ] G5 explainer live on /here-now at the stable slug, current
- [ ] G6 HTML fetched + solid; live URL handed to the human

## References
- `references/journeys.md` — define a journey; the worked ainb diff-review journey set
- `references/frame-truth.md` — vhs → frames → READ + assert; anti-patterns
- `references/explainer.md` — the continuous /explain-to-me → /here-now cadence
- Sibling: [tmux-ui-tripwire](../tmux-ui-tripwire/SKILL.md) (G1). Tooling: `/media-processing` (vhs/ffmpeg/imagemagick), `/explain-to-me`, `/here-now`.

Related Skills

tmux-status

8
from stevengonsalvez/agents-in-a-box

Show status of all tmux sessions including dev environments, spawned agents, and running processes

tmux-monitor

8
from stevengonsalvez/agents-in-a-box

Monitor and report status of all tmux sessions including dev environments, spawned agents, and running processes. Uses tmuxwatch for enhanced visibility.

tmux-message

8
from stevengonsalvez/agents-in-a-box

Reliable peer-to-peer message delivery to other Claude Code instances via tmux send-keys. Use as a fallback when claude-peers MCP send_message fails to surface in the receiver's inbox (delivered server-side but receiver never picks it up — observed behaviour). Also use when sending a directive to a known Claude Code TUI session by tmux session name or fuzzy hint, or when injecting a multi-line directive into a peer's prompt and submitting it. Trigger phrases — "claude-peers fallback", "tmux send-keys", "send to peer via tmux", "inject directive", "deliver to nanoclaw/hermes peer", "peer message". Tmux-only — won't reach peers running outside tmux.

browser-verify

8
from stevengonsalvez/agents-in-a-box

Combined AI browser testing + visual inspection. Runs expect-cli for automated test generation/execution, then debug-bridge for screenshots and DOM inspection. Use when you need to verify UI changes with both automated tests AND visual evidence. Trigger on "verify in browser", "browser verify", "visual test", "test and screenshot", or after completing UI fixes that need proof.

tmux-ui-tripwire

8
from stevengonsalvez/agents-in-a-box

Write or debug tmux-driven end-to-end TUI tests ("tripwires") for the ainb terminal app. Use when the user asks to "write a tmux test", "add a tripwire", "verify the TUI in tmux", "test feature X by pressing key Y", "validate plugin Z renders", or when editing any file under `crates/ainb-core/tests/tripwire_*.rs`. Codifies the silent traps we hit during Phase 7 plugin testing — macOS AMFI SIGKILL of staged binaries (exit 137, no stderr), first-run wizard intercepting keystrokes, EnvFilter crate-name drift hiding logs, and substring-OR assertions that pass while the feature is broken. Use proactively before writing any new `tripwire_*.rs` test, and reference whenever an existing tripwire fails for non-obvious reasons.

workflow

8
from stevengonsalvez/agents-in-a-box

Guide through structured delivery workflow with plan, implement, validate phases

webapp-testing

8
from stevengonsalvez/agents-in-a-box

Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.

validate

8
from stevengonsalvez/agents-in-a-box

Verify implementation against specifications

ui-ux-pro-max

8
from stevengonsalvez/agents-in-a-box

UI/UX design intelligence. 67 styles, 96 palettes, 57 font pairings, 25 charts, 13 stacks (React, Next.js, Vue, Svelte, Astro, Nuxt, SwiftUI, React Native, Flutter, Tailwind, shadcn/ui, Jetpack Compose). Actions: plan, build, create, design, implement, review, fix, improve, optimize, enhance, refactor, check UI/UX code. Projects: website, landing page, dashboard, admin panel, e-commerce, SaaS, portfolio, blog, mobile app, .html, .tsx, .vue, .svelte. Elements: button, modal, navbar, sidebar, card, table, form, chart. Styles: glassmorphism, claymorphism, minimalism, brutalism, neumorphism, bento grid, dark mode, responsive, skeuomorphism, flat design. Topics: color palette, accessibility, animation, layout, typography, font pairing, spacing, hover, shadow, gradient.

tui-style-guide

8
from stevengonsalvez/agents-in-a-box

TUI style guide for consistent terminal interface design

token-usage

8
from stevengonsalvez/agents-in-a-box

Show Claude Code token usage across sessions — daily, weekly, per-project, and per-session breakdowns. Parses {{HOME_TOOL_DIR}}/projects/**/*.jsonl for consumption data. Use when the user asks about token usage, costs, how many tokens were used, session statistics, or wants a usage report.

test-driven-development

8
from stevengonsalvez/agents-in-a-box

Use when implementing any feature or bugfix, before writing implementation code. Enforces RED-GREEN-REFACTOR cycle with test-first approach.