@muggleai/works 4.10.0 → 4.10.1

package/plugin/skills/mimport/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: mimport
+description: Explicit short alias for the `muggle-test-import` skill. ONLY invoke when the user explicitly types `mimport` or `/mimport` — never auto-trigger from any other phrasing.
+---
+
+# mimport — alias for muggle-test-import
+
+Invoke the `muggle-test-import` skill via the Skill tool. Forward any user-provided arguments unchanged.

package/plugin/skills/mpr/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: mpr
+description: Explicit short alias for the `muggle-pr-visual-walkthrough` skill. ONLY invoke when the user explicitly types `mpr` or `/mpr` — never auto-trigger from any other phrasing.
+---
+
+# mpr — alias for muggle-pr-visual-walkthrough
+
+Invoke the `muggle-pr-visual-walkthrough` skill via the Skill tool. Forward any user-provided arguments unchanged.

package/plugin/skills/mprefs/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: mprefs
+description: Explicit short alias for the `muggle-preferences` skill. ONLY invoke when the user explicitly types `mprefs` or `/mprefs` — never auto-trigger from any other phrasing.
+---
+
+# mprefs — alias for muggle-preferences
+
+Invoke the `muggle-preferences` skill via the Skill tool. Forward any user-provided arguments unchanged.

package/plugin/skills/mregen/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: mregen
+description: Explicit short alias for the `muggle-test-regenerate-missing` skill. ONLY invoke when the user explicitly types `mregen` or `/mregen` — never auto-trigger from any other phrasing.
+---
+
+# mregen — alias for muggle-test-regenerate-missing
+
+Invoke the `muggle-test-regenerate-missing` skill via the Skill tool. Forward any user-provided arguments unchanged.

package/plugin/skills/mrelease/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: mrelease
+description: Explicit short alias for the `muggle-works-npm-release` skill. ONLY invoke when the user explicitly types `mrelease` or `/mrelease` — never auto-trigger from any other phrasing.
+---
+
+# mrelease — alias for muggle-works-npm-release
+
+Invoke the `muggle-works-npm-release` skill via the Skill tool. Forward any user-provided arguments unchanged.

package/plugin/skills/mrepair/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: mrepair
+description: Explicit short alias for the `muggle-repair` skill. ONLY invoke when the user explicitly types `mrepair` or `/mrepair` — never auto-trigger from any other phrasing.
+---
+
+# mrepair — alias for muggle-repair
+
+Invoke the `muggle-repair` skill via the Skill tool. Forward any user-provided arguments unchanged.

package/plugin/skills/mstatus/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: mstatus
+description: Explicit short alias for the `muggle-status` skill. ONLY invoke when the user explicitly types `mstatus` or `/mstatus` — never auto-trigger from any other phrasing.
+---
+
+# mstatus — alias for muggle-status
+
+Invoke the `muggle-status` skill via the Skill tool. Forward any user-provided arguments unchanged.

package/plugin/skills/mtest/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: mtest
+description: Explicit short alias for the `muggle-test` skill. ONLY invoke when the user explicitly types `mtest` or `/mtest` — never auto-trigger from any other phrasing.
+---
+
+# mtest — alias for muggle-test
+
+Invoke the `muggle-test` skill via the Skill tool. Forward any user-provided arguments unchanged.

package/plugin/skills/mtestlocal/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: mtestlocal
+description: Explicit short alias for the `muggle-test-feature-local` skill. ONLY invoke when the user explicitly types `mtestlocal` or `/mtestlocal` — never auto-trigger from any other phrasing.
+---
+
+# mtestlocal — alias for muggle-test-feature-local
+
+Invoke the `muggle-test-feature-local` skill via the Skill tool. Forward any user-provided arguments unchanged.

package/plugin/skills/mtestprep/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: mtestprep
+description: Explicit short alias for the `muggle-test-prepare` skill. ONLY invoke when the user explicitly types `mtestprep` or `/mtestprep` — never auto-trigger from any other phrasing.
+---
+
+# mtestprep — alias for muggle-test-prepare
+
+Invoke the `muggle-test-prepare` skill via the Skill tool. Forward any user-provided arguments unchanged.

package/plugin/skills/muggle/SKILL.md

@@ -1,15 +1,17 @@
 ---
 name: muggle
