How Mushi Mushi works
A user says your app is broken. Mushi Mushi tells you why, in plain English, and hands your AI editor the fix. This page shows each step on real screens: what to press, and where the bug goes next.
The console clips use Mushi Mushi’s own app, so every bug and pull request in them is real and public. The first clip uses a made-up shop, because it shows what your users see.
How a bug moves
- Your user, Sentry, or a checkA bug comes inFrom the report button in your app, an error in Sentry, or a check Mushi Mushi runs on its own: a first-time user test, a watch on your live site, a scan for known security holes.Watch a user report one ↓
- Mushi MushiIt is explained in plain EnglishDuplicates are merged. Mushi Mushi reads the screenshot, the page and your code, then writes why it broke, how to fix it and how to see it happen.Watch a real diagnosis ↓
- You and your AI editorYou choose who fixes itPaste the fix prompt into Cursor, Claude Code or Lovable, let your editor fetch the bug over MCP, or send it to a fix agent that opens a pull request.Watch the editor setup ↓
- CI and a second AIThe fix is checkedYour CI runs. A second AI reads the pull request next to the original report and can refuse it.
- Release trainApproved fixes ship togetherWith “Merge when ready” on, approved fixes leave together: one branch, one CI run, one merge and one deploy. Anything stuck says why.Watch the pipeline ↓
- Mushi MushiThe reporter hears backThe bug is marked fixed, and the person who reported it is told.
What it fixes about bug tracking today
| What hurts today | What Mushi Mushi does |
|---|---|
| A user writes “it’s broken” and you don’t know where to start. | Each report comes with the screen, the page and what they tapped, and a diagnosis that says why it broke. |
| You didn’t write the code line by line, so the stack trace means little. | The diagnosis is plain English: the cause, the fix and the steps to see it happen. |
| You ask the AI to fix it, and it guesses, because it has no context. | The fix prompt carries the report, the evidence and the files involved. Your editor can also fetch it over MCP. |
| Most people who hit a bug just leave. | A report button in the corner takes one sentence. Mushi Mushi also runs its own checks, so bugs nobody reports still show up. |
| Reports are scattered across email, Slack, Sentry and app reviews. | They land in one list, duplicates merged, ranked by how bad they are and how many people they hit. |
| Agent-written pull requests pile up, and each needs a careful read. | A second AI reads each one next to the original report and can refuse it. Approved fixes can ship together, in one CI run. |
| You never close the loop with the person who told you. | When the fix merges, the bug is marked fixed and the reporter is told. |
More on who feels which pain: Who it’s for.
1. Your user reports a bug
To put the button in your app, run npx mushi-mushi in your app’s folder, or
paste one script tag. See the Quickstart.
2. From the report to a merged fix
This is a real report: the app switcher in Mushi Mushi’s own console said “All apps” on pages that only show one. The pull request that fixed it is public.
3. Connect your AI editor
The Connect page guide covers each editor, and MCP lists what your editor can ask Mushi Mushi for.
4. Watch every fix ship
The numbers in this clip are real: on Mushi Mushi’s own app, many fixes wait for a person’s decision, and the page says so instead of hiding them. Pipeline explains each stage and button.
Where to go next
- Quickstart: install it on your app in a few minutes.
- Sample diagnosis: one bug, from report to fix prompt, no sign-up.
- How a bug moves, step by step: the same loop, in detail.