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", "mon
npx skills add jeremylongshore/claude-code-plugins-plus-skills --skill monitor-test-run --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
What it does
Watches a Kobiton test run and narrates events to the user. It reads the live-remediation flag up front, streams a poller that reports only on state changes, surfaces blockers with the live-remediation URL when they appear, and performs a post-mortem so a COMPLETED-with-BLOCKER_ENCOUNTERED is never reported as passed. If live remediation is enabled, it can prompt for auto-opening the live-remediation window and, on blockers, may auto-open the remediation window. It groups results by test case and remains quiet on passes, being loud on blockers and the final summary.
How it works
- Reads the live_remediation_enabled flag once via getOrgSettings and caches it as flagOn; if reading fails, assumes OFF and informs the user once.
- Derives the portal base URL from the MCP server URL in .mcp.json, mapping API host to portal host; uses that as <portal> (fallback to https://portal.kobiton.com if mapping fails).
- If flagOn is true, optionally records an autoOpen preference up front based on caller input (otherwise prompts once before monitoring).
- Runs the bundled poller in the background:
- Executes: node $SKILL_DIR/scripts/poll-test-run.js --run-id <testRunId>
- Emits lines only when an execution state changes; exits when DONE.
- Reacts to emitted lines:
- On READY portal=<base> caches portal base.
- On EVENT dispatched exec=… device=…: quiet one-liner at most.
- On EVENT blocked exec=… device=…: loud surface with blocked status and URL when blocker appears (live remediation URL built from <portal> and device id).
- On EVENT resumed exec=…: post a concise "execution … resumed".
- On terminal lines: accumulate for final summary; surface blocker-encountered as blocker, never as pass.
- On DONE: perform final post-mortem; if blockers occurred, surface the final summary accordingly.
- Surface blockers with full device view URL: <portal>/devices/launch?id=<device> and provide a deterministic explanation based on flagOn.
- If autoOpen is enabled, open the live-remediation window via run-automation-suite’s chromeless-launcher on each blocker event when appropriate. If autoOpen is not enabled, only post the URL.
When to use it
Use when the user asks to "watch", "monitor", "track", or "follow" a Kobiton test run, or as a follow-up after createTestRun returns a testRunId.
What it can touch
- Reads: getOrgSettings
- Terminates: terminateTestRun (on request)
- Runs: node scripts/poll-test-run.js
- Opens: run-automation-suite's chromeless-launcher for live remediation (when autoOpen = yes)
- Accesses: <portal> URL derived from MCP server, not hardcoded
Caveats
- Requires an authenticated Kobiton MCP connection; getOrgSettings requires the automate plugin release that ships it.
- The watch loop uses the bundled poll-test-run.js and reads credentials from ~/.kobiton/.credentials; a background process cannot call MCP tools directly.
- If flagOn is false, blockers end immediately with BLOCKER_ENCOUNTERED; no live window is opened.
- If event lines show device=-, surface blocker text without a URL and note INVALID_EXECUTION_STATE.
## 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. R
What does the monitor-test-run skill do?
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", "mon
How do I install it?
Run `npx skills add jeremylongshore/claude-code-plugins-plus-skills --skill monitor-test-run --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From jeremylongshore/claude-code-plugins-plus-skills, a repository with 2,596 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.