-description: Muggle AI command router and menu. Use when user types "muggle" or asks for available Muggle commands.
+description: Muggle AI command router and menu. Use when user types "muggle" or asks for available Muggle Test commands.
 ---
 
-# Muggle
+# Muggle Test
 
-Use this as the top-level Muggle command router.
+> Telemetry first step: see [`_shared/telemetry-emit.md`](../_shared/telemetry-emit.md). Use `skillName: "muggle"`.
+
+Use this as the top-level Muggle Test command router.
 
 ## Preferences
 
-User preferences are injected by the SessionStart hook into a `Muggle Preferences` line in session context (key=value pairs). Resolution: defaults → `~/.muggle-ai/preferences.json` (global) → `<repo>/.muggle-ai/preferences.json` (project). Treat absent prefs as `ask`.
+User preferences are injected by the SessionStart hook into a `Muggle Test Preferences` line in session context (key=value pairs). Resolution: defaults → `~/.muggle-ai/preferences.json` (global) → `<repo>/.muggle-ai/preferences.json` (project). Treat absent prefs as `ask`.
 
 This router skill itself does not gate any decision on a preference — it just routes user intent to a downstream skill. Each downstream skill consults its own preferences. For example, `checkForUpdates` is consulted by `muggle-status` (Check 4), not here.
 
@@ -17,7 +19,7 @@ If the user types "muggle" with no subcommand and you want to surface a contextu
 
 ## Menu
 
-When user asks for "muggle" with no specific subcommand, use `AskQuestion` to present these four options:
+When user asks for "muggle" with no specific subcommand, use `AskUserQuestion` to present these four options:
 
 - "Test a feature — run E2E acceptance tests locally or remotely" → `muggle-test-feature-local` (local) or `muggle-test` (remote/change-driven)
 - "Build something — implement a feature with E2E acceptance tests and a visual PR" → `muggle-do`
@@ -35,5 +37,6 @@ If the user intent clearly matches one command, route directly — no menu neede
 - test localhost/validate single feature/test a feature → `muggle-test-feature-local`
 - build/implement from request/end-to-end → `muggle-do`
 - post results to PR/attach walkthrough/visual evidence on PR → `muggle-pr-visual-walkthrough`
+- give feedback on a run/the test was wrong/step N didn't work/show my feedback/delete feedback → `muggle-feedback`
 
-If intent is ambiguous, use `AskQuestion` with the most likely options rather than asking the user to type a clarification.
+If intent is ambiguous, use `AskUserQuestion` with the most likely options rather than asking the user to type a clarification.

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

@@ -4,9 +4,11 @@ description: Unified Muggle AI workflow entry point. Use when user types muggle
 disable-model-invocation: true
 ---
 
-# Muggle Do
+# Muggle Test Do
 
-Muggle Do runs a battle-tested autonomous dev cycle: **pre-flight → requirements → impact analysis → validate code → unit tests → E2E acceptance → open PR**.
+> Telemetry first step: see [`_shared/telemetry-emit.md`](../_shared/telemetry-emit.md). Use `skillName: "muggle-do"`.
+
+Muggle Test Do runs a battle-tested autonomous dev cycle: **pre-flight → requirements → impact analysis → validate code → unit tests → E2E acceptance → open PR**.
 
 The design goal is **fire and review**: the user answers one consolidated pre-flight questionnaire, then walks away. Every subsequent stage runs unattended until completion or a genuine blocker.
 
@@ -16,12 +18,28 @@ For maintenance tasks, use the dedicated skills:
 - `/muggle:muggle-repair`
 - `/muggle:muggle-upgrade`
 
+## Preferences
+
+Gates run per [`preference-gates/README.md`](../muggle-preferences/preference-gates/README.md).
+
+| Preference | Stage | Decision it gates |
+|------------|-------|-------------------|
+| `autoUseWorktree` | 1 (pre-flight) | Create a worktree (see [`_shared/use-worktrees.md`](../_shared/use-worktrees.md)) |
+| `autoE2ETest` | 6 (e2e-acceptance) | Run E2E every cycle (default `always`), or fold the question into pre-flight |
+| `autoRebase` | 6 (e2e-acceptance) | Rebase onto `origin/<default>` (see [`_shared/rebase-before-e2e.md`](../_shared/rebase-before-e2e.md)) |
+| `autoCreatePR` | 7 (open-prs) | Push the branch and open the PR (see [`do/open-prs.md`](../do/open-prs.md)) |
+| `autoCleanup` | 7 (post-merge) | Run cleanup sequence (see [`_shared/post-merge-cleanup.md`](../_shared/post-merge-cleanup.md)) |
+
 ## Input routing
 
 Treat `$ARGUMENTS` as the user command:
 
 - Empty / `help` / `menu` / `?` → show menu and session selector.
