bug-investigation

Diagnose bug root causes using observation-driven investigation methods.

Updated Jun 12, 2026
One-click install
npx skills add https://github.com/missingbulb/GoogleCalendarEventCreator --skill bug-investigation-missingbulb
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: bug-investigation
Source: https://github.com/missingbulb/GoogleCalendarEventCreator/tree/main/.claudinite/shared/packs/basics/skills/bug-investigation
Command: npx skills add https://github.com/missingbulb/GoogleCalendarEventCreator --skill bug-investigation-missingbulb

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Bug fixes often fail because teams iterate on an unverified theory instead of re-deriving the cause from evidence. This Skill provides a disciplined method for pinning down root causes before committing to a fix. ## Core Features & Use Cases - Recurring bug analysis: Re-derive causes from observation when a fix doesn't hold, weighting the repo's own shipped-working behavior over external claims. - Version gap checks: Compare installed versions against the latest release and use git log -S when a report doesn't reproduce against main. - Evidence-first reporting: Request browser Network tab and Application/Storage panel evidence before building speculative local reproductions. - Use Case: A user reports the live app shows stale data. Instead of guessing which cache layer is at fault, you ask for a Network tab screenshot first, then verify whether the fix merged but hasn't shipped yet. ## Quick Start Investigate this bug report and help me pin down the root cause before proposing a fix.

Frequently Asked Questions about bug-investigation

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I investigate a bug that keeps recurring after a fix?▼

Re-derive the cause from observation rather than iterating on the prior theory. Weight the repo's own shipped-working behavior over external claims like blog posts, since prior working code is a real run while a stale external claim is not.

What should I check when a bug report doesn't reproduce locally?▼

Check the version gap first: compare the installed or package.json version to the latest release and use git log -S to verify whether the fix merged but hasn't shipped. The user runs the released build, not your checkout.

Why can a local bug reproduction lead to the wrong root cause?▼

When multiple layers can produce the same symptom, such as an HTTP cache, application cache, or client-side TTL, a repro built around the first suspected layer can reproduce the symptom for a different reason. Ask for the reporter's browser evidence first.

Can I rely on retry or fallback logic instead of fixing a bug?▼

No. Self-heal mechanisms exist to keep production alive when unforeseen issues slip through, not to handle known defects. A healer firing on a known bug is evidence the bug is live; root-cause and fix the primary path.

How do I verify a bug theory before announcing a root cause?▼

Get one real datapoint from a minimal probe run by someone who can exercise the platform. A theory predicts what you will find but is not itself the finding; read the actual run logs rather than reasoning forward from your diagnosis.