investigate

Automate root-cause debugging with a phased investigate, analyze, hypothesize, implement workflow.

Updated Apr 20, 2026
One-click install
npx skills add https://github.com/aspectrr/denchclaw-workspace --skill investigate-aspectrr
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: investigate
Source: https://github.com/aspectrr/denchclaw-workspace/tree/main/skills/gstack/investigate
Command: npx skills add https://github.com/aspectrr/denchclaw-workspace --skill investigate-aspectrr

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Systematic root-cause debugging. Four phases: investigate, analyze, hypothesize, implement. Iron Law: no fixes without root cause investigation first. Use when debugging errors, unexpected behavior, or troubleshooting.

Core Features & Use Cases

  • Phase-driven analysis with structured outputs
  • Reproducible hypothesis testing and validation
  • Clear escalation and verification workflow for fixes

Quick Start

Follow the steps in Phase 1 to collect symptoms, read the code, reproduce the bug, and produce a root cause hypothesis.

Frequently Asked Questions about investigate

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

FAQPage Schema
What is the best way to find a root cause when debugging unexpected software behavior?

Systematic root-cause debugging uses a phased workflow to collect symptoms, read the code, reproduce the bug, and form a verifiable hypothesis. This enforces the rule of no fixes without prior investigation, ensuring you address the actual issue.

How do I start troubleshooting an error in my codebase?

Troubleshooting starts by collecting symptoms and reading the relevant code to reproduce the bug. You then move through analysis and hypothesis phases to produce a reproducible root cause hypothesis and verification steps before implementing any fix.

Can I use structured hypothesis testing for debugging errors across large codebases?

Structured hypothesis testing applies to debugging errors across codebases of varying sizes. It uses a phased workflow to systematically investigate, analyze, and validate root causes, ensuring fixes are reproducible.

Why should I form a root cause hypothesis before implementing a software fix?

Forming a root cause hypothesis before implementing a fix enforces the Iron Law of debugging: no fixes without root cause investigation first. This ensures you verify the actual problem rather than treating symptoms, leading to reproducible and reliable resolutions.

Does root-cause debugging work for troubleshooting unexpected behavior without clear error messages?

Root-cause debugging works for troubleshooting unexpected behavior by applying a structured investigation and analysis workflow. It helps you collect symptoms, form a hypothesis, and generate verification steps even when explicit error messages are absent.