-- Anything else → treat as a new task description and start/resume a dev-cycle session.
+- Anything else → infer intent:
+  - **Task automation** (user wants to perform an action on a website — post something, fill a form, click through a flow) → invoke `muggle:muggle-do-task` skill with the full prompt as arguments.
+  - **Feature development** (user wants to build, implement, fix, or refactor code) → treat as a new task description and start/resume a dev-cycle session.
+
+  When in doubt, ask one question: "Do you want me to run this as a browser automation task, or implement it as a code change?"
 
 ## The seven stages
 
@@ -39,7 +57,7 @@ Treat `$ARGUMENTS` as the user command:
 
 ## Front-loading (stage 1 non-negotiable)
 
-All ambiguity — task scope, repo selection, validation strategy, localhost URL, backend health, Muggle project, test-user credentials, branch name, PR target — is resolved in a **single** pre-flight turn. See `pre-flight.md` for the exact questionnaire.
+All ambiguity — task scope, repo selection, validation strategy, localhost URL, backend health, Muggle Test project, test-user credentials, branch name, PR target — is resolved in a **single** pre-flight turn. See `pre-flight.md` for the exact questionnaire.
 
 **Red-flag behaviors (do not do):**
 

package/plugin/skills/muggle-do-pr-followup/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: muggle-do-pr-followup
+description: One polling tick of /muggle-do stage 8 — addresses reviewer comments and CI failures on PRs opened by an earlier /muggle-do session. Dispatched by `/loop 5m /muggle:muggle-do-pr-followup <slug>` after stage 7; also re-runnable by hand on any session slug.
+disable-model-invocation: true
+---
+
+# Muggle Test Do — PR follow-up
+
+> Telemetry first step: see [`_shared/telemetry-emit.md`](../_shared/telemetry-emit.md). Use `skillName: "muggle-do-pr-followup"`.
+
+This skill is the **dispatch entry** for stage 8 of /muggle-do. It is intentionally thin — the actual per-tick logic lives in [`../do/pr-followup.md`](../do/pr-followup.md), the single source of truth.
+
+## Input routing
+
+`$ARGUMENTS` is the **session slug** (the directory name under `.muggle-do/sessions/`).
+
+- Empty / `help` / `?` → list available session slugs from `.muggle-do/sessions/` that have a non-empty `prs.json` with at least one non-terminal entry, then exit. Do not start a poll.
+- Otherwise → resolve `.muggle-do/sessions/<slug>/`. If the directory or its `prs.json` is missing, log the error to `followup.log` (creating it if needed) and exit. Do **not** ask the user.
+
+## Run one tick
+
+With a valid session slug, follow [`../do/pr-followup.md`](../do/pr-followup.md) exactly. That file owns:
+
+- The turn preamble.
+- The 9-step per-tick contract.
+- The classify rule (directive / question / CI failure / ambiguous → escalate).
+- Reply routing.
+- Telemetry shape.
+- The self-check before exit.
+
+This skill file adds nothing beyond the slug resolution above.
+
+## Why a separate entry exists
+
+- `/loop 5m /muggle:muggle-do-pr-followup <slug>` (dispatched by stage 7 of /muggle-do) needs a slash-addressable target.
+- Manual re-attach: if `/loop` was killed and the user wants to resume, they can run `/muggle:muggle-do-pr-followup <slug>` once to drive a single tick, or re-dispatch the `/loop` themselves.
+- Isolated debugging: a single tick is reproducible against a real session dir.

