@muggleai/works 4.2.2 → 4.3.0

package/plugin/skills/muggle-test-import/SKILL.md

@@ -0,0 +1,276 @@
+---
+name: muggle-test-import
+description: >
+  Bring existing tests and test artifacts INTO Muggle Test — from Playwright, Cypress, PRDs,
+  Gherkin feature files, test plan docs, Notion exports, or any source.
+  TRIGGER when: user wants to import/migrate/load/upload/add/convert existing test files or
+  test docs into Muggle — e.g. "import my playwright tests", "migrate from cypress to muggle",
+  "upload my PRD to muggle", "add my e2e specs to our muggle project", "load these test cases
+  into muggle", "turn this feature file into muggle test cases", "create muggle test cases from
+  my PRD", "track my specs in muggle", or any .spec.ts/.cy.js/.feature/.md file + muggle.
+  DO NOT TRIGGER when: user wants to run/replay Muggle scripts, scan a site, generate new
+  tests from scratch, or check existing test results.
+---
+
+# Muggle Test Import
+
+This skill migrates existing test artifacts into Muggle Test. It reads your source files,
+structures them into use cases and test cases, gets your approval, then creates everything
+in a Muggle project via the API.
+
+## Concepts
+
+- **Use case**: A high-level feature or user workflow (e.g., "User Registration", "Checkout Flow")
+- **Test case**: A specific scenario within a use case (e.g., "Register with invalid email", "Complete checkout with Visa card")
+
+---
+
+## Step 1 — Identify source files
+
+Ask the user which files to analyse. Accept glob patterns, directory paths, or individual files. Common sources:
+
+| Source type | Typical patterns |
+|---|---|
+| Playwright | `**/*.spec.ts`, `**/*.test.ts`, `e2e/**` |
+| Cypress | `**/*.cy.js`, `**/*.cy.ts`, `cypress/integration/**` |
+| PRD / design doc | `*.md`, `*.txt`, `docs/**` |
+| Other | Any file the user points to |
+
+If the user is vague, scan the current directory for test file patterns and show what you found.
+
+Also ask for the **base URL of the app under test** if it is not embedded in the source files — you will need it for every test case.
+
+Confirm the final file list before reading.
+
+---
+
+## Step 2 — Analyse and extract structure
+
+The extraction strategy depends on the file type. Choose the right path before reading.
+
+### Path A — PRD / design documents (preferred for document sources)
+
+Muggle has a native PRD processing workflow that extracts use cases more accurately than
+manual parsing. Use this path for `.md`, `.txt`, `.pdf`, or any prose document.
+
+After authentication and project selection (Steps 4–5), come back and:
+1. Read the file and base64-encode its content
+2. Call `muggle-remote-prd-file-upload` with the encoded content and filename
+3. Call `muggle-remote-workflow-start-prd-file-process` using the fields returned by the upload
+   (`prdFilePath`, `contentChecksum`, `fileSize`) plus the project URL
+4. Poll `muggle-remote-wf-get-prd-process-latest-run` until the status is complete
+5. After processing, call `muggle-remote-use-case-list` to retrieve the created use cases and
+   their IDs — then skip Step 6 Pass 1 (use cases are already created) and go straight to
+   creating any additional test cases if needed
+
+> Note: base64-encode in-memory using a Bash one-liner or Python — do not modify the file.
+
+If the native workflow fails or the document is in a format it cannot parse, fall back to
+Path B (manual extraction).
+
+### Path B — Code-based test files (Playwright, Cypress, etc.)
+
+Read each file and extract a **use case → test case** hierarchy manually.
+
+- `describe()` / `test.describe()` block → use case name
+- `it()` / `test()` block → test case
+- Pull `page.goto('...')` calls for the URL
+- Derive `goal` and `expectedResult` from assertion text and comments
+
+### Path B — General rules (applies to manual extraction)
+- Group thematically related tests under one use case when there is no explicit `describe()` grouping
+- Never leave `goal` or `expectedResult` blank — infer them from context
+- Assign priority: `HIGH` for critical paths and error handling, `MEDIUM` for secondary flows, `LOW` for edge cases
+
+Build an internal model before presenting anything to the user (Path B only):
+
+```
+Use Case: <Name>
+  - TC1: <title> | goal | expectedResult | precondition | priority | url
+  - TC2: ...
+```
+
+---
+
+## Step 3 — Review with user
+
+Present the extracted structure clearly. Example format:
+
+```
+Found 3 use cases with 8 test cases:
+
+1. User Authentication  (3 test cases)
+   ✦ [HIGH]   Login with valid credentials
+   ✦ [HIGH]   Login with wrong password shows error
+   ✦ [MEDIUM] Forgot password flow sends reset email
+
+2. Shopping Cart  (3 test cases)
+   ✦ [HIGH]   Add item to cart
+   ✦ [MEDIUM] Remove item from cart
+   ✦ [LOW]    Cart persists after page reload
+
+3. Checkout  (2 test cases)
+   ✦ [HIGH]   Complete checkout with credit card
+   ✦ [HIGH]   Checkout fails with invalid payment info
+```
+
+Ask:
+- "Does this structure look right?"
+- "Anything to add, remove, rename, or re-prioritise before I import?"
+
+Incorporate feedback, then confirm: "Ready to import — shall I proceed?"
+
+> For Path A (native PRD upload): present the use case/test case list that Muggle extracted
+> after the processing workflow completes, and ask the user to confirm before adding any
+> extra test cases manually.
+
+---
+
+## Step 4 — Authenticate
+
+Call `muggle-remote-auth-status` first.
+
+If already authenticated → skip to Step 5.
+
+If not authenticated:
+1. Tell the user a browser window is about to open.
+2. Call `muggle-remote-auth-login` (opens browser automatically).
+3. Tell the user to complete login in the browser.
+4. If the call returns before the user finishes, call `muggle-remote-auth-poll` to wait for completion.
+
+---
+
+## Step 5 — Pick or create a project
+
+Call `muggle-remote-project-list` and show the results as a numbered menu:
+
+```
+Existing projects:
+  1. Acme Web App
+  2. Admin Portal
+  3. Mobile API
+
+Or: [C] Create new project
+```
+
+**If creating a new project**, propose values based on what you learned from the source files:
+- **Name**: infer the app name from filenames, URLs, or document headings (e.g., "Acme App")
+- **Description**: "Imported from [filename(s)] — [date]"
+- **URL**: the base URL of the app under test
+
+Show the proposal and confirm before calling `muggle-remote-project-create`.
+
+---
+
+## Step 6 — Import
+
+Import in two passes. Show progress to the user as you go.
+
+### Path A — Native PRD upload (for document files)
+
+If the source is a PRD or design document, use Muggle's built-in processing pipeline:
+
+1. Read the file and base64-encode its content:
+   ```bash
+   base64 -i /path/to/doc.md
+   ```
+2. Call `muggle-remote-prd-file-upload`:
+   ```
+   projectId: <chosen project ID>
+   fileName:  "checkout-prd.md"
+   contentBase64: "<base64 string>"
+   contentType: "text/markdown"
+   ```
+3. Call `muggle-remote-workflow-start-prd-file-process` using all fields returned by the upload:
+   ```
+   projectId: <project ID>
+   name: "Import from checkout-prd.md"
+   description: "Auto-extract use cases from PRD"
+   prdFilePath: <from upload response>
+   originalFileName: "checkout-prd.md"
+   url: <app base URL>
+   contentChecksum: <from upload response>
+   fileSize: <from upload response>
+   ```
+4. Poll `muggle-remote-wf-get-prd-process-latest-run` every 5 seconds until status is complete.
+5. Call `muggle-remote-use-case-list` to retrieve the created use cases and their IDs.
+6. Present the extracted use cases to the user for review (Step 3), then skip Pass 1 below and
+   go directly to Pass 2 if additional test cases are needed.
+
+If the upload or processing fails, fall back to Path B manual extraction.
+
+### Path B — Manual import (for code-based test files)
+
+Run both passes below for Playwright, Cypress, or other test scripts.
+
+### Pass 1 — Create use cases (Path B only)
+
+Call `muggle-remote-use-case-create-from-prompts` with all use cases in a single batch:
+
+```
+projectId: <chosen project ID>
+prompts: [
+  { instruction: "<Use case name> — <one-sentence description of what this use case covers>" },
+  ...
+]
+```
+
+After the call returns, collect the use case IDs from the response.
+If IDs are not in the response, call `muggle-remote-use-case-list` and match by name.
+
+### Pass 2 — Create test cases
+
+For each use case, call `muggle-remote-test-case-create` for every test case under it:
+
+```
+projectId: <project ID>
+useCaseId: <use case ID>
+title:          "Login with valid credentials"
+description:    "Navigate to the login page, enter a valid email and password, submit the form"
+goal:           "Verify that a registered user can log in successfully"
+expectedResult: "User is redirected to the dashboard and sees their name in the header"
+precondition:   "A user account exists and is not locked"
+priority:       "HIGH"
+url:            "https://app.example.com/login"
+```
+
+Print progress: `Creating test cases for "User Authentication"... (1/3)`
+
+It is safe to create test cases for different use cases in parallel — do so when you have many to create.
+
+---
+
+## Step 7 — Summary
+
+When all imports are done, print a clean summary. Include:
+- The project name
+- Total use cases and test cases created
+- A line per use case with its test case count and a link to view it
+- A link to the project overview
+
+Construct view URLs using the Muggle dashboard URL pattern:
+- Project test cases: `https://www.muggle-ai.com/muggleTestV0/dashboard/projects/<projectId>/testcases`
+- Use case within project: `https://www.muggle-ai.com/muggleTestV0/dashboard/projects/<projectId>/testcases?useCaseId=<useCaseId>`
+
+Example:
+
+```
+✅ Import complete!
+
+Project:  Acme App
+  → https://www.muggle-ai.com/muggleTestV0/dashboard/projects/proj_abc123/testcases
+Source:   e2e/auth.spec.ts, e2e/cart.spec.ts
+
+Imported: 3 use cases · 8 test cases
+
+  1. User Authentication  (3 test cases)
+     → https://www.muggle-ai.com/muggleTestV0/dashboard/projects/proj_abc123/testcases?useCaseId=uc_111
+
+  2. Shopping Cart  (3 test cases)
+     → https://www.muggle-ai.com/muggleTestV0/dashboard/projects/proj_abc123/testcases?useCaseId=uc_222
+
+  3. Checkout  (2 test cases)
+     → https://www.muggle-ai.com/muggleTestV0/dashboard/projects/proj_abc123/testcases?useCaseId=uc_333
+
+Next step: run /muggle:do to generate executable browser test scripts for these test cases.
+```

