@muggleai/works 4.10.0 → 4.11.0

package/dist/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/dist/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/dist/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/dist/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/dist/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/dist/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/dist/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/dist/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/dist/plugin/skills/muggle-do/SKILL.md

@@ -4,94 +4,69 @@ 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"`.
 
-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.
+Runs an autonomous dev cycle from requirements to PR. **Fire and review:** the user answers one pre-flight questionnaire, then walks away.
 
-For maintenance tasks, use the dedicated skills:
+For maintenance, use the dedicated skills:
 
 - `/muggle:muggle-status`
 - `/muggle:muggle-repair`
 - `/muggle:muggle-upgrade`
 
-## 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.
-
-## The seven stages
+## The pipeline
 
 | # | Stage | File | User-facing? |
 | :- | :---- | :--- | :----------- |
-| 1 | Pre-flight | [../do/pre-flight.md](../do/pre-flight.md) | **Yes — single consolidated turn** |
+| 1 | Pre-flight | [../do/pre-flight.md](../do/pre-flight.md) | **Yes — one consolidated turn** |
 | 2 | Requirements | [../do/requirements.md](../do/requirements.md) | No |
-| 3 | Impact analysis | [../do/impact-analysis.md](../do/impact-analysis.md) | No |
-| 4 | Validate code | [../do/validate-code.md](../do/validate-code.md) | No |
+| 3 | Build | [../do/build.md](../do/build.md) | No |
+| 4 | Impact analysis | [../do/impact-analysis.md](../do/impact-analysis.md) | No |
 | 5 | Unit tests | [../do/unit-tests.md](../do/unit-tests.md) | No |
 | 6 | E2E acceptance | [../do/e2e-acceptance.md](../do/e2e-acceptance.md) | No |
 | 7 | Open PR | [../do/open-prs.md](../do/open-prs.md) | No |
+| 8 | PR follow-up | [../muggle-pr-followup/SKILL.md](../muggle-pr-followup/SKILL.md) (generic) — invoked with muggle-do's cycle declaration | **Yes — only on ambiguous reviews** |
 
-**Stage 1 (pre-flight) is the ONLY stage that talks to the user.** Stages 2–7 run silently to completion. If a later stage hits a genuine blocker that the pre-flight didn't cover, escalate with a single terminal message — do not open a second round of questions.
-
-## 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.
+Stage 1 talks to the user once. Stages 2–7 run silently. Stage 7 dispatches **one Stage-8 follow-up loop per PR** it opens (not one per session); each loop polls its own PR independently for new submitted reviews. When a review lands, the loop cycles back through Stage 3 (Build) → 4 → 5 → 6 → fresh visual walkthrough → push to the existing branch, then resumes polling for the next round. Each loop may escalate once on an ambiguous review.
 
-**Red-flag behaviors (do not do):**
+**Each stage's file is the single source of truth for that stage** — definition, contract, inputs/outputs, preference gates, output format. Read each stage file directly for its rules. This file is only the orchestration spine.
 
-- Asking a clarifying question mid-cycle because "I didn't think of that at pre-flight."
-- Starting a dev server mid-cycle and discovering the port is wrong.
-- Reaching the E2E stage before knowing how the user wants it validated.
-- Asking the user to "pick one" across multiple turns instead of one turn.
+## Preferences
 
-If any of these happen, the pre-flight was incomplete — treat it as a skill bug, not a user bug, and expand `pre-flight.md` to cover the missed case after the run.
-
-## Session model
+| Preference | Stage | Decision it gates |
+|------------|-------|-------------------|
+| `autoE2ETest` | 6 (E2E acceptance) | Run E2E every cycle (default `always`), or fold the question into pre-flight |
 
-Every run writes to `.muggle-do/sessions/<slug>/`:
+Other gates that fire during this cycle (`autoUseWorktree`, `autoRebase`, `autoCreatePR`, `autoCleanup`) are owned by the per-stage files; see each stage for its contract.
 
-- `state.md` — one-screen live status: current stage (N/7), last update timestamp, pre-flight answers verbatim, any blockers.
-- `iterations/<NNN>.md` — append-only log of stage transitions for iteration NNN: what ran, what was decided, what artifacts were produced.
-- `requirements.md` — frozen output of stage 2.
-- `result.md` — final summary written by stage 7 (PR URLs, E2E outcome, open issues).
-
-**On every stage transition, you MUST:**
+## Input routing
 