package/plugin/skills/muggle-do-task/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: muggle-do-task
+description: Run a browser automation task on a website using natural language. Finds or creates the Muggle Test project, use case, test case, and script, then executes locally via the electron app. Use when the user wants to perform an action on a website (post, fill a form, click through a flow) rather than implement a code change.
+---
+
+# Muggle Test Task Runner
+
+> Telemetry first step: see [`_shared/telemetry-emit.md`](../_shared/telemetry-emit.md). Use `skillName: "muggle-do-task"`.
+
+Runs a browser automation task described in plain English. Finds or creates the necessary Muggle Test entities automatically, then executes locally with mutation-driven step prediction.
+
+## Step 1 — Parse the prompt
+
+From `$ARGUMENTS`, extract:
+
+- **`domain`** — the target website domain (e.g., `x.com`, `amazon.com`, `localhost:3000`). Normalize: strip `www.`, strip `https://`, lowercase. Result: bare domain with no scheme, no trailing slash.
+- **`useCaseName`** — the core action being performed, stripped of variable content (e.g., `"Publish a post"`, `"Add to cart"`, `"Submit a form"`).
+- **`mutations`** — variable parameters as a `string[]` (JSON array of strings). Each string is either:
+  - A plain-English instruction describing what varies this run (e.g., `"The post content should be 'Hello world'"`)
+  - A local file path for uploads (e.g., `"Attach the image at C:\\Users\\stan4\\Pictures\\photo.jpg"`)
+  
+  Examples: `["The post content should be 'Hello world'"]`, `["Attach the image at C:\\Users\\stan4\\photo.jpg", "Caption should be 'My photo'"]`
+- **`localUrl`** — the full URL to test against (e.g., `https://x.com`, `http://localhost:3000`). For external sites, use `https://<domain>`. For local dev servers, use the port the user's app is running on.
+
+If the prompt is ambiguous and you cannot confidently extract these, ask one clarifying question before proceeding.
+
+## Step 2 — Find or create Project
+
+Load and call `muggle-remote-project-list`. Find a project whose URL contains `domain` (case-insensitive substring match).
+
+**If found:** use it. Tell the user: `Found project: <name>`.
+
+**If not found:** call `muggle-remote-project-create` with:
+- `projectName`: `<domain>`
+- `description`: `E2E acceptance testing project for <domain>`
+- `url`: `https://<domain>`
+
+Tell the user: `Created project: <name>`.
+
+## Step 3 — Find or create Use Case
+
+Load and call `muggle-remote-use-case-list` filtered by `projectId`. Fuzzy-match against `useCaseName`:
+- Case-insensitive
+- Strip punctuation
+- Match if either string is a substring of the other
+
+If multiple candidates, pick the closest and tell the user which was selected.
+
+**If not found:** call `muggle-remote-use-case-create-from-prompts` with:
+- `projectId`: from Step 2
+- `instructions`: `["<original prompt>"]`
+
+Use the first result. Capture its `id` as `useCaseId`. If the result is empty or the call fails, stop and tell the user: "Could not create use case — try rephrasing the task description."
+
+Tell the user: `Created use case: <title>`.
+
+## Step 4 — Find or create Test Case
+
+Load and call `muggle-remote-test-case-list-by-use-case` with `useCaseId`. Filter for test cases where `status` equals `ACTIVE`.
+
+**If not found:** call `muggle-remote-test-case-create` with:
+- `projectId`: from Step 2
+- `useCaseId`: from Step 3
+- `title`: `<useCaseName>`
+- `description`: `Test case for: <original prompt>`
+- `goal`: `Successfully complete: <useCaseName>`
+- `expectedResult`: `The action completes without error`
+- `url`: `https://<domain>`
+
+Tell the user: `Created test case: <id>`.
+
+## Step 5 — Find active Test Script
+
+Load and call `muggle-remote-test-script-list` with:
+- `projectId`: from Step 2
+- `testCaseId`: from Step 4
+
+Tell the user which mutations will be applied: `Mutations: <mutations[]>` (or "no mutations" if empty).
+
+Filter for scripts where `status` equals `ACTIVE` or `PUBLISHED`. If all returned scripts have another status (`DRAFT`, `GENERATION_PENDING`, `FAILED`), treat as "no active script" and proceed to Phase 1.
+
+---
+
+### Phase 1 — No active script: generate locally
+
+1. Load and call `muggle-remote-test-case-get` with the test case ID from Step 4. This returns the full test case object needed by the local execution tool.
+
+2. Load and call `muggle-local-execute-test-generation` with:
+   - `testCase`: the full object from step 1 above
+   - `localUrl`: from Step 1
+   - `mutations`: the `mutations[]` array from Step 1 (omit if empty)
+
+3. Tell the user:
+> Script generation is running in the Muggle Test window. Once complete, run `/muggle-do "<original prompt>"` again to execute the task.
+
+Do not proceed further.
+
+---
+
+### Phase 2 — Active script found: replay with mutations
+
+## Step 6 — Fetch Action Script
+
+1. Load and call `muggle-remote-test-script-get` with the script ID from Step 5. Extract `actionScriptId`. If `actionScriptId` is missing or null, stop and tell the user: "The script record is incomplete — it may still be generating. Try again in a moment."
+
+2. Load and call `muggle-remote-action-script-get` with `actionScriptId`.
+
+Tell the user: `Executing task...`
+
+## Step 7 — Execute locally
+
+Load and call `muggle-local-execute-replay` with:
+- `testScript`: the full object from Step 6 (from `muggle-remote-test-script-get`)
+- `actionScript`: the content from Step 6 (from `muggle-remote-action-script-get`)
+- `localUrl`: from Step 1
+- `mutations`: the `mutations[]` array from Step 1 (omit if empty)
+
+Tell the user:
+> Running **[useCaseName]** on [domain]. Watch the Muggle Test window — it will execute the task with your parameters applied.
+
+## Step 8 — Route failures through the failure-mode handler
+
+If Phase 1 generation or Phase 2 replay returns `failed` or any non-passing terminal state, follow [`_shared/failure-mode-handling.md`](../_shared/failure-mode-handling.md):
+
+- **Phase 1 (generation) failure** → section C (buckets: `transient` / `infra` / `agent-course` / `product-uxux`).
+- **Phase 2 (replay) failure** → section B (buckets: `infra` / `stale-script` / `product-defect`).
+
+Steps:
+1. Read the run via `muggle-local-run-result-get` and extract signals per the heuristics in the shared doc.
+2. Emit `regen-failure-classified` or `replay-failure-classified` via `muggle-local-telemetry-event-emit` **before** asking the user.
+3. Present the recommended action via `AskUserQuestion` with the alternatives the shared doc lists for that bucket.
+4. After the user picks, emit the matching `*-resolved` event with `userAction`.
+
+If the user picks `muggle-feedback` from any bucket's options, invoke the `muggle-feedback` skill via the `Skill` tool with the `runId`. Skip silently on clean success.

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