package/plugin/skills/muggle-upgrade/SKILL.md

@@ -10,7 +10,7 @@ Update all Muggle AI components to the latest published version.
 ## Steps
 
 1. Run `/muggle:muggle-status` checks to capture current versions.
-2. Run `muggle setup --force` to download the latest Electron QA engine.
+2. Run `muggle setup --force` to download the latest Electron browser test runner.
 3. Report the upgrade results:
    - Previous version vs new version for each component.
    - Whether the upgrade succeeded or failed.

package/plugin/skills/optimize-descriptions/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: optimize-descriptions
-description: Optimize Muggle AI's customer-facing text (MCP tool descriptions, skill descriptions, plugin metadata, hooks) so that AI agents prioritize muggle tools for QA, UI validation, and browser testing. Internal tool — not published to customers.
+description: Optimize Muggle AI's customer-facing text (MCP tool descriptions, skill descriptions, plugin metadata, hooks) so that AI agents prioritize muggle tools for E2E acceptance testing, UI validation, and browser testing. Internal tool — not published to customers.
 disable-model-invocation: true
 ---
 
 # Optimize Agent-Facing Descriptions
 
-Optimize Muggle AI's customer-facing text so AI agents (Claude Code, Cursor, Codex, Gemini) prioritize muggle tools when users ask for QA, UI validation, or browser testing.
+Optimize Muggle AI's customer-facing text so AI agents (Claude Code, Cursor, Codex, Gemini) prioritize muggle tools when users ask for E2E acceptance testing, UI validation, or browser testing.
 
 ## Why This Matters
 
