root-cause-tracing

Trace call chains backwards to identify original error triggers.

Updated Feb 17, 2026
One-click install
npx skills add https://github.com/tim-hub/role-based-skills --skill root-cause-tracing-tim-hub
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: root-cause-tracing
Source: https://github.com/tim-hub/role-based-skills/tree/main/root-cause-tracing/root-cause-tracing
Command: npx skills add https://github.com/tim-hub/role-based-skills --skill root-cause-tracing-tim-hub

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps developers and testers find the true origin of errors that appear deep in the call stack so you avoid fixing only the symptom and instead repair the underlying trigger and prevent future pollution.

Core Features & Use Cases

  • Backward call-chain tracing: Systematically walk up the call stack to discover which caller passed the invalid value or invoked the problematic operation.
  • Instrumentation guidance: Practical examples for adding stack capture and contextual debug logs before dangerous operations to reveal the caller and environment.
  • Test bisection: A script-driven approach to run tests incrementally and identify the specific test that creates unwanted files or state (test pollution).
  • Use case: Find which test or initialization created a .git folder in the source tree by tracing an empty cwd parameter back through setup code and adding defensive validations.

Quick Start

Ask the assistant to trace an error where a git init or another operation ran in the wrong directory and identify the original call or test that triggered it.

Frequently Asked Questions about root-cause-tracing

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

FAQPage Schema
How do I trace an error back to its original caller when the stack trace is misleading?

To trace errors backward, you systematically walk up the call chain to find which caller passed the invalid value. This methodology uses stack capture and contextual debug logs to reveal the true trigger behind runtime failures.

What is the best way to find which test is causing test pollution in my CI pipeline?

Test bisection isolates the specific test causing pollution by running tests incrementally. This script-driven approach identifies tests that create unwanted files or state, preventing flaky tests and invalid data in your CI pipeline.

How do I debug a flaky test where the immediate error symptom is not the root cause?

Debugging flaky tests requires backward call-chain tracing to discover the original trigger. By adding instrumentation for stack logging before dangerous operations, you can reveal the caller and environment that caused the invalid data.

How do I trace back to find which test created a .git folder in the wrong directory?

You trace the empty cwd parameter back through setup code to find the test or initialization that triggered the git init. Adding defensive validations after using test bisection helps isolate the specific test creating unwanted files.

When should I use test bisection instead of standard debugging for runtime failures?

Use test bisection when errors surface deep in the stack and the immediate symptom is misleading, such as CI test pollution. Standard debugging often fixes only the symptom, while bisection isolates the specific test creating unwanted state.

What instrumentation is needed to capture the caller of a problematic operation?

Instrumentation for stack capture involves adding contextual debug logs before dangerous operations. This practical guidance reveals the caller and environment, helping you trace backwards through call chains to find the original trigger of errors.