@@ -0,0 +1,38 @@
+---
+name: muggle-feedback
+description: Capture feedback on a generated Muggle Test action script — either step-level or whole-script — and submit it so the system can analyze it and regenerate affected scripts. Use when the user has just run a Muggle Test (local or remote) and wants to flag what went wrong, when they paste a Muggle dashboard URL with a test script or run, or when they want to view or delete previously submitted feedback. Triggers on: '/muggle-feedback', 'give feedback on this run', 'the test was wrong', 'step N didn't work', 'the script clicked the wrong button', 'flag this run', 'the summary is wrong', 'show my feedback', 'list feedback', 'delete that feedback'. Skill auto-detects the run context from a recent local run, a remote run, or a Muggle dashboard URL in the prompt.
+---
+
+# Muggle Test Feedback
+
+> Telemetry first step: see [`_shared/telemetry-emit.md`](../_shared/telemetry-emit.md). Use `skillName: "muggle-feedback"`.
+
+Capture user feedback on what a generated Muggle Test action script did wrong. The server uses each feedback row to find similar test cases via LLM and regenerate their scripts in the background.
+
+## Routing
+
+Pick the operation, then read its op file for the procedure.
+
+| Intent | Op file |
+|---|---|
+| "give feedback on this run" / "the test was wrong" / "step N didn't work" / a Muggle dashboard URL in the prompt / chained from another skill | [`ops/submit.md`](ops/submit.md) |
+| "show my feedback" / "list feedback for this project" / "what feedback have I filed" | [`ops/list.md`](ops/list.md) |
+| "delete that feedback" / "remove feedback for X" | [`ops/delete.md`](ops/delete.md) |
+
+If intent is ambiguous, use `AskUserQuestion` once with options **Submit / List / Delete** — never ask the user to type a clarification in plain text.
+
+## Constraints (all ops)
+
+- **Feedback attaches to a cloud action-script id.** A local run that has not yet been uploaded to the cloud has no such id. Submit must upload the run first if needed.
+- **Feedback target is one of two shapes:**
+  - **Whole script** — `target.targetType = "actionScript"`, `target.targetId = <actionScriptId>`.
+  - **One specific step** — `target.targetType = "step"`, `target.targetId = "<actionScriptId>:<stepIndex>"` where `stepIndex` is **0-based** on the wire even though steps are shown to the user 1-based.
+- **Project scope.** All ops scope to the user's last-used project (`muggle-local-last-project-get`). If unset, ask once and persist via `muggle-local-last-project-set` so subsequent ops in this session reuse it.
+- **`feedbackText` must be non-empty.** Re-prompt the user if they leave it blank.
+
+## Non-negotiables (all ops)
+
+- Use `AskUserQuestion` for every selection (project, test case, run, target type, confirm). Never ask the user to "reply with a number" in plain text.
+- Convert step numbers between 1-based (rendered to user) and 0-based (wire format) at the boundary. Never expose 0-based indices to the user.
+- One MCP submit/delete call per feedback piece — never batch into a single call.
+- Surface the `feedbackAnalysisWorkflowRuntimeId` returned by submit so the user knows regeneration is running. Do not poll it from this skill.

