From muggle
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.
How this skill is triggered — by the user, by Claude, or both
Slash command
/muggle:muggle-test-importThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill migrates existing test artifacts into Muggle Test. It reads your source files,
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.
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.
The extraction strategy depends on the file type. Choose the right path before reading.
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:
muggle-remote-prd-file-upload with the encoded content and filenamemuggle-remote-workflow-start-prd-file-process using the fields returned by the upload
(prdFilePath, contentChecksum, fileSize) plus the project URLmuggle-remote-wf-get-prd-process-latest-run until the status is completemuggle-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 neededNote: 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).
Read each file and extract a use case → test case hierarchy manually.
describe() / test.describe() block → use case nameit() / test() block → test casepage.goto('...') calls for the URLgoal and expectedResult from assertion text and commentsdescribe() groupinggoal or expectedResult blank — infer them from contextHIGH for critical paths and error handling, MEDIUM for secondary flows, LOW for edge casesBuild an internal model before presenting anything to the user (Path B only):
Use Case: <Name>
- TC1: <title> | goal | expectedResult | precondition | priority | url
- TC2: ...
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:
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.
Call muggle-remote-auth-status first.
If already authenticated → skip to Step 5.
If not authenticated:
muggle-remote-auth-login (opens browser automatically).muggle-remote-auth-poll to wait for completion.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:
Show the proposal and confirm before calling muggle-remote-project-create.
Import in two passes. Show progress to the user as you go.
If the source is a PRD or design document, use Muggle's built-in processing pipeline:
base64 -i /path/to/doc.md
muggle-remote-prd-file-upload:
projectId: <chosen project ID>
fileName: "checkout-prd.md"
contentBase64: "<base64 string>"
contentType: "text/markdown"
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>
muggle-remote-wf-get-prd-process-latest-run every 5 seconds until status is complete.muggle-remote-use-case-list to retrieve the created use cases and their IDs.If the upload or processing fails, fall back to Path B manual extraction.
Run both passes below for Playwright, Cypress, or other test scripts.
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.
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.
When all imports are done, print a clean summary. Include:
Construct view URLs using the Muggle dashboard URL pattern:
https://www.muggle-ai.com/muggleTestV0/dashboard/projects/<projectId>/testcaseshttps://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.
npx claudepluginhub multiplex-ai/muggle-ai-works --plugin muggleaiGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.