investigate

Investigate software bugs through a four-phase root-cause analysis workflow.

Updated Feb 27, 2026
One-click install
npx skills add https://github.com/curielmc/beat-SPY --skill investigate-curielmc
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: investigate
Source: https://github.com/curielmc/beat-SPY/tree/main/.claude/skills/gstack/investigate
Command: npx skills add https://github.com/curielmc/beat-SPY --skill investigate-curielmc

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Structured debugging to identify root causes of bugs through a repeatable four-phase workflow: investigate, analyze, hypothesize, implement.

Core Features & Use Cases

  • Guided collection of symptoms, error messages, and reproduction steps to frame the problem.
  • Systematic analysis and hypothesis generation to pinpoint the root cause.
  • Safe scope control and a documented path to implement a verifiable fix.

Quick Start

Investigate the issue by collecting symptoms, tracing the code path, and forming a root-cause hypothesis.

Frequently Asked Questions about investigate

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

FAQPage Schema
How do I find the root cause of a software bug systematically?

Root-cause debugging uses a four-phase workflow—investigate, analyze, hypothesize, implement—to systematically trace code paths and form a testable root-cause hypothesis. It guides symptom collection and reproduction steps to frame the problem before implementing a verifiable fix.

What is the best way to structure a debugging workflow for complex code analysis?

A structured debugging workflow separates root-cause analysis into investigate, analyze, hypothesize, and implement phases. This approach uses scope locking and structured evidence gathering to ensure a repeatable, reproducible path to a verifiable fix.

How do I generate a root-cause hypothesis from error messages and symptoms?

To generate a root-cause hypothesis, first collect symptoms, error messages, and reproduction steps during the investigation phase. Then, systematically analyze the code path to pinpoint the root cause and transition into implementing a verifiable fix.

Can I use scope locking to prevent unintended changes during code analysis?

Yes, scope locking is integrated into the debugging workflow to prevent unintended changes. It confines the investigation, analysis, and implementation phases to a safe boundary, ensuring the verifiable fix targets only the identified root cause.

Why does debugging fail without a reproducible approach to symptom collection?

Debugging fails without a reproducible approach because the four-phase workflow requires structured evidence gathering. Reproducible symptoms and error messages are necessary to accurately frame the problem, form a testable hypothesis, and yield a verifiable fix.