package/plugin/skills/muggle-feedback/ops/delete.md

@@ -0,0 +1,49 @@
+# Delete feedback
+
+Soft-delete a feedback entry. Always confirm with the user before deleting — this is a write the user cannot undo from this skill.
+
+## 1. Identify the feedback
+
+Three paths:
+
+- **Explicit id** — user named the feedback id (e.g. "delete feedback `abcd-1234-...`"). Use it.
+- **Recently shown id** — the user is referring to a row from a list rendered earlier in the conversation. Resolve from that context.
+- **No id given** — run [`list.md`](list.md) first to surface entries; offer "Delete one" as the next-action; the user picks.
+
+## 2. Show what will be deleted
+
+Print:
+
+```
+Feedback: <id>
+Target:   <Whole script | Step N>
+Test case: <title>
+Created:  <human-readable>
+Text:
+  <full feedbackText, indented>
+```
+
+## 3. Confirm
+
+`AskUserQuestion`:
+
+> "Delete this feedback?"
+> - **Delete** — proceed
+> - **Cancel** — abort
+
+If the user cancels, print "Cancelled — feedback kept." and stop.
+
+## 4. Soft-delete
+
+`muggle-remote-user-feedback-delete` with the feedback id.
+
+## 5. Report
+
+On success: `✓ Deleted feedback <id>.`
+
+On failure: print the error verbatim. If the error is "not found", inform the user the entry was likely already deleted and continue gracefully.
+
+## Non-negotiables
+
+- Never delete without an explicit confirm step, even if the user said "delete X" in their original prompt — the confirm shows what they're actually deleting.
+- One delete call per invocation. No bulk delete in v1.

package/plugin/skills/muggle-feedback/ops/list.md

