AI Tools Want a Well-Formed Bug Report. I Have a Voice Memo.
Coding agents expect a clean, well-formed request. Real bug reports never look like that.
I’m building RuckPace, a rucking app for Android and iOS. Rucking is hiking with a loaded backpack, which means the whole app lives or dies on GPS, both to call the pace out loud while you walk and to record the session afterward.
After a nine-mile ruck I’m wrecked, so I’ve taken to recording my bug reports with voice-to-text. As you can see, I can barely speak.
Last bug report
I just did a 1 mile rock. The performance seems off. I tried to change it mid session in the middle and I saw that both chips were active both live and smoothing. I couldn’t select anything different. I felt like I was going 3.8 to 4 plus per hour and yet it was being reported as 3.4.
Four bugs in there. Bug reports don’t always make sense; this one isn’t even English.
Superpowers works best on a well-formed bug report. Hand it one of these and it reports NO_REPRO instead, and even when it can work out what I meant, it wants a well-ordered plan or it makes serial passes through the code. So why do that ordering by hand, when the model can triage the pile and group the work intelligently across a codebase I can no longer keep in my head?
What the skill actually does
So I wrote a skill, fixing-raw-bugs, for the part that happens before the plan. SKILL.md runs the phases and decides where Superpowers takes over, but the actual work lives in three reference files behind it, and each one kills a different way this goes wrong.
-
triage.mdturns a pile into an ordered list. It writes my transcript down the way I said it, keeps whatever I called the worst one, and cuts one breath into separate numbered bugs, because a wrong number and the badly worded message displaying it want different fixes. Then read-only agents fan out on Haiku, one per bug, and report facts only: whether there’s a repro, which files are involved, whether a test covers it. None of them may draw a conclusion, because a cheap model asked how hard a bug is will guess, and it will guess low. I do the ranking myself once everything lands, nothing counts as an easy fix unless the evidence names a file and a line, and anything unknown ranks up rather than down. What comes out is an ordered list built from evidence instead of from how sure I sounded on the trail. Benefit: nothing gets underestimated. -
decisions.mdseparates a code problem from a product problem. Some of what I report isn’t a bug at all. It’s a decision I never made, and the skill stops rather than guessing at it. It collects every one of those questions and asks them in a single batch, all of them, not just the two or three that look most important. Answering them is product work, not bug fixing. Each one comes with real options and the exact string or number each would produce, so I’m deciding what the app should do instead of approving an abstraction. A short batch happens in chat. A long one goes to a file I can answer at my own pace, and once a run picks a mode it stays in it. Benefit: no product call gets guessed. -
execution.mdis the part that saves money. It decides what goes into a batch, groups the bugs into waves that share a surface so one pass covers several of them, and runs those waves back to back without stopping to ask. It tiers the work automatically too: one-line fixes go to Haiku, anything needing judgment goes to Sonnet, and a wave only halts if it trips a named stop condition. That’s the difference between one serial pass per bug and one pass per wave. Benefit: no repeated passes.
Some bugs only exist outside
Superpowers won’t attempt a fix until a failing test exists, and a bug that only happens on a trail can’t produce one at a desk, so a worker handed one of those refuses and reports NO_REPRO. That’s the right call, and it stalls the run until the tooling catches up. For me that meant building device logging into the app, so every GPS reading from a real ruck gets recorded, pulled off the phone, and replayed at my desk until the bug shows up on demand.
If you use this skill you’ll need your own version of that. Point an MCP server at whatever log aggregation you already run, or build an export-and-replay path for one real session. Whatever it is, build it before the fixes and build nothing else beside it, because a fix written without it is written blind.
None of this made the model smarter. It just means that when I mumble four bugs into a phone in a parking lot, all four of them get fixed.
Two commands. It needs Superpowers and refuses to run without it.
/plugin marketplace add frictionlesscode/claude-plugins/plugin install fixing-raw-bugs@frictionlesscode