@testdriverai/mcp 7.10.0-canary.0 → 7.10.1-test

package/ai/skills/testdriver-making-assertions/SKILL.md

@@ -1,12 +1,82 @@
 ---
 name: testdriver:making-assertions
-description: Verify application state with AI-powered assertions
+description: Locate elements and verify app state with AI-powered assertions
 ---
 <!-- Generated from making-assertions.mdx. DO NOT EDIT. -->
 
+Once a test runs, validate that the app did what it should. Validation has two parts: locating the elements you want to check, and making assertions about the state of your app. TestDriver uses AI as a judge, returning a boolean plus reasoning about whether your app is in the expected state.
+
+## Locating Elements
+
+### Locating Single Elements
+
+Use natural language to describe elements. Descriptions should be specific enough to locate the element, but not too-specific that they break with minor UI changes. For example:
+
+```javascript
+await testdriver.find('email input field');
+await testdriver.find('first product card in the grid');
+await testdriver.find('dropdown menu labeled "Country"');
+```
+
+<Info>TestDriver will cache found elements for improved performance on subsequent calls. Learn more about [element caching here](/v7/caching).</Info>
+
+### Debugging Found Elements
+
+After finding an element, you can inspect its properties for debugging:
+
+```javascript
+const button = await testdriver.find('submit button');
+console.log(button);
+```
+
+This outputs all element properties:
+
+```javascript
+{
+  description: 'submit button',
+  found: true,
+  x: 150,
+  y: 300,
+  coordinates: { x: 150, y: 300, centerX: 200, centerY: 320 },
+  threshold: 0.8,
+  confidence: 0.95,
+  similarity: 0.92,
+  selector: 'button[type="submit"]',
+  cache: {
+    hit: true,
+    strategy: 'pixel-diff',
+    createdAt: '2025-01-15T10:30:00Z',
+    diffPercent: 0.02,
+    imageUrl: 'https://...'
+  }
+}
+```
+
+### Working with Multiple Elements
+
+Find and interact with multiple elements:
+
+```javascript
+// Find all matching elements
+const products = await testdriver.findAll('product card');
+console.log(`Found ${products.length} products`);
+
+// Interact with each
+for (const product of products) {
+  const title = await product.find('title text');
+  console.log('Product:', title.text);
+
+  await product.find('add to cart button').click();
+}
+
+// Or find specific element
+const firstProduct = products[0];
+await firstProduct.click();
+```
+
 ## Making Assertions
 
-Use AI-powered assertions to verify application state:
+Use AI-powered assertions to verify application state. TestDriver acts as a judge: it evaluates your natural-language statement against the current state of the app and returns a boolean plus reasoning explaining the verdict.
 
 ```javascript
 // Verify visibility
@@ -30,3 +100,9 @@ await testdriver.assert('form has red border');
 ```
 
 <Info>Assertions are not cached and always re-evaluated to ensure accuracy.</Info>
+
+## Next
+
+<Card title="Adapt" icon="arrows-rotate" href="/v7/performing-actions">
+  Drive your app forward by performing actions on the elements you've located and validated.
+</Card>

package/ai/skills/testdriver-mcp-workflow/SKILL.md

