ds-debug

What it does and when to use it

Use when a test fails unexpectedly, runtime behavior is wrong, or a flaky failure needs a reproducible cause.

How it works

SKILL.md has no level-two headings · 12 lines, 197 words

---
name: "ds-debug"
description: "Use when a test fails unexpectedly, runtime behavior is wrong, or a flaky failure needs a reproducible cause."
---

# Find the cause, then fix it

1. Reproduce the failure with the exact command or steps, expected result, and actual result. Read the full error and compare a working case when available.
2. Choose one hypothesis and the cheapest observation that could disprove it. Change one variable at a time.
3. After two wrong hypotheses, recheck inputs, versions, configuration, and what actually ran. After a third, record what you ruled out and switch methods, such as bisecting or comparing a known-good build. If that also fails, report the specific missing input or decision and stop the affected work.
4. Fix the cause and lock it down with a focused regression check. Prefer a failing test before the fix; if the reproduction is impractical, explain the gap and use the closest executable check. Remove temporary logging.

Missing services, credentials, disk, and overloaded hosts need one or two direct environment fixes, then a blocker report. Do not change product behavior to hide the environment failure.

For a flaky test outside changed code, rerun once and report a follow-up if it passes. For changed code, investigate shared state, timing, or ordering; do not hide failures with retries or sleeps.

Versions

The database has no other skills named ds-debug.

Database snapshot: 13.11.2026 · package version 75f75938d3fb (SHA-256 digest of the entire package)

Downloads in the last 30 days: 0 · ranking

Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.

Similar skills

• 100systematic-debugging
  Use when code fails, a test breaks, or a program behaves wrong: find the root cause before fixing.
• 100debugging
  Finds the root cause of a bug before fixing it. Use when something behaves unexpectedly, throws, fails a test, runs slow, or the user says "find out why". Not for a precisely diagnosed fix, test runs, reviews or tests-first work.
• 90systematic-debugging
  Find the root cause of a bug or failing check before changing code. Use when a test, build, command, or DoneCheck check fails or behaves unexpectedly.
• 100v1-debug
  Use when an observable problem is wrong, recurring, or unexplained and needs root-cause diagnosis. Triggers on "debug this", "why is this failing", or "find the root cause".
• 100debug-failure
  Find the root cause of an error, crash, failing test, regression or wrong behaviour, then fix it with a regression test. Use this whenever something is broken or behaves unexpectedly and the cause is not already proven, even if a fix seems obvious. Do not guess at fixes.
• 90root-cause-debugging
  Use when behavior is wrong or broke and the cause is unknown, or someone asks what went wrong: a failing test, wrong totals or output, a 500 in production, something that worked before, a flaky run. Not for adding logging, debug settings, explaining traces or tests for new features.