メニュー
Muggle AI command router and menu. Use when user types "muggle" or asks for available Muggle Test commands.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when the user wants a pull request's incoming review feedback handled for them — it watches one PR's review thread and, each time a reviewer submits new comments, dispatches the work to address them. Engage on PR-review-follow-up intent: "watch my PR and address review comments as they come in", "keep an eye on PR #123 and respond to reviewer feedback", "babysit my PR's review thread", "I'm stepping away — handle my PR's reviews while I'm gone". This is PR-review-specific automation — prefer it over the generic loop skill. It only watches and dispatches; the actual edits and replies are muggle-do. Not for posting test results to a PR (use muggle-pr-visual-walkthrough).
Take a feature request, spec, design, bug, or ticket and carry it autonomously to an opened pull request — write the code, test it, raise the PR. Use whenever the user wants something built, implemented, added, or fixed with a PR opened, raised, or put up at the end — "implement rate limiting and raise a PR", "build the CSV export and put up a PR", "take this Jira ticket and run with it, ping me when the PR is up", "fix this bug and open a pr", or "muggle do …". Also handles the internal `address-reviews` directive the muggle-pr-followup watcher dispatches when new reviews land. Not for testing or validating existing changes (use muggle-test), nor watching a PR's incoming reviews (use muggle-pr-followup).
View, set, or reset Muggle AI preferences that control testing behavior. Use when user asks to see preferences, change a setting, configure Muggle Test defaults, or manage muggle config. Triggers on: 'muggle preferences', 'show muggle settings', 'change muggle preference', 'set autoLogin to always', 'muggle config', 'reset muggle preferences', 'show my muggle settings', 'configure muggle', 'muggle setup'.
Run a real-browser end-to-end (E2E) acceptance test against localhost to verify a feature works correctly — signup flows, checkout, form validation, UI interactions, or any user-facing behavior. Launches a browser that executes test steps and captures screenshots. Use this skill whenever the user asks to test, validate, or verify their web app, UI changes, user flows, or frontend behavior on localhost or a dev server — even if they don't mention 'muggle' or 'E2E' explicitly.
Cut @muggleai/works release: AskUserQuestion (major/minor/patch), sync master, stop if nothing ships, semver baseline + Electron from GitHub, confirm plan, bump package.json + sync:versions, full local verify, chore(release) PR, merge via gh, dispatch publish-works-to-npm.yml—no local npm publish.
Use when the user wants to flag that a generated Muggle Test action script — or one specific step in it — did the wrong thing, so Muggle can analyze and regenerate affected scripts. Covers any report that a script or step is wrong, broken, or misbehaving (clicked the wrong element, step N did not work, broken at the submit step), whether from a recent local/remote run or a pasted Muggle dashboard run/script URL. Also lists, views, or deletes previously submitted feedback. Triggers on /muggle-feedback, give feedback on this run, the test was wrong, flag this run.
| name | muggle |
| model | haiku |
| description | Muggle AI command router and menu. Use when user types "muggle" or asks for available Muggle Test commands. |
Telemetry first step: see
_shared/telemetry-emit.md. UseskillName: "muggle".
Use this as the top-level Muggle Test command router.
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.
If the user types "muggle" with no subcommand and you want to surface a contextual hint about the update-check pref, defer to muggle-status rather than reimplementing the gate in this router.
When user asks for "muggle" with no specific subcommand, use AskUserQuestion to present these four options:
muggle-test-feature-local (local) or muggle-test (remote/change-driven)muggle-domuggle-status (then muggle-repair if issues found)muggle-upgradeIf the user intent clearly matches one command, route directly — no menu needed:
muggle-statusmuggle-repairmuggle-upgrademuggle-testmuggle-test-feature-localmuggle-domuggle-pr-visual-walkthroughmuggle-pr-followupmuggle-feedbackIf intent is ambiguous, use AskUserQuestion with the most likely options rather than asking the user to type a clarification.