Skip to lesson
Exit
Deep Debugging & Root-Cause1 / 4

1 min lesson

The investigation isn't done when you understand the bug

Use "Lead with impact, not narrative" to say what you would do next.

Step 1 of 4

The investigation isn't done when you understand the bug. It's done when an engineer can read your report in under a minute and know exactly what to do next.

This is the part of the job leadership sees and the part that scales your impact. A clean report saves engineers their first hour of re-deriving your work and it's the artifact that earns you trust as the escalation point. Lead with impact, not narrative.

Learn more

Advanced table

Reference table

Section
Impact & severity
What goes here
One line: what breaks, how bad (data loss / security / outage > broken feature > annoyance) and the reach.
Section
Repro steps
What goes here
Numbered, exact, copy-pasteable. Include the minimal repo or fixture if you built one.
Section
Expected vs actual
What goes here
Two short lines. The gap is the bug.
Section
Environment
What goes here
OS, Cursor version, model, plan, relevant extensions, network shape.
Section
Evidence
What goes here
Logs, HAR, screen recording, stack trace - attached, not described.
Section
Hypothesis & ruled-out
What goes here
Your best guess at root cause, plus what you eliminated. This is what makes it senior.
Section
Frequency & reach
What goes here
How many users, which versions, how often. Ties the bug to prioritization.

Top to bottom is roughly the order an engineer reads in.

Learn more

Optional practice

Practice: The investigation isn't done when you understand the bug