bug-killer

Diagnose complex bugs with evidence-gated multi-path root-cause investigation and case tracking.

3|Updated Mar 20, 2026
One-click install
npx skills add https://github.com/ceasarXuu/AstartesSkills --skill bug-killer-ceasarxuu
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: bug-killer
Source: https://github.com/ceasarXuu/AstartesSkills/tree/main/skills/bug-killer
Command: npx skills add https://github.com/ceasarXuu/AstartesSkills --skill bug-killer-ceasarxuu

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Debugging large, intermittent, or repeatedly-failed bugs often leads to premature fixes based on the first plausible guess. This Skill enforces a disciplined investigation process that keeps a persistent case file, explores multiple independent root-cause paths, and blocks any repair until diagnostic evidence proves the actual mechanism. ## Core Features & Use Cases - Chain-of-Evidence Case Files: Maintains a timestamped /coe Markdown case file with Problem, Hypothesis, and Evidence nodes as the single source of truth for the investigation. - Multi-Path Root-Cause Investigation: Runs at least two independent evidence paths (code traces, reproductions, subagents, diagnostic logs, user feedback) and compares them by evidence quality rather than consensus. - Diagnostic Evidence Gate: Forbids repair design until a hypothesis is confirmed by logs, probes, tests, reproductions, or runtime observations tied to predeclared predictions. - Activation Gate & Privacy Gate: Applies the heavy workflow only to medium/large bugs and protects public repositories by confirming .gitignore handling before writing case files. - Use Case: A production bug has survived two hotfixes and crosses auth and billing modules. The Skill opens a /coe case, records falsifiable hypotheses, gathers diagnostic log evidence, confirms the root cause, and only then asks for confirmation to implement the fix. ## Quick Start Ask the agent to use bug-killer to investigate your bug with evidence-gated root-cause analysis before proposing any fix.

Frequently Asked Questions about bug-killer

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

FAQPage Schema
How do I debug a bug that keeps coming back after multiple fixes?

Use an evidence-gated debugging process that records each failed attempt in a persistent case file, generates falsifiable root-cause hypotheses, and requires diagnostic evidence such as logs, tests, or reproductions before designing the next repair. This prevents repeating guesses based on code proximity.

What is a chain-of-evidence case file in debugging?

It is a timestamped Markdown file under /coe containing Problem, Hypothesis, and Evidence nodes. Each hypothesis states falsifiable predictions and a diagnostic plan, and each evidence entry links back to the exact prediction it supports or refutes, creating an auditable investigation trail.

When should I use a heavy debugging process instead of a quick fix?

Use it when the bug crosses multiple modules, affects production or data correctness, is intermittent or hard to reproduce, has survived two or more repair attempts, or hides in deep state machines or concurrency paths. For a deterministic single-file bug with a clear stack trace, a lightweight debug loop is sufficient.

Can I write debugging case files in a public GitHub repository?

Yes, but resolve the privacy gate first: check whether /coe is gitignored and whether any case files are already tracked. Ask before adding /coe to .gitignore or untracking files, since .gitignore does not protect files already tracked by Git.

Why should diagnostic logging be separate from the repair patch?

Mixing instrumentation with the fix makes it impossible to tell which change produced the observed behavior. Diagnostic-only changes with stable event names and defined true/false signals prove the root-cause mechanism first, then the repair is implemented and validated separately.