af-investigate

Diagnose software issue root causes through iterative, hypothesis-driven investigation.

3|Updated Oct 5, 2025
One-click install
npx skills add https://github.com/korchasa/ide-rules --skill af-investigate
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: af-investigate
Source: https://github.com/korchasa/ide-rules/tree/main/catalog/skills/af-investigate
Command: npx skills add https://github.com/korchasa/ide-rules --skill af-investigate

SYSTEM DOCUMENTATION & REQUIREMENTS

## What problem does it solve? Diagnoses root causes of software issues through an iterative, hypothesis-driven investigation.

## Core Features & Use Cases

  • Hypothesis generation and user-controlled selection to steer debugging.
  • Visualized Hypothesis Board with probabilities, evidence, and progress tracking.
  • Enforced non-production changes, clean baselines between experiments, and automatic audit trails using a task-management tool.

### Quick Start Initialize a plan, gather initial data (logs, environment details), and present 3–7 candidate hypotheses for user selection.

Frequently Asked Questions about af-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 through iterative debugging?

Root-cause debugging works by generating 3–7 candidate hypotheses, having the user select the most probable, and running controlled experiments to gather evidence and narrow down the actual cause.

What is a hypothesis-driven investigation for software issues?

Hypothesis-driven investigation is a debugging method that formulates potential explanations for an issue, tracks their probabilities and evidence on a visual board, and iteratively tests user-approved hypotheses.

How do I track debugging steps and maintain a clean baseline between experiments?

Use a task-management tool to track debugging steps and maintain an automatic audit trail. Enforce non-production changes and restore a clean baseline between experiments to ensure test integrity.

Can I use this root-cause analysis approach safely in a production environment?

No, this approach enforces non-production changes. It requires gathering initial data like logs and environment details but restricts actual experiments and hypothesis testing to non-production environments.

What's the best way to start a root-cause analysis when diagnosing code or runtime issues?

Initialize a plan, gather initial data such as logs and environment details, and generate a list of 3–7 candidate hypotheses for the user to review and select from to steer the investigation.