diagnosing-bugs

Diagnose bugs through a six-phase hypothesis-driven investigation loop before applying fixes.

1|Updated Jul 17, 2026
One-click install
npx skills add https://github.com/dariovr1/sixth-sense --skill diagnosing-bugs-dariovr1
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: diagnosing-bugs
Source: https://github.com/dariovr1/sixth-sense/tree/main/skills/diagnosing-bugs
Command: npx skills add https://github.com/dariovr1/sixth-sense --skill diagnosing-bugs-dariovr1

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Developers often jump straight to random fixes when facing bugs or test failures, wasting time on symptoms instead of root causes. This Skill enforces a disciplined investigation loop that requires naming the root cause before any production code changes. ## Core Features & Use Cases - Six-Phase Diagnosis Loop: Reproduce, Minimise, Hypothesise, Instrument, Fix, and Regression Test, with concrete guidance for Java, JUnit, and Spring Boot environments. - Fix Escalation Guard: After three failed fix attempts, the Skill stops further patching and forces a re-examination of architectural assumptions with the human partner. - Learnings Ledger: Reusable pitfalls discovered during diagnosis are appended to .sixth-sense/learnings.jsonl so the same class of bug is never re-diagnosed from scratch. - Use Case: A Spring Boot integration test fails intermittently. The Skill guides you to isolate it with a single JUnit test, form one testable hypothesis from the stack trace, instrument with temporary logging, fix at the narrowest responsible layer, and add a regression test. ## Quick Start Ask the AI to diagnose the failing test or unexpected behavior using the diagnosing-bugs workflow before proposing any fix.

Frequently Asked Questions about diagnosing-bugs

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

FAQPage Schema
How do I debug a failing test without guessing at fixes?

Follow a hypothesis-driven loop: reproduce the failure reliably, minimise the test case, state one testable hypothesis, instrument to verify it, then fix only the root cause. Never change production code before naming the root cause out loud.

How to isolate a bug in a Spring Boot application?

Strip the failure down to a minimal @SpringBootTest context or a plain unit test, removing unrelated beans and configurations. Read the full stack trace and check bean wiring, transaction boundaries, and lazy loading before forming a hypothesis.

What should I do when multiple fix attempts keep failing?

After three failed fixes, stop patching. Repeated fixes revealing new shared state or coupling elsewhere signal an architectural problem, not a wrong hypothesis. Re-examine the fundamentals with your team before touching code again.

Can I run a single JUnit test with Gradle to reproduce a bug?

Yes. Run ./gradlew test --tests "TestClass.testMethod" to execute one test method in isolation. This creates the smallest reliable feedback loop for confirming the bug before investigating further.

When should debugging findings be recorded for future reuse?

Record a finding only when diagnosis surfaces a non-obvious, reusable pattern such as a platform gotcha or recurring bug class. Append it as a JSON line to .sixth-sense/learnings.jsonl; skip one-off bugs with no reusable lesson.