diagnosing-bugs

Diagnose hard bugs and performance regressions through a structured feedback-loop workflow.

Updated Aug 22, 2026
One-click install
npx skills add https://github.com/falentio/cimi --skill diagnosing-bugs-falentio
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: diagnosing-bugs
Source: https://github.com/falentio/cimi/tree/main/.agents/skills/skills/diagnosing-bugs
Command: npx skills add https://github.com/falentio/cimi --skill diagnosing-bugs-falentio

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve? Hard bugs and flaky performance regressions resist casual code reading; without a reproducible signal, debugging devolves into guessing. This Skill enforces a disciplined six-phase diagnosis loop that builds a tight pass/fail feedback signal before any hypothesis is tested. ## Core Features & Use Cases - Feedback Loop Construction: Builds a red-capable, deterministic, fast repro command using failing tests, curl scripts, headless browser runs, trace replay, fuzz loops, or git bisect harnesses. - Structured Hypothesis Testing: Generates 3-5 ranked falsifiable hypotheses, then instruments with tagged debug logs or debugger breakpoints, changing one variable at a time. - Regression Lockdown: Writes the regression test before the fix at a correct seam, then cleans up all debug instrumentation and documents the confirmed root cause. - Use Case: A user reports the export button intermittently throws an error. The Skill drives creation of a deterministic repro script, minimises the failing scenario, tests ranked hypotheses, applies the fix, and leaves a regression test behind. ## Quick Start Diagnose this bug: the export button throws an error intermittently, build a feedback loop and find the root cause.

Frequently Asked Questions about diagnosing-bugs

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

FAQPage Schema
How do I debug an intermittent or flaky bug?

Raise the reproduction rate instead of chasing a clean repro: loop the trigger 100 times, parallelise, add stress, and narrow timing windows. A bug that fails 50% of the time is debuggable; at 1% it is not, so keep increasing the rate before hypothesising.

How to diagnose a performance regression in code?

Establish a baseline measurement first using a timing harness, performance.now(), a profiler, or a query plan, then bisect between known states. Logging is usually the wrong tool for perf work; measure first and fix second.

What is a feedback loop in debugging?

It is one command, such as a failing test, curl script, or headless browser run, that goes red on the specific bug and green once fixed. It must be deterministic, fast, and runnable unattended before any hypothesis testing begins.

When should I write a regression test for a bug?

Write it before the fix, but only at a correct seam where the test exercises the real bug pattern as it occurs at the call site. If no correct seam exists, that architectural gap is itself a finding worth flagging.

What if I cannot reproduce the bug at all?

Stop and say so explicitly rather than guessing. Ask the user for environment access, a redacted captured artifact like a HAR file or log dump, or permission to add temporary production instrumentation.