Menu
End-to-end bug triage using Mushi MCP tools. Discover, investigate, and decide on fix dispatch — all without leaving your IDE.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Guided Mushi Mushi onboarding — install the right SDK for the detected framework, sign in, write env vars, and wire the MCP server into the editor. Use when "set up mushi", "install mushi", "add mushi to this project", "mushi onboarding", "wire mushi into cursor/claude", or when a repo has no Mushi SDK yet and the user wants bug capture + AI diagnosis.
Pass/fail health check across every Mushi Mushi pipeline component — CLI credentials, API reachability, edge functions, BYOK key pool, QA cron. Use when "is mushi working", "mushi health check", "check mushi pipeline", "mushi deploy check", "pipeline not responding", or right after setup.
Set up Mushi Mushi in a new project — install SDK, configure API keys, connect to the admin console, map user stories from a live app, and generate TDD tests. Use when the user asks to "set up mushi", "add mushi to my project", "connect mushi", "configure mushi", "install mushi sdk", "map my user stories", or "start using mushi tdd".
Pass/fail health check across every Mushi Mushi pipeline component — CLI credentials, API reachability, edge functions, BYOK key pool, QA cron. Use when "is mushi working", "mushi health check", "check mushi pipeline", "mushi deploy check", "pipeline not responding", or right after setup.
Debug Mushi Mushi issues — SDK not reporting, API errors, LLM key exhaustion, story mapping failures, QA test failures, PDCA loop not running, edge function errors. Use when "mushi is not working", "sdk not pinging", "story map failed", "tdd test not running", "api key exhausted", "fix-worker failed", "pdca not improving", or any mushi error/failure.
Full end-to-end Mushi Mushi integration smoke test: bug capture → AI triage → story mapping → TDD test generation → approval → execution → PDCA cycle. Use when "test mushi integration", "verify full pipeline", "mushi e2e check", "does mushi work end-to-end", "smoke test mushi", or after deploying changes.
| name | mushi-triage |
| title | Mushi Triage Workflow |
| description | End-to-end bug triage using Mushi MCP tools. Discover, investigate, and decide on fix dispatch — all without leaving your IDE. |
| chain_slugs | [] |
Use this skill to investigate a user-felt bug report end-to-end using the Mushi MCP server.
Run these steps in order. Do not call dispatch_fix until you have confirmed the fix scope with the user.
list_projects
Pick the relevant project from the returned list.
get_project_context { project_id: "<id>" }
Review SDK heartbeat, ingest status, and open report counts.
get_recent_reports { status: "open", limit: 10 }
Identify the report you want to investigate. Note the id.
get_report_evidence { report_id: "<id>" }
Read screenshot URL, console logs, network requests, and user comments. Form a working hypothesis.
triage_issue { report_id: "<id>", project_id: "<id>", include_logs: true }
This combines report detail, similar bugs, fix context, blast radius, and recent pipeline logs into one packet. Read recommended_actions carefully.
get_fix_context { reportId: "<id>" }
Check what the previous fix attempt did and why it may have failed.
get_pipeline_logs { project_id: "<id>", level: "error", limit: 20 }
Only after discussing findings and getting confirmation:
dispatch_fix { reportId: "<id>", autoReadyPr: false }
autoReadyPr: false keeps the PR as a draft for review before it can merge.
dispatch_fix, close_report, reopen_report, or reply_to_reporter without explicit user confirmation.severity: critical, also check blast radius before dispatching.MUSHI_API_KEY value in chat or commits.