mushi-triagelisted

# Mushi Triage Workflow Use this skill to investigate a user-felt bug report end-to-end using the Mushi MCP server. ## When to use - User reports a bug and you want a complete picture before writing code - A Mushi report ID is available and you want to understand root cause, evidence, and blast radius - You want to see whether a similar bug was fixed before and what the fix looked like ## Triage workflow Run these steps in order. Do **not** call `dispatch_fix` until you have confirmed the fix scope with the user. ### Step 1 — Discover projects (if project ID unknown) ``` list_projects ``` Pick the relevant project from the returned list. ### Step 2 — Get project context ``` get_project_context { project_id: "<id>" } ``` Review SDK heartbeat, ingest status, and open report counts. ### Step 3 — Survey the triage queue ``` get_recent_reports { status: "open", limit: 10 } ``` Identify the report you want to investigate. Note the `id`. ### Step 4 — Deep evidence pull ``` get_report_evidence { report_id: "<id>" } ``` Read screenshot URL, console logs, network requests, and user comments. Form a working hypothesis. ### Step 5 — Full triage orchestration ``` 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. ### Step 6 — Fix context (if a previous fix attempt exists) ``` get_fix_context