gstack-openclaw-investigate

Execute Phase 1-5 root-cause analysis and output a structured debug report.

2|1|Updated Mar 5, 2026
One-click install
npx skills add https://github.com/vnmoorthy/Skylog --skill gstack-openclaw-investigate-vnmoorthy
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: gstack-openclaw-investigate
Source: https://github.com/vnmoorthy/Skylog/tree/main/.claude/skills/gstack/openclaw/skills/gstack-openclaw-investigate
Command: npx skills add https://github.com/vnmoorthy/Skylog --skill gstack-openclaw-investigate-vnmoorthy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill provides a disciplined, step-by-step framework to perform root-cause analysis for bugs, ensuring fixes address the underlying issues rather than symptoms.

Core Features & Use Cases

  • Phase-driven workflow spanning Phase 1-5 to guide symptom collection, hypothesis testing, and verification.
  • Evidence-led debugging that emphasizes reproducing steps, collecting logs, and testing hypotheses.
  • Structured reports that document symptoms, root cause, fixes, and regression plans for audits and knowledge sharing.

Quick Start

Provide a step-by-step root-cause analysis of the reported issue using the Phase 1-5 framework and produce a structured debug report.

Frequently Asked Questions about gstack-openclaw-investigate

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

FAQPage Schema
What is phase-based root-cause analysis for software debugging?

Phase-based root-cause analysis is a structured debugging workflow that guides you through symptom collection, hypothesis testing, and verification to systematically identify the underlying cause of software bugs rather than just treating symptoms.

How do I systematically troubleshoot a software regression across codebases and logs?

You troubleshoot a software regression by applying a disciplined phase-driven workflow that enforces evidence-led debugging, collecting reproduction steps and logs to test hypotheses, identify the root cause, and output a structured debug report.

Does this root-cause analysis approach require any specific debugging dependencies or tools?

No dependencies are required to use this root-cause analysis approach. It provides a self-contained, step-by-step framework that can be applied directly to bug investigations and error reports across your existing codebases and deployments.

What is the best way to document software bug investigations for audits and knowledge sharing?

The best way to document bug investigations is generating a structured debug report that captures symptoms, root cause, fixes, and regression plans, ensuring the evidence-led debugging process is reproducible and verifiable for future audits.

How do I verify a software fix actually addresses the underlying issue instead of a symptom?

You verify a software fix addresses the underlying issue by following the structured root-cause analysis workflow through to its final phases, which provide specific guidance for testing hypotheses and validating the resolution against the original reproduction steps.

When should I use a structured root-cause analysis framework instead of standard debugging?

You should use a structured root-cause analysis framework when standard debugging risks treating symptoms instead of root causes, particularly during complex bug investigations, error reports, and regressions spanning multiple codebases, deployments, and logs.