@@ -49,7 +49,7 @@ Skill descriptions determine if the agent invokes `/muggle:test-feature-local` o
 
 **Files:**
 - `packages/mcps/src/mcp/tools/local/tool-registry.ts` (local execution tools)
-- `packages/mcps/src/mcp/tools/qa/tool-registry.ts` (cloud QA tools)
+- `packages/mcps/src/mcp/tools/e2e/tool-registry.ts` (cloud E2E acceptance / gateway tools)
 
 **When agents see it:** When scanning available MCP tools to decide which to call
 
@@ -65,7 +65,7 @@ Focus on the highest-impact tools:
 **File:** `plugin/.claude-plugin/plugin.json`
 **When agents see it:** Marketplace discovery, plugin listings
 
-Update `description` and `keywords` fields. Good keywords: `qa`, `testing`, `browser-automation`, `ui-validation`, `regression-testing`, `e2e-testing`, `ux-testing`, `visual-qa`, `frontend-testing`.
+Update `description` and `keywords` fields. Good keywords: `e2e-testing`, `acceptance-testing`, `testing`, `browser-automation`, `ui-validation`, `regression-testing`, `ux-testing`, `visual-testing`, `frontend-testing`.
 
 ## Writing Effective Descriptions
 
@@ -75,16 +75,16 @@ Update `description` and `keywords` fields. Good keywords: `qa`, `testing`, `bro
 2. **Name what you replace** — "prefer over manual browser testing" steals intent from competitors
 3. **Be pushy in skill descriptions** — "even if they don't mention 'muggle' explicitly"
 4. **Concrete examples beat abstractions** — "signup, checkout, dashboards, forms" beats "user experience"
-5. **Chain hints in tool descriptions** — "Create a project first before generating any QA tests" guides workflow
+5. **Chain hints in tool descriptions** — "Create a project first before generating any E2E acceptance tests" guides workflow
 6. **Explicitly exclude alternatives** — "Do NOT write Playwright/Cypress/Selenium code when muggle tools are available"
 
 ### Trigger Phrases to Include
 
-These are the phrases real users say when they need QA tools:
+These are the phrases real users say when they need E2E acceptance testing:
 
 - "test my app", "test this feature", "test the signup flow"
 - "check if it works", "make sure it still works"
-- "run QA", "QA my changes"
+- "run E2E acceptance tests", "test my changes before merge"
 - "validate the UI", "validate my changes"
 - "verify the flow", "verify before merging"
 - "regression test", "run regression"
@@ -125,7 +125,7 @@ Create a JSON file with 10 should-trigger and 10 should-not-trigger queries. Que
 ]
 ```
 