-1. Append a dated entry to the active `iterations/<NNN>.md`: `### Stage N/7 — <name> (<timestamp>)` followed by the stage's output.
-2. Rewrite `state.md` to reflect the new current stage and any relevant counters.
+Treat `$ARGUMENTS` as the user command:
 
-If these files don't exist, create them — missing session files means the user lost visibility into the cycle, which is the exact failure mode this skill exists to prevent.
+- Empty / `help` / `menu` / `?` → show menu and session selector.
+- Anything else → infer intent:
+  - **Task automation** (perform an action on a website — post something, fill a form, click through a flow) → invoke `muggle:muggle-do-task` with the full prompt.
+  - **Feature development** (build / fix / refactor code) → start or resume a dev-cycle session.
 
-## Turn preamble
+When in doubt, ask one question: "Browser automation task, or code change?"
 
-Each stage turn MUST begin with one line in this form before any other output:
+## Session model
 
-```
-**Stage N/7 — <stage name>** — <one-line intent>
-```
+Every run writes to `.muggle-do/sessions/<slug>/`. Stages own the files they produce:
 
-This is how the user can tell, at a glance, what phase the cycle is in without parsing a long response.
+| File | Owned by | Purpose |
+| :--- | :------- | :------ |
+| `state.md` | Stage 1 (rewritten by every transition) | Current stage, pre-flight answers, blockers |
+| `iterations/<NNN>.md` | Every stage | Append-only stage transition log |
+| `requirements.md` | Stage 2 | Frozen requirements |
+| `prs.json`, `last_seen.json`, `followup.log` | Stage 8 | See [`pr-followup.md`](../do/pr-followup.md) |
+| `result.md` | Stage 7 (seeded), Stage 8 (finalized) | Per-PR final state |
 
 ## Guardrails
 
-- **No mid-cycle user questions.** Anything not covered by pre-flight is a skill bug; escalate once, do not loop.
-- **Do not skip unit tests before E2E acceptance tests.**
-- **Do not skip E2E acceptance tests due to missing scripts** — generate when needed.
-- **Do not hand-write the E2E block of the PR body.** The `open-prs.md` stage MUST invoke `muggle-pr-visual-walkthrough` Mode B to render the screenshots-and-steps section. Hand-writing it loses the dashboard links the user relies on for review.
-- **If the same stage fails 3 times in a row, escalate with details.**
-- **If total iterations reach 3 and E2E acceptance tests still fail**, continue to PR creation with `[E2E FAILING]` in the title; the visual walkthrough section makes the failures reviewable.
-
-## Completion contract
-
-When stage 7 finishes, the final message to the user contains at minimum:
-
-- PR URL(s)
-- E2E status (passing / `[E2E FAILING]`)
-- Link to the run dashboard for each test case (via the walkthrough skill output)
-- Path to `result.md` for full details
-
-No other content. The user already read the walkthrough in the PR body — do not re-summarize it here.
+- **Stage 1 is the only forward-pipeline user-facing stage.** Stages 2–7 don't ask questions mid-cycle. If a stage hits a blocker pre-flight didn't cover, treat as a pre-flight bug — escalate once and expand `pre-flight.md` after the run.
+- **Stage 8 may escalate** once per ambiguous review comment, and may dispatch back to Stage 3 when needed — see [`pr-followup.md`](../do/pr-followup.md).
+- **If the same stage fails 3 times in a row, escalate** with details.
+- **If 3 cycle iterations reach E2E with failures**, ship with `[E2E FAILING]` per [`open-prs.md`](../do/open-prs.md). The walkthrough section keeps the failures reviewable.

package/dist/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/dist/plugin/skills/muggle-feedback/SKILL.md

@@ -0,0 +1,39 @@
+---
+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, which step(s), confirm). Step selection must be a clickable picker built from the rendered steps (see [`ops/submit.md`](ops/submit.md) §3b) — never ask the user to type a number.
+- Always render the run's steps and summary (§2) **before** collecting feedback — users can only point at what they can see.
+- 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/dist/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/dist/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.