@@ -0,0 +1,65 @@
+# List feedback
+
+Show feedback the user has filed. The user usually wants feedback on a specific test case (or test script, or use case) — not the whole project — so the skill picks a scope first.
+
+## 1. Scope to a project
+
+Read `muggle-local-last-project-get`. If set, use it.
+
+If unset: `muggle-remote-project-list` and pick via `AskUserQuestion` (top 5 by recency, plus "Show full list"). Persist with `muggle-local-last-project-set`.
+
+## 2. Pick a narrowing scope
+
+Ask once via `AskUserQuestion` — the list tool accepts at most one narrowing filter:
+
+> "What feedback do you want to see?"
+> - **A specific test case** (most common)
+> - **A specific test script**
+> - **A specific use case**
+> - **All in this project**
+
+If the user came from a chained skill or from a recent run, default to the matching narrowing scope and skip this question.
+
+## 3. Resolve the filter id
+
+- **Test case** → `muggle-remote-test-case-list` with `projectId`, `AskUserQuestion`. Pass picked id as `testCaseId`.
+- **Test script** → first pick a test case (as above), then `muggle-remote-test-script-list` with `testCaseId`, `AskUserQuestion`. Pass as `testScriptId`.
+- **Use case** → `muggle-remote-use-case-list` with `projectId`, `AskUserQuestion`. Pass as `useCaseId`.
+- **All in project** → no narrowing param.
+
+Use relevance-first filtering on each picker: top 3-5 most relevant to the user's stated goal, plus "Show full list".
+
+## 4. Fetch
+
+`muggle-remote-user-feedback-list` with `projectId` and at most one of `actionScriptId` / `testScriptId` / `testCaseId` / `useCaseId`.
+
+If the response has zero entries, print "No feedback yet for `<scope description>`." and offer `AskUserQuestion` with **Submit new feedback / Done**.
+
+## 5. Render
+
+Markdown table sorted by `createdAt` (newest first):
+
+| # | Target | Test case | Excerpt | Created | Id |
+|---|---|---|---|---|---|
+
+- **Target** — "Whole script" or "Step N" (convert wire 0-based index to 1-based for display).
+- **Test case** — when the scope is `testCaseId` or `testScriptId`, all rows share the same test case (use the title from the picker). When the scope is `useCaseId` or project-wide, resolve per row by fetching `muggle-remote-test-script-list` once for each unique `actionScriptId` (cache in-memory) — or skip and show "Test case: …" if there are >20 unique scripts.
+- **Excerpt** — first 80 chars of `feedbackText`, single line.
+- **Created** — human-readable, e.g. `2 days ago`.
+- **Id** — feedback id, truncated to first 8 chars in the table; full id shown in the detail view.
+
+## 6. Offer next action
+
+`AskUserQuestion`:
+
+> "What next?"
+> - **View detail** — pick an entry, print full `feedbackText`, full ids, target, dashboard link if available.
+> - **Delete one** — hand off to [`delete.md`](delete.md).
+> - **Submit new feedback** — hand off to [`submit.md`](submit.md).
+> - **Done**
+
+## Non-negotiables
+
+- One narrowing filter only — never set more than one of `actionScriptId` / `testScriptId` / `testCaseId` / `useCaseId` in the same call.
+- Convert wire 0-based step indices to 1-based when rendering to the user.
+- Don't fetch test-case names per row eagerly past ~20 unique action scripts — make it opt-in.

package/plugin/skills/muggle-feedback/ops/submit.md

