monitor-test-runlisted

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.
kobiton/automate · ★ 12 · AI & Automation · score 78

Install: claude install-skill kobiton/automate

## Overview Given a `testRunId`, watch the run and narrate it. The skill: 1. Reads `live_remediation_enabled` **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 `mcp__plugin_automate_kobiton__getOrgSettings`; a repo-local `.mcp.json` exposes > `mcp__kobiton__getOrgSettings`; 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