Agent skill · software engineering · jeremylongshore
monitor-test-run
Watch a running Kobiton test run and narrate it to the user: read the org's live-remediation flag up front, poll the run until every execution is terminal, surface the live-remediation URL the moment an execution is blocked, and give a correct post-mortem so a COMPLETED-with-BLOCKER_ENCOUNTERED execution is never reported as passed. Quiet on passes, loud on blockers and the final summary; suite runs are grouped by test case. When live remediation is enabled, it asks up front whether to auto-open the live-remediation browser window when a blocker hits. Use when the user asks to "watch", "monitor", "track", or "follow" a test run, or as the natural follow-up right after createTestRun returns a testRunId. The watch runs a bundled poller that emits only on real state changes (no per-poll chatter); uses getOrgSettings up front and terminateTestRun on request, plus the shared chromeless launcher — it does not drive or resolve the blocker itself.
Why this skill is useful
Adds a complete monitoring and reporting automation for Kobiton test runs, including scripts for polling and handling live remediation that are not publicly documented.
What it needs
Requires node installed locally. Requires kobiton account access. About 12k tokens when loaded. Last updated 2026-08-07. 2,604 stars on the source repository.
What this skill does
Overview Given a testRunId, watch the run and narrate it. The skill: 1. Reads liveremediationenabled once via getOrgSettings, so it can explain deterministically what happens when an execution is blocked. 2. Runs the bundled scripts/poll-test-run.js in the background — it watches the run and emits a line only when an execution's state changes (the model never hand-polls). 3. Reacts to those emitted lines: surfaces a blocker (with the live-remediation URL) when one appears, stays silent in between. 4. On the poller's DONE, does a post-mortem so a blocker is never mistaken for a pass. The skill is conversational: its "output" is the messages it posts to the user (events + final summary), not a value returned to a caller. It changes nothing server-side except, optionally, terminateTestRun if the user asks to stop the underlying run. Tool naming. This doc refers to Kobiton MCP tools by their bare names (getOrgSettings, terminateTestRun). The registered name depends on how the host loaded the MCP server (Claude Code as a plugin exposes mcppluginautomatekobitongetOrgSettings; a repo-local .mcp.json exposes mcpkobitongetOrgSettings; other hosts differ). Use the bare name and let the host resolve the prefix. (Run state is read by the bundled poller over REST, not via the MCP getTestRun tool — a background process can't call MCP tools.) Prerequisites Runs on any OS, but needs a local filesystem, Node.js 18+, and ~/.kobiton/.credentials — the watch is a bundled Node poller that reads that file. Where you can't run a local command at all, tell the user to follow the run in the portal instead. A streamed-output affordance is strongly preferred but not required: Claude Code uses the Monitor tool, other hosts substitute their own streamed shell / watch / loop, and a host with none falls back to the foreground loop in Step 2 — see that per-host table, including what NOT to use (a silent detached process misses the blocker window). See the Skill compatibility matrix in CLAUDE.md. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills jeremylongshore/monitor-test-run--3bd36b