@@ -294,7 +294,7 @@ When creating a new test project, use these exact dependencies:
 {
   "type": "module",
   "devDependencies": {
-    "testdriverai": "beta",
+    "testdriverai": "canary",
     "vitest": "^4.0.0"
   },
   "scripts": {
@@ -303,7 +303,7 @@ When creating a new test project, use these exact dependencies:
 }
 ```
 
-**Important:** The package is `testdriverai` (NOT `@testdriverai/sdk`). Always install from the `beta` tag.
+**Important:** The package is `testdriverai` (NOT `@testdriverai/sdk`). Always install from the `canary` tag.
 
 ## Test File Format
 

package/ai/skills/testdriver-parse/SKILL.md

@@ -120,7 +120,7 @@ console.log(`Found ${buttons.length} buttons`);
 
 ```javascript
 import { describe, expect, it } from "vitest";
-import { TestDriver } from "testdriverai/lib/vitest/hooks.mjs";
+import { TestDriver } from "testdriverai/vitest/hooks";
 
 describe("Login Page", () => {
   it("should have expected form elements", async (context) => {

package/ai/skills/testdriver-performing-actions/SKILL.md

@@ -1,9 +1,13 @@
 ---
 name: testdriver:performing-actions
-description: Click, type, hover, scroll and more with TestDriver
+description: Perform actions and handle dynamic, async UI so tests adapt to change
 ---
 <!-- Generated from performing-actions.mdx. DO NOT EDIT. -->
 
+Real apps move, load, and change. Adapt your tests to handle it.
+
+Once you've [generated](/v7/generating-tests) and [learned](/v7/caching) your tests and gotten them [running](/v7/copilot/running-tests), the next challenge is the real world: buttons appear after a spinner, pages navigate, animations play, and content streams in over the network. To keep tests reliable, you need to perform the right actions and handle timing so your tests adapt to how the UI actually behaves instead of breaking.
+
 ## Performing Actions
 
 TestDriver provides a variety of actions you can perform, like [clicking](/v7/click), [typing](/v7/type), [hovering](/v7/hover), and [scrolling](/v7/scroll). For a full list, see the [API Reference](/v7/click).
@@ -27,7 +31,6 @@ await testdriver.find('dropdown menu').hover();
 
 // Scrolling
 await testdriver.scroll('down', 500);
-await testdriver.scrollUntilText('Footer content');
 
 // Waiting
 await testdriver.wait(2000); // Wait 2 seconds for animation/state change
@@ -37,7 +40,7 @@ const price = await testdriver.extract('the total price');
 const orderNumber = await testdriver.extract('the order confirmation number');
 ```
 
-## Chaining Actions
+### Chaining Actions
 
 TestDriver supports method chaining for cleaner code:
 
@@ -52,3 +55,94 @@ Or save element reference for later use:
 const button = await testdriver.find('submit button');
 await button.click();
 ```
+
+## Waiting for Dynamic Content
+
+By default, `find()` automatically polls for up to 10 seconds, retrying every 5 seconds until the element is found. This means most elements that appear after short async operations will be found without any extra configuration.
+
+For longer operations, increase the `timeout`:
+
+```javascript
+// Default behavior - polls for up to 10 seconds automatically
+const element = await testdriver.find('Loading complete indicator');
+await element.click();
+
+// Wait up to 30 seconds for slower operations
+const element = await testdriver.find('Loading complete indicator', { timeout: 30000 });
+await element.click();
+
+// Useful after actions that trigger loading states
+await testdriver.find('submit button').click();
+await testdriver.find('success message', { timeout: 15000 });
+
+// Disable polling for instant checks
+const toast = await testdriver.find('notification toast', { timeout: 0 });
+```
+
+### Flake Prevention
+
+TestDriver automatically waits for the screen and network to stabilize after each action using **redraw detection**. This prevents flaky tests caused by animations, loading states, or dynamic content updates.
+
+<Note>
+  Redraw detection adds a small delay after each action but significantly reduces test flakiness.
+</Note>
+
+For example, when clicking a submit button that navigates to a new page:
+
+```javascript
+// Click submit - TestDriver automatically waits for the new page to load
+await testdriver.find('submit button').click();
+
+// By the time this runs, the page has fully loaded and stabilized
+await testdriver.assert('dashboard is displayed');
+await testdriver.find('welcome message');
+```
+
+Without redraw detection, you'd need manual waits or retries to handle the page transition. TestDriver handles this automatically by detecting when the screen stops changing and network requests complete.
+
+You can disable redraw detection or customize its behavior:
+
+```javascript
+// Disable redraw detection for faster tests (less reliable)
+const testdriver = TestDriver(context, { 
+  redraw: false 
+});
+```
+
+Here is an example of customizing redraw detection:
+
+```javascript
+// Fine-tune redraw detection
+const testdriver = TestDriver(context, { 
+  redraw: {
+    enabled: true,
+    diffThreshold: 0.1,      // Pixel difference threshold (0-1)
+    screenRedraw: true,      // Monitor screen changes
+    networkMonitor: true,    // Wait for network idle
+  }
+});
+```
+
+### Simple Delays with `wait()`
+
+For simple pauses — waiting for animations, transitions, or state changes after an action — use `wait()`:
+
+```javascript
+// Wait for an animation to complete
+await testdriver.find('menu toggle').click();
+await testdriver.wait(2000);
+
+// Wait for a page transition to settle
+await testdriver.find('next page button').click();
+await testdriver.wait(1000);
+```
+
+<Note>
+  For waiting for specific **elements** to appear, prefer `find()` with a `timeout` option. Use `wait()` only for simple time-based pauses.
+</Note>
+
+Once your tests can reliably act on a changing UI and [assert](/v7/making-assertions) the results, the next step is figuring out what happened when something does go wrong.
+
+<Card title="Next: Debug" icon="bug" href="/v7/debugging-with-screenshots">
+  Use screenshots and run output to see exactly what your test saw and pinpoint failures.
+</Card>

package/ai/skills/testdriver-provision/SKILL.md

@@ -14,10 +14,6 @@ Access provision methods via `testdriver.provision.*`:
 await testdriver.provision.chrome({ url: 'https://example.com' });
 ```
 
-<Note>
-  When `reconnect: true` is set on the client, **all provision methods are skipped** since the application is assumed to already be running.
-</Note>
-
 ## Methods
 
 ### chrome()
@@ -234,22 +230,6 @@ await testdriver.provision.dashcam({
 });
 ```
 
-## Reconnect Behavior
-
-When `reconnect: true` is set on the client, all provision methods are wrapped in a Proxy that intercepts calls and skips them silently. This is because when reconnecting to an existing sandbox, the applications are already running.
-
-```javascript
-const testdriver = new TestDriver({
-  reconnect: true,
-});
-
-await testdriver.ready();
-
-// These calls are silently skipped:
-await testdriver.provision.chrome({ url: 'https://example.com' });
-await testdriver.provision.dashcam();
-```
-
 ## Types
 
 ```typescript

package/ai/skills/testdriver-quickstart/SKILL.md

@@ -9,6 +9,53 @@ TestDriver makes it easy to write automated computer-use tests for web browsers,
 <Tip><a href="https://discord.com/invite/cWDFW8DzPm" target="_blank" rel="noreferrer">Join our Discord</a> if you have any questions or need help getting started!</Tip>
 
 <Tabs>
+  <Tab title="Add to GitHub" icon="github">
+
+    Drop-in UI testing for any GitHub repository. Mention `@testdriverai` anywhere in your repo and it writes UI tests and catches regressions before they merge.
+
+    <Card
+      title="Add to GitHub"
+      icon="github"
+      href="https://go.testdriver.ai/github"
+      arrow
+      horizontal
+    >
+      Install the TestDriver GitHub app and start testing in minutes — no setup required.
+    </Card>
+
+    <Steps>
+      <Step title="Install the GitHub App">
+        Click **Add to GitHub** above and install TestDriver on the repositories you want to test.
+      </Step>
+
+      <Step title="Mention @testdriverai">
+        Open a pull request or issue and mention `@testdriverai` to have it write and run UI tests:
+
+        ```
+        @testdriverai Write a test that verifies the homepage loads and the signup button works.
+        ```
+
+        TestDriver spawns a sandbox, writes the test, and posts results right in the conversation.
+      </Step>
+
+      <Step title="Catch Regressions Automatically">
+        Once your tests are committed, TestDriver runs them on every pull request and flags regressions before they merge.
+      </Step>
+    </Steps>
+
+    Want to use TestDriver from GitHub Copilot or the GitHub Mobile app instead? See the full GitHub guide:
+
+    <Card
+      title="GitHub Integration Guide"
+      icon="arrow-right"
+      href="/v7/copilot/auto-healing#use-testdriver-in-github"
+      arrow
+      horizontal
+    >
+      Use TestDriver from GitHub web, Copilot chat, PR reviews, and mobile.
+    </Card>
+
+  </Tab>
   <Tab title="CLI" icon="terminal">
 
     Get started quickly with the TestDriver CLI.
@@ -39,32 +86,263 @@ TestDriver makes it easy to write automated computer-use tests for web browsers,
       </Step>
     </Steps>
   </Tab>
-  <Tab title="GitHub Copilot" icon="github">
+  <Tab title="AI Setup" icon="robot">
 
-    Use the TestDriver VS Code extension with GitHub Copilot for an AI-powered testing workflow.
+    Plug TestDriver into your AI client so you can write, run, and debug real end-to-end tests right from chat. There are three pieces, and `testdriverai init` installs all of them for you:
 
-    <Card
-      title="Install TestDriver for VS Code"
-      icon="/images/content/extension/vscode.svg"
-      href="vscode:extension/testdriver.testdriver"
-      arrow
-      horizontal
-    >
-    </Card>
+    - **The agent** — an expert test-creator that drives a live sandbox, writes code after each step, and reruns the test until it passes.
+    - **Skills** — small instruction files that teach the agent the exact syntax for each TestDriver capability (`find`, `click`, `type`, `assert`, …).
+    - **The MCP server** — exposes TestDriver's computer-use tools over the [Model Context Protocol](https://modelcontextprotocol.io) so any MCP-capable client can use them.
 
-    The extension provides one-click sign-in, project initialization, a live preview panel for watching tests execute, and MCP server configuration for GitHub Copilot.
+    ### Quick install (recommended)
 
-    Once installed, follow the full setup guide to configure MCP and start building tests with AI assistance:
+    `testdriverai init` wires up the agent, skills, and MCP server for you, writing each client's config in the exact format and location it expects:
 
-    <Card
-      title="VS Code + Copilot Setup Guide"
-      icon="arrow-right"
-      href="/v7/copilot/setup"
-      arrow
-      horizontal
-    >
-      Sign in, initialize your project, and configure MCP for GitHub Copilot.
-    </Card>
+    ```bash
+    # interactive — pick your client(s)
+    npx testdriverai init
+
+    # one client
+    npx testdriverai init --client claude-code
+
+    # several
+    npx testdriverai init --client claude-code,cursor,vscode
+
+    # everything
+    npx testdriverai init --client all
+    ```
+
+    <Info>
+    `init` detects clients already present in your project and pre-selects them in the picker. Re-running `init` is safe — it merges the TestDriver entry into existing config without overwriting your other servers.
+    </Info>
+
+    You'll need a TestDriver API key. Create one at [console.testdriver.ai/team](https://console.testdriver.ai/team) and `init` will save it to `.env` as `TD_API_KEY`.
+
+    ### The agent
+
+    The **TestDriver agent** is an expert test-creator that runs inside your AI client (Claude Code, Cursor, VS Code, and others). It writes, runs, and debugs real end-to-end tests by driving your app the same way a person would — using AI vision to find elements, click, type, and assert — through the TestDriver MCP server.
+
+    Unlike a chat assistant that only suggests code, the agent works **iteratively against a live sandbox**: it starts a session, performs each action, writes the generated code to your test file, verifies the result with a screenshot, and reruns the test until it passes.
+
+    During init you'll be asked which AI client(s) to install into. The agent is written to the location each client expects:
+
+    | Client | Agent location |
+    | --- | --- |
+    | Claude Code | `.claude/agents/testdriver.md` |
+    | VS Code (Copilot) | `.github/agents/testdriver.agent.md` |
+    | Cursor | `.cursor/rules/testdriver.mdc` |
+    | Windsurf | `.windsurf/rules/testdriver.md` |
+    | Codex | `AGENTS.md` |
+    | Zed | `.rules` |
+
+    Once installed, invoke it from your client's chat:
+
+    ```text
+    @testdriver write a test that logs in and verifies the dashboard loads
+    ```
+
+    The agent will spin up a sandbox, perform the steps live, write them into a test file under `tests/`, and run it for you.
+
+    ### Skills
+
+    **Skills** are small, focused instruction files — one per TestDriver capability — that teach your AI client exactly how to use each part of the TestDriver SDK and MCP tools. They follow the [Anthropic `SKILL.md` format](https://code.claude.com/docs/en/skills): a folder per skill, each containing a `SKILL.md` with YAML frontmatter and a markdown body.
+
+    There are **106 skills**, generated directly from the TestDriver documentation, covering every action and concept: `find`, `click`, `type`, `assert`, `check`, `scroll`, `press-keys`, `provision`, caching, secrets, CI/CD, and more. They're written to the directory each client expects:
+
+    | Client | Skills location |
+    | --- | --- |
+    | Claude Code | `.claude/skills/<name>/SKILL.md` |
+    | Zed | `.agents/skills/<name>/SKILL.md` |
+    | Codex | referenced from `AGENTS.md` |
+    | VS Code · Cursor · Windsurf | folded into the agent rules/instructions |
+
+    <Note>
+    Skills are **generated, not hand-edited** — each is built from a `.mdx` docs page and carries a `DO NOT EDIT` marker. To change a skill, edit the corresponding documentation page and run `node docs/_scripts/generate-skills.js`.
+    </Note>
+
+    ### MCP server
+
+    The **TestDriver MCP server** exposes TestDriver's computer-use tools — `session_start`, `find`, `click`, `type`, `assert`, `check`, `screenshot`, and more — over the [Model Context Protocol](https://modelcontextprotocol.io). It runs as a local stdio process:
+
+    ```bash
+    npx -p testdriverai testdriverai-mcp
+    ```
+
+    and authenticates with your `TD_API_KEY`. `testdriverai init` configures it for you, but you can also wire it up by hand:
+
+    | Client | Auto-install | MCP config file | Config key |
+    | --- | --- | --- | --- |
+    | Claude Code | ✅ | `.mcp.json` | `mcpServers` |
+    | Claude Desktop | ✅ | OS-specific | `mcpServers` |
+    | Cursor | ✅ | `.cursor/mcp.json` | `mcpServers` |
+    | VS Code (Copilot) | ✅ | `.vscode/mcp.json` | `servers` |
+    | Windsurf | ✅ | `~/.codeium/windsurf/mcp_config.json` | `mcpServers` |
+    | Codex | ✅ | `~/.codex/config.toml` | `[mcp_servers]` |
+    | Zed | ✅ | `.zed/settings.json` | `context_servers` |
+    | Lovable | ⚙️ partial | GitHub `AGENTS.md` + UI | — |
+    | Replit | ⚙️ partial | `replit.md` + UI | — |
+    | v0 (Vercel) | 📝 manual | web UI only | — |
+
+    <Note>
+    Each client uses a **different top-level key** for MCP servers. The most common mistake when configuring by hand is using `mcpServers` for VS Code (it wants `servers`), Codex (TOML `[mcp_servers]`), or Zed (`context_servers`).
+    </Note>
+
+    <Tabs>
+      <Tab title="Claude Code">
+        Add to `.mcp.json` at your project root (or `~/.claude.json` for all projects):
+
+        ```json
+        {
+          "mcpServers": {
+            "testdriver": {
+              "type": "stdio",
+              "command": "npx",
+              "args": ["-p", "testdriverai", "testdriverai-mcp"],
+              "env": { "TD_API_KEY": "${TD_API_KEY}" }
+            }
+          }
+        }
+        ```
+      </Tab>
+
+      <Tab title="Claude Desktop">
+        Edit the Claude Desktop config file:
+
+        - **macOS:** `~/Library/Application Support/Claude/claude_desktop_config.json`
+        - **Windows:** `%APPDATA%\Claude\claude_desktop_config.json`
+        - **Linux:** `~/.config/Claude/claude_desktop_config.json`
+
+        ```json
+        {
+          "mcpServers": {
+            "testdriver": {
+              "command": "npx",
+              "args": ["-p", "testdriverai", "testdriverai-mcp"],
+              "env": { "TD_API_KEY": "your_api_key" }
+            }
+          }
+        }
+        ```
+
+        Restart Claude Desktop after saving.
+      </Tab>
+
+      <Tab title="Cursor">
+        Add to `.cursor/mcp.json` (project) or `~/.cursor/mcp.json` (global):
+
+        ```json
+        {
+          "mcpServers": {
+            "testdriver": {
+              "type": "stdio",
+              "command": "npx",
+              "args": ["-p", "testdriverai", "testdriverai-mcp"],
+              "env": { "TD_API_KEY": "${TD_API_KEY}" }
+            }
+          }
+        }
+        ```
+      </Tab>
+
+      <Tab title="VS Code">
+        Add to `.vscode/mcp.json`. VS Code uses the `servers` key and an `inputs` prompt for secrets:
+
+        ```json
+        {
+          "servers": {
+            "testdriver": {
+              "type": "stdio",
+              "command": "npx",
+              "args": ["-p", "testdriverai", "testdriverai-mcp"],
+              "env": { "TD_API_KEY": "${input:testdriver-api-key}" }
+            }
+          },
+          "inputs": [
+            {
+              "type": "promptString",
+              "id": "testdriver-api-key",
+              "description": "TestDriver API Key From https://console.testdriver.ai/team",
+              "password": true
+            }
+          ]
+        }
+        ```
+      </Tab>
+
+      <Tab title="Windsurf">
+        Windsurf reads MCP config globally. Add to `~/.codeium/windsurf/mcp_config.json`:
+
+        ```json
+        {
+          "mcpServers": {
+            "testdriver": {
+              "command": "npx",
+              "args": ["-p", "testdriverai", "testdriverai-mcp"],
+              "env": { "TD_API_KEY": "${TD_API_KEY}" }
+            }
+          }
+        }
+        ```
+      </Tab>
+
+      <Tab title="Codex">
+        Codex uses TOML. Add to `~/.codex/config.toml`:
+
+        ```toml
+        [mcp_servers.testdriver]
+        command = "npx"
+        args = ["-p", "testdriverai", "testdriverai-mcp"]
+        env = { TD_API_KEY = "${TD_API_KEY}" }
+        ```
+      </Tab>
+
+      <Tab title="Zed">
+        Zed calls them "context servers". Add to `.zed/settings.json` (project) or `~/.config/zed/settings.json` (global):
+
+        ```json
+        {
+          "context_servers": {
+            "testdriver": {
+              "command": "npx",
+              "args": ["-p", "testdriverai", "testdriverai-mcp"],
+              "env": { "TD_API_KEY": "${TD_API_KEY}" }
+            }
+          }
+        }
+        ```
+      </Tab>
+    </Tabs>
+
+    **Web-based clients** — Lovable, Replit, and v0 run in the browser, so the MCP server can't be launched as a local process. Configure them through each product's UI:
+
+    <AccordionGroup>
+      <Accordion title="Lovable">
+        1. Connect your GitHub repo and run `npx testdriverai init --client lovable` — this writes `AGENTS.md` and the skills into the repo so Lovable's agent picks them up.
+        2. In Lovable, open **Settings → MCP** and add the TestDriver server.
+      </Accordion>
+
+      <Accordion title="Replit">
+        1. Run `npx testdriverai init --client replit` to write `replit.md` with the TestDriver agent guidance.
+        2. In Replit, open **Tools → Integrations → MCP** and add a custom MCP server.
+      </Accordion>
+
+      <Accordion title="v0 (Vercel)">
+        v0 is fully UI-driven and does not read repo files.
+
+        1. Open **[v0.app/chat/settings/mcp-connections](https://v0.app/chat/settings/mcp-connections)** and add the TestDriver MCP connection.
+        2. Paste the agent guidance into **Instructions** (the **+** in the prompt bar).
+      </Accordion>
+    </AccordionGroup>
+
+    ### Verifying the install
+
+    Open your client's chat and ask the agent to write a test:
+
+    ```text
+    @testdriver write a test that opens the homepage and asserts the title
+    ```
+
+    If the MCP server is wired up correctly, the agent will start a session and you'll see screenshots come back as it works. If tools don't appear, check that `TD_API_KEY` is set and restart the client.
 
   </Tab>
   <Tab title="Manual" icon="wrench">

package/ai/skills/testdriver-reusable-code/SKILL.md

@@ -49,7 +49,7 @@ Now import and use these helpers in any test:
 
 ```javascript test/checkout.test.mjs
 import { describe, expect, it } from "vitest";
-import { TestDriver } from "testdriverai/lib/vitest/hooks.mjs";
+import { TestDriver } from "testdriverai/vitest/hooks";
 import { login } from './helpers/auth.js';
 
 describe("Checkout", () => {
@@ -120,7 +120,7 @@ Use the page object in your tests:
 
 ```javascript test/auth.test.mjs
 import { describe, expect, it } from "vitest";
-import { TestDriver } from "testdriverai/lib/vitest/hooks.mjs";
+import { TestDriver } from "testdriverai/vitest/hooks";
 import { LoginPage } from './pages/LoginPage.js';
 
 describe("Authentication", () => {
@@ -190,7 +190,7 @@ export async function setupAuthenticatedSession(testdriver, user = testUsers.reg
 
 ```javascript test/admin.test.mjs
 import { describe, expect, it } from "vitest";
-import { TestDriver } from "testdriverai/lib/vitest/hooks.mjs";
+import { TestDriver } from "testdriverai/vitest/hooks";
 import { testUsers, testUrls, setupAuthenticatedSession } from './fixtures/index.js';
 
 describe("Admin Panel", () => {

package/ai/skills/testdriver-running-tests/SKILL.md

@@ -101,7 +101,7 @@ Set `maxConcurrency` in your Vitest config to match your license slot limit:
 
 ```javascript vitest.config.mjs
 import { defineConfig } from 'vitest/config';
-import { TestDriver } from 'testdriverai/vitest';
+import TestDriver from 'testdriverai/vitest';
 
 export default defineConfig({
   test: {