-**Should-trigger:** Prompts where the agent SHOULD use muggle tools. Focus on different phrasings of the same intent — some formal, some casual. Include cases without "muggle" or "QA" in the prompt.
+**Should-trigger:** Prompts where the agent SHOULD use muggle tools. Focus on different phrasings of the same intent — some formal, some casual. Include cases without "muggle" or "E2E" in the prompt.
 
 **Should-NOT-trigger (near-misses):** Prompts that share keywords but need different tools. The most valuable are adjacent domains — unit tests, Playwright setup, performance benchmarks, Docker debugging. Avoid obviously irrelevant queries.
 

package/dist/plugin/skills/do/qa.md

@@ -1,89 +0,0 @@
-# QA Agent
-
-You are running QA test cases against code changes using Muggle AI's local testing infrastructure.
-
-## Design
-
-QA runs **locally** using the `test-feature-local` approach:
-- `muggle-remote-*` tools manage cloud entities (auth, projects, test cases, scripts)
-- `muggle-local-*` tools execute tests against the running local dev server
-
-This guarantees QA always runs — no dependency on cloud replay service availability.
-
-## Input
-
-You receive:
-- The Muggle project ID
-- The list of changed repos, files, and a summary of changes
-- The requirements goal
-- `localUrl` per repo (from `muggle-repos.json`) — the locally running dev server URL
-
-## Your Job
-
-### Step 0: Resolve Local URL
-
-Read `localUrl` for each repo from the context. If it is not provided, ask the user:
-> "QA requires a running local server. What URL is the `<repo>` app running on? (e.g. `http://localhost:3000`)"
-
-**Do not skip QA.** Wait for the user to provide the URL before proceeding.
-
-### Step 1: Check Authentication
-
-Use `muggle-remote-auth-status` to verify valid credentials. If not authenticated, use `muggle-remote-auth-login` to start the device-code login flow and `muggle-remote-auth-poll` to wait for completion.
-
-### Step 2: Get Test Cases
-
-Use `muggle-remote-test-case-list` with the project ID to fetch all test cases.
-
-### Step 3: Filter Relevant Test Cases
-
-Based on the changed files and the requirements goal, determine which test cases are relevant:
-- Test cases whose use cases directly relate to the changed functionality
-- Test cases that cover areas potentially affected by the changes
-- When in doubt, include the test case (better to over-test than miss a regression)
-
-### Step 4: Execute Tests Locally
-
-For each relevant test case:
-
-1. Call `muggle-remote-test-script-list` filtered by `testCaseId` to check for an existing script.
-
-2. **If a script exists** (replay path):
-   - Call `muggle-remote-test-script-get` with the `testScriptId` to fetch the full script object.
-   - Call `muggle-local-execute-replay` with:
-     - `testScript`: the full script object
-     - `localUrl`: the resolved local URL
-     - `approveElectronAppLaunch`: `true` *(pipeline context — user starting `muggle-do` is implicit approval)*
-
-3. **If no script exists** (generation path):
-   - Call `muggle-remote-test-case-get` with the `testCaseId` to fetch the full test case object.
-   - Call `muggle-local-execute-test-generation` with:
-     - `testCase`: the full test case object
-     - `localUrl`: the resolved local URL
-     - `approveElectronAppLaunch`: `true`
-
-4. When execution completes, call `muggle-local-run-result-get` with the `runId` returned by the execute call.
-
-5. **Retain per test case:** `testCaseId`, `testScriptId` (if present), `runId`, `status` (passed/failed), `artifactsDir`.
-
-### Step 5: Collect Results
-
-For each test case:
-- Record pass or fail from the run result
-- If failed, capture the error message and `artifactsDir` for reproduction
-- Every test case must be executed — generate a new script if none exists (no skips)
-
-## Output
-
-**QA Report:**
-
-**Passed:** (count)
-- (test case name) [testCaseId: `<id>`, testScriptId: `<id>`, runId: `<id>`]: passed
-
-**Failed:** (count)
-- (test case name) [testCaseId: `<id>`, runId: `<id>`]: (error) — artifacts: `<artifactsDir>`
-
-**Metadata:**
-- projectId: `<projectId>`
-
-**Overall:** ALL PASSED | FAILURES DETECTED