@@ -0,0 +1,117 @@
+# Submit feedback
+
+Resolve the action script being commented on, render it for review, collect feedback against one or more steps and/or the whole script, then submit each piece as its own server-side row.
+
+## 1. Resolve the action script (the "anchor")
+
+Pick the first applicable path. Stop at the first that yields an `actionScriptId`.
+
+### 1a. Dashboard URL in user's prompt
+
+A Muggle dashboard URL looks like `https://app.muggle-ai.com/muggleTestV0/dashboard/projects/<projectId>/...`. Scan the user's recent message for any `https://app.muggle-ai.com/...` URL.
+
+- Extract any UUID-shaped path segments. If `/projects/<uuid>` is present, capture as `projectId`. If `/test-scripts/<uuid>` is present, capture as `testScriptId`.
+- If a `testScriptId` was captured: call `muggle-remote-test-script-get` to get the script and read `actionScriptId` off it. Done — proceed to step 2.
+- If only a `projectId` was captured: use it as the project for path 1c and continue to picker.
+- If parsing yields nothing actionable: fall through to 1b.
+
+### 1b. Recent local run (chained or just-finished)
+
+If this skill was invoked by another skill (`muggle-test`, `muggle-test-feature-local`) the caller MUST pass the just-finished `runId` as context. If you have a `runId`:
+
+1. `muggle-local-run-result-get` with the `runId`.
+2. The result includes the test case context. If the run was already published (`muggle-local-publish-test-script` was called), the resulting `testScriptId` gives you the cloud `actionScriptId` via `muggle-remote-test-script-get`.
+3. **If the run was NOT published**, upload it first via `muggle-remote-local-run-upload` (passing the `runId`'s test case context and `actionScript` payload). Use the returned cloud `actionScriptId`.
+
+If no `runId` was passed but the user is plausibly continuing from a recent test:
+
+1. `muggle-local-list-sessions` and pick sessions completed in the last 10 minutes for the current project.
+2. If exactly one fresh session exists, offer it as the default via `AskUserQuestion` ("Feedback on the run from <X> minutes ago?" with **Yes / Pick a different run**).
+3. If multiple, present the top 3 via `AskUserQuestion` (most recent first).
+4. Once picked, follow the publish-or-upload path above.
+
+If neither chained nor recent fits, fall through to 1c.
+
+### 1c. Picker (project → test case → run)
+
+1. **Project.** Read `muggle-local-last-project-get`. If set, use it. Else `muggle-remote-project-list` with `AskUserQuestion` (top 5 by recency, plus "Show full list"). Persist the pick with `muggle-local-last-project-set`.
+2. **Test case.** `muggle-remote-test-case-list` with `projectId`, then `AskUserQuestion`. Top 5 by recency plus "Show full list". Rank by relevance if the user mentioned anything specific.
+3. **Run / script.** `muggle-remote-test-script-list` with `testCaseId`. Show via `AskUserQuestion` with: name + status + updatedAt. Top 5 by recency.
+4. `muggle-remote-test-script-get` on the picked one → note `actionScriptId`.
+
+## 2. Render the script for review
+
+Always render before asking for feedback — the user must see the steps to reference them by index.
+
+`muggle-remote-action-script-get` with the resolved `actionScriptId`.
+
+Print:
+
+- **Header** — project name, test case title, script name, status, run url (if available). For remote, include the dashboard link.
+- **Steps** — numbered list, **1-based**, in order:
+  - `Step <n>: <action label> on <element text or id> — <briefExplanation>`
+  - If `screenshotPath` is present (local) or `screenshotUrl` (remote), append `[screenshot: <path>]` so the user can open it manually.
+- **Summary** — print `summary` from the action script if present, else "No summary recorded".
+
+## 3. Collect feedback (batch)
+
+Use `AskUserQuestion` to scope which targets:
+
+> "Where is the problem?"
+> - One specific step
+> - Multiple steps
+> - The whole script's outcome / summary
+> - Multiple steps **and** the whole outcome
+
+For each chosen target, prompt for the feedback paragraph in plain text. Keep prompts specific:
+
+- For a step: "What should step `<n>` have done instead?"
+- For the whole script: "What's wrong with the overall outcome?"
+
+Validate each paragraph is non-empty (re-prompt if blank). Build an in-memory list of feedback pieces:
+
+```
+[
+  { kind: "step", stepNumber: 3, text: "..." },
+  { kind: "step", stepNumber: 7, text: "..." },
+  { kind: "actionScript",            text: "..." },
+]
+```
+
+Before submitting, re-confirm the full set with the user via `AskUserQuestion`:
+
+> "Submit these <N> feedback entries?" — **Submit / Edit / Cancel**.
+
+## 4. Submit
+
+For each piece, call `muggle-remote-user-feedback-create` once. Map fields:
+
+| Piece kind | `target.targetType` | `target.targetId` |
+|---|---|---|
+| Step `n` (1-based) | `"step"` | `` `${actionScriptId}:${n - 1}` `` (convert to 0-based) |
+| Whole script | `"actionScript"` | `actionScriptId` |
+
+Always pass `projectId` and `feedbackText`. Capture each response — note `feedback.id` and `feedbackAnalysisWorkflowRuntimeId` (may be undefined).
+
+If a single create call fails, log the error, continue with the rest, and report the failure at the end. Do not abort the batch.
+
+## 5. Report
+
+Print one line per submitted feedback in this shape:
+
+```
+✓ feedback <id> — <target description> [analysis runtime: <id>]
+```
+
+End with a one-line note:
+
+> "Regeneration runs in the background. Re-run this test case later to use the updated script."
+
+If any pieces failed, list them under a `Failed:` header with the error.
+
+## Non-negotiables
+
+- Always render the script (step 2) before collecting feedback.
+- One create call per feedback piece — never concatenate paragraphs across targets.
+- Convert step numbers from 1-based (UI) to 0-based (wire) at submit time.
+- If the user came from a non-uploaded local run, do the upload silently before submit; do not ask for permission for the upload itself.