rlm-debugging

Perform systematic root cause analysis for software bugs and failing tests.

67|2|Updated Feb 7, 2026
One-click install
npx skills add https://github.com/doubleuuser/rlm-workflow --skill rlm-debugging
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: rlm-debugging
Source: https://github.com/doubleuuser/rlm-workflow/tree/main/skills/rlm-debugging
Command: npx skills add https://github.com/doubleuuser/rlm-workflow --skill rlm-debugging

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill prevents guesswork and symptom-based fixes by enforcing a structured Phase 1.5 root cause investigation that captures error analysis, reproduction steps, evidence, and a documented fix strategy before any code changes are attempted.

Core Features & Use Cases

  • Structured Phase 1.5 Template: Provides a ready artifact layout for error analysis, reproduction verification, recent changes review, data-flow tracing, pattern comparison, hypothesis tests, and a final root cause summary.
  • Defensive Workflow & Gates: Defines coverage and approval gates to ensure root causes are confirmed and tests are created before proceeding to implement fixes.
  • Use Case: Investigate failing CI tests, intermittent crashes, incorrect API responses, or performance regressions and produce a locked Phase 1.5 artifact that feeds into the Phase 3 fix plan.

Quick Start

Start Phase 1.5 by creating a 01.5-root-cause.md artifact and follow the prescribed error analysis, reproduction, evidence gathering, hypothesis testing, and summary steps to produce a locked root cause report for Phase 3.

Frequently Asked Questions about rlm-debugging

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

FAQPage Schema
How do I perform root cause analysis for failing CI tests and software bugs?

Root cause analysis for failing CI tests requires documenting error messages, reproduction steps, recent changes, data-flow traces, and hypothesis tests before attempting fixes. This process produces a locked Phase 1.5 artifact that feeds directly into your subsequent fix plan.

What is the best way to investigate intermittent crashes and performance regressions before fixing code?

Investigating intermittent crashes and performance regressions involves a structured template capturing error analysis, reproduction verification, evidence gathering, and hypothesis testing. This enforces a defensive workflow ensuring root causes are confirmed before any code modifications proceed.

How do I stop guessing and trace data-flow to find the root cause of incorrect API responses?

Tracing data-flow to find root causes of incorrect API responses involves pattern comparison and hypothesis testing within a structured artifact. This prevents symptom-based fixes by requiring evidence and reproduction verification before moving to implementation.

Does this debugging workflow require specific dependencies or components to investigate CI failures?

This debugging workflow requires no specific dependencies or components to investigate CI failures. It provides a ready artifact layout and defines coverage gates to ensure tests are created and root causes are confirmed before proceeding to implement fixes.

When do I need a Phase 1.5 artifact for bug fixing and what does it contain?

A Phase 1.5 artifact for bug fixing is needed before implementing code changes and contains error analysis, reproduction steps, recent changes review, data-flow tracing, hypothesis tests, and a final root cause summary to guide the fix strategy.

Why should I document reproduction steps and recent changes before fixing integration issues?

Documenting reproduction steps and recent changes before fixing integration issues prevents guesswork by enforcing a structured root cause investigation. This defensive workflow defines approval gates to ensure causes are confirmed and tests are created prior to code changes.