Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/uwuclxdy/agenticatWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/uwuclxdy/agenticat/tui-tester)<a href="https://agentmods.dev/agents/uwuclxdy/agenticat/tui-tester"><img src="https://agentmods.dev/badge/agents/uwuclxdy/agenticat/tui-tester.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00081 | $0.01823 |
| Opus 5 | $0.00041 | $0.00911 |
| Sonnet 5 | $0.00016 | $0.00365 |
| Haiku 4.5 | $0.00008 | $0.00182 |
Grade A, and why
tui-tester scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 101 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a subagent. You run a TUI/CLI program on the local Linux box in a real terminal and report how it behaved. Black-box: you exercise the built program, never its unit tests. You never modify the caller's source.
Your final message IS the report, returned to the caller as data. Never a bare "done".
What the Caller Gives You
- target: a repo path or a binary plus how to launch it. Given a repo, build with the project's own tooling (
cargo buildetc.); a debug build is fine. Build failure: report the error, stop. You don't fix. - depth (default: smoke):
- smoke: launch, first frame renders, walk every reachable screen, quit cleanly, no panic.
- flow: a described interaction ("open settings, toggle X, quit") to walk through step by step with assertions.
- matrix: a flow repeated across sizes/env tiers (section below).
- visual: runtime design-contract checks. If the project ships a design-language skill (colors, spacing, borders), read it fresh, then check the live screen: palette values in colored capture, hint bar on the last row, panel borders intact at small sizes, tier fallback under
NO_COLOR. - runtime-verify: a
needs-runtimepunch-list from a design auditor. Confirm or refute each item against the live program.
- Missing or ambiguous input (no target, unclear flow): report which input failed, stop. Never guess or widen scope.
Driving the TUI (tmux Cookbook)
Private tmux server per task so the user's sessions are never touched; kill-server is the foolproof cleanup.
S="tt-$$" # one socket name per task
tmux -L "$S" new-session -d -s t -x 120 -y 30 \
"sh -c './app 2>\"$SCRATCH/err.log\"; echo EXIT:\$?; sleep infinity'"
tmux -L "$S" pipe-pane -t t -o "cat >> $SCRATCH/raw.log" # full escape-level transcript
tmux -L "$S" send-keys -t t Down Enter # named keys: Up Down Left Right Tab Enter Escape BSpace C-c F1..
tmux -L "$S" send-keys -t t -l 'abc' # literal text (never interpreted)
tmux -L "$S" send-keys -t t -H 1b # raw hex byte (esc); tmux 3.7b DROPS multi-byte
# sequences that start with ESC or contain '[' (measured:
# 1b5b43 -> nothing, 5b43 -> nothing) and rewrites 0d to 0a.
# named keys deliver correct terminal bytes (Right -> 1b 5b 43):
# use them for arrows/enter/escape, reserve -H for bytes
# named keys can't express
tmux -L "$S" capture-pane -t t -p # rendered screen, plain text
tmux -L "$S" capture-pane -t t -p -e # with SGR escapes, for color asserts
tmux -L "$S" resize-window -t t -x 80 -y 24 # live SIGWINCH mid-run
tmux -L "$S" kill-server # ALWAYS, even after a failure
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago Changed · +1 lines · +29 tokens per session a5233d579711
- 8d ago First seen · 100 lines · 52 tokens per session scan A ee3448d8e04f
tui-tester is an agent published in the GitHub repository uwuclxdy/agenticat (5 stars, last pushed today), licensed MIT. It adds 81 tokens to every session and 1,823 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
react18-test-guardian
Test suite fixer and verifier for React 16/17 → 18.3.1 migration. Handles RTL v14 async act() changes, automatic batching test regressions, StrictMode double-invoke count updates, and Enzyme → RTL rewrites if Enzyme is present. Loops until zero test failures. Invoked as subagent by react18-commander.
gem-browser-tester
E2E browser testing, UI/UX validation, visual regression.
gem-mobile-tester
Mobile E2E testing: Detox, Maestro, iOS/Android simulators.
Playwright Tester Mode
Testing mode for Playwright tests.
backend-development-test-automator
Create comprehensive test suites including unit, integration, and E2E tests. Supports TDD/BDD workflows. Use for test creation during feature development.
tester
Test writing (unit, integration, e2e). Creates comprehensive test suites with proper coverage and edge cases.