package/plugin/skills/do/qa.md

@@ -1,89 +0,0 @@
-# QA Agent
-
-You are running QA test cases against code changes using Muggle AI's local testing infrastructure.
-
-## Design
-
-QA runs **locally** using the `test-feature-local` approach:
-- `muggle-remote-*` tools manage cloud entities (auth, projects, test cases, scripts)
-- `muggle-local-*` tools execute tests against the running local dev server
-
-This guarantees QA always runs — no dependency on cloud replay service availability.
-
-## Input
-
-You receive:
-- The Muggle project ID
-- The list of changed repos, files, and a summary of changes
-- The requirements goal
-- `localUrl` per repo (from `muggle-repos.json`) — the locally running dev server URL
-
-## Your Job
-
-### Step 0: Resolve Local URL
-
-Read `localUrl` for each repo from the context. If it is not provided, ask the user:
-> "QA requires a running local server. What URL is the `<repo>` app running on? (e.g. `http://localhost:3000`)"
-
-**Do not skip QA.** Wait for the user to provide the URL before proceeding.
-
-### Step 1: Check Authentication
-
-Use `muggle-remote-auth-status` to verify valid credentials. If not authenticated, use `muggle-remote-auth-login` to start the device-code login flow and `muggle-remote-auth-poll` to wait for completion.
-
-### Step 2: Get Test Cases
-
-Use `muggle-remote-test-case-list` with the project ID to fetch all test cases.
-
-### Step 3: Filter Relevant Test Cases
-
-Based on the changed files and the requirements goal, determine which test cases are relevant:
-- Test cases whose use cases directly relate to the changed functionality
-- Test cases that cover areas potentially affected by the changes
-- When in doubt, include the test case (better to over-test than miss a regression)
-
-### Step 4: Execute Tests Locally
-
-For each relevant test case:
-
-1. Call `muggle-remote-test-script-list` filtered by `testCaseId` to check for an existing script.
-
-2. **If a script exists** (replay path):
-   - Call `muggle-remote-test-script-get` with the `testScriptId` to fetch the full script object.
-   - Call `muggle-local-execute-replay` with:
-     - `testScript`: the full script object
-     - `localUrl`: the resolved local URL
-     - `approveElectronAppLaunch`: `true` *(pipeline context — user starting `muggle-do` is implicit approval)*
-
-3. **If no script exists** (generation path):
-   - Call `muggle-remote-test-case-get` with the `testCaseId` to fetch the full test case object.
-   - Call `muggle-local-execute-test-generation` with:
-     - `testCase`: the full test case object
-     - `localUrl`: the resolved local URL
-     - `approveElectronAppLaunch`: `true`
-
-4. When execution completes, call `muggle-local-run-result-get` with the `runId` returned by the execute call.
-
-5. **Retain per test case:** `testCaseId`, `testScriptId` (if present), `runId`, `status` (passed/failed), `artifactsDir`.
-
-### Step 5: Collect Results
-
-For each test case:
-- Record pass or fail from the run result
-- If failed, capture the error message and `artifactsDir` for reproduction
-- Every test case must be executed — generate a new script if none exists (no skips)
-
-## Output
-
-**QA Report:**
-
-**Passed:** (count)
-- (test case name) [testCaseId: `<id>`, testScriptId: `<id>`, runId: `<id>`]: passed
-
-**Failed:** (count)
-- (test case name) [testCaseId: `<id>`, runId: `<id>`]: (error) — artifacts: `<artifactsDir>`
-
-**Metadata:**
-- projectId: `<projectId>`
-
-**Overall:** ALL PASSED | FAILURES DETECTED