diagnose

Diagnose hard bugs and performance regressions with reproducible feedback loops.

Updated May 2, 2026
One-click install
npx skills add https://github.com/ayehiaa/my-travel-assistant --skill diagnose-ayehiaa
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: diagnose
Source: https://github.com/ayehiaa/my-travel-assistant/tree/main/.claude/skills/diagnose
Command: npx skills add https://github.com/ayehiaa/my-travel-assistant --skill diagnose-ayehiaa

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve?

This Skill helps you systematically diagnose hard bugs and performance regressions by turning vague failures into a repeatable feedback loop with crisp verification.

Core Features & Use Cases

  • Build a deterministic debugging signal: prioritize failing tests, scripts, CLI fixtures, or trace replay so fixes are provably correct.
  • Run a disciplined phased workflow: reproduce, confirm the exact symptom, generate falsifiable hypotheses, instrument with targeted probes, then fix and lock in with regression tests.
  • Improve debuggability when the bug is flaky: raise reproduction rates and use structured loops rather than guesswork.
  • Safety gate when diagnosis isn’t possible: explicitly stop when no loop can be built and request concrete artifacts or access needed to proceed.

Quick Start

Ask to diagnose a specific failing scenario and provide a repro signal (error message, failing command, captured trace/logs, or a test case) so the Skill can drive the reproduce → hypothesize → instrument → fix → regression-test process.

Frequently Asked Questions about diagnose

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

FAQPage Schema
How do I debug hard bugs using a reproducible feedback loop?

Debugging hard bugs requires a reproducible feedback loop with a sharp pass/fail signal, using staged testing and falsifiable ranked hypotheses to verify fixes. You reproduce the exact symptom, generate hypotheses, instrument with probes, then fix and lock in regression tests.

What is hypothesis-driven verification for performance regression testing?

Hypothesis-driven verification for performance regression testing involves creating falsifiable ranked hypotheses to systematically isolate measurable slowdowns, using minimally invasive instrumentation and trace replay to confirm the exact cause before applying fixes.

How do I diagnose a flaky bug when reproduction rates are low?

Diagnosing a flaky bug involves raising reproduction rates by building a deterministic debugging signal from failing tests, scripts, CLI fixtures, or trace replay, then applying structured loops rather than guesswork to systematically verify staged hypotheses.

When should I stop trying to debug a failing test without a reproducible signal?

You should stop debugging a failing test when no reliable reproducible loop can be constructed. The process explicitly halts as a safety gate and requests concrete artifacts, captured traces, or access needed to proceed, preventing guesswork without a sharp pass/fail signal.

Do I need specific error logs or test cases to start debugging recurring exceptions?

To start debugging recurring exceptions you need a reproducible signal such as an error message, failing command, captured trace, logs, or a test case. This input artifact is required to drive the reproduce, hypothesize, instrument, and fix workflow effectively.

What is the best way to lock in fixes for performance regressions?

The best way to lock in fixes for performance regressions is to enforce regression-test locking after applying fixes, ensuring the measurable slowdowns are provably corrected through a deterministic feedback loop with crisp verification and staged testing.