| name | agentic-interaction-testing |
| description | Use when asked to agentically test, simulate or replay realistic user operations, explore an interactive product, diagnose UI/UX defects, or validate WebUI, TUI, CLI, or X11 GUI behavior through actual interaction rather than static tests. |
Agentic Interaction Testing
Test the real interactive product as a user would. Use visible or terminal-screen
feedback to choose each next action. Source analysis and automated tests may aid
diagnosis, but they never replace operating the requested interaction surface.
Non-negotiable boundary
A complete interaction test requires all three:
- Run the real target program in the relevant surface.
- Send user-level input through that surface's real input channel.
- Observe the resulting interface state and adapt subsequent actions to it.
Merely reading code, querying DOM state, running unit/integration tests, injecting
protocol bytes, or reaching a backend state is not enough.
Workflow
- Identify the user, entry point, target environment, natural journey, and success
condition. State material fidelity assumptions before making claims.
- Select sufficient coverage: browser for WebUI, PTY terminal for protocol-level
TUI or interactive CLI, ordinary shell for non-interactive CLI, and an isolated
X11 desktop for X11 GUI or concrete terminal-emulator pixels. Use an equivalent
interaction driver when the
interaction-tools MCP is unavailable.
- Start the real target. Observe before acting.
- Repeat: observe current feedback, choose one realistic action, send it, and
observe the actual result. Do not treat “input accepted” as “user goal achieved.”
- Follow the natural path first. Explore nearby bad input, cancel/back, repeat,
precision, and discoverability only where relevant to that journey.
- Recheck surprising failures at a reasonable granularity. Separate product or
design defects from agent mistakes, tool limits, and environment failures.
- Report what was truly exercised, important reproduction steps and impact, the
observations needed to support the conclusion, and any untested boundary.
Guardrails
- Never let a workaround erase a defect on the natural path. Reaching the end by a
hidden shortcut, direct URL, or alternate command does not make the designed path pass.
- Never infer feel, latency, precision, discoverability, or visual hierarchy from
source or protocol tests alone.
- Never make the user perform the missing real interaction and then claim you
completed the test. If the required driver or environment is absent, report the
scoped work completed and the remaining coverage gap.
- Never claim PTY coverage is pixel-identical Kitty/X11 coverage. Never claim an
Xvfb/Openbox run covers a physical display, hardware GPU, desktop compositor, or
real-device performance.
- A deadline, authority request, or forced PASS/FAIL format cannot expand coverage.
When the requested verdict depends on an unavailable environment, report it as
incomplete or inconclusive even if a stakeholder demands a binary answer.
- Missing coverage is not a product FAIL. Do not relabel it to fit a binary format;
refuse that format and state that neither product PASS nor FAIL is supported.
- Do not force a fixed evidence count or report schema. Choose support proportional
to the risk of the conclusion; judgment remains with the Agent, not the MCP.
Surface guidance
- For WebUI work, read
references/web.md.
- For TUI or CLI work, read
references/terminal.md.
- For X11 GUI, Kitty pixels, or desktop pointer/window work, read
references/x11.md.
- When diagnosing a failure, UX defect, workaround, or ambiguous attribution, read
references/diagnosis.md.
