Przejdź do treści
Biblioteka skilli
Programowanie · Analiza

debug-root-cause

/debug-root-cause

Szuka i naprawia systematycznie przyczyny błędów, awarii i nieudanych testów w JavaScript, TypeScript i Pythonie, zamiast zgadywać poprawkę.

Repozytorium
kiln ↗
Licencja
MIT
Ostatnia zmiana repozytorium
09.11.2026

Ocena i bezpieczeństwo

100/ 100Klasa: dobry
Format25 / 25
Frontmatter z nazwą i opisem, poprawna nazwa, opis do 1024 znaków, nazwa zgodna z folderem.
Odkrywalność25 / 25
Opis mówi, kiedy użyć skilla, ma sensowną długość i jest w 3. osobie.
Treść35 / 35
Co najmniej 150 słów i do 500 linii, nagłówki, listy kroków, przykłady albo kod.
Higiena15 / 15
Bez zaślepek typu TODO, bez ścieżek Windows, z licencją.
Ryzykobrak sygnałów w skanie
Pliki w paczce
1
Skrypty
0
Komentarze HTML
0
Adresy URL w SKILL.md
0
Przestarzałość

Brak sygnałów. Repozytorium zmienione 09.11.2026, bez odwołań do wycofanych modeli i API.

Licencja

MIT, otwarta: można używać i zmieniać, z zachowaniem informacji o autorze.

Co robi i kiedy

Szuka i naprawia systematycznie przyczyny błędów, awarii i nieudanych testów w JavaScript, TypeScript i Pythonie, zamiast zgadywać poprawkę.

Wyzwalacze z opisu

not workingerrorkenapa gagalbug
Oryginalny opis (EN)

Systematically find and fix the root cause of bugs, errors, failing tests, and crashes in JavaScript/TypeScript and Python. Use whenever the user pastes an error or stack trace, says something is broken, "not working", "error", "kenapa gagal", "bug", a test fails, or behavior is unexpected — instead of guessing at a fix.

Jak działa

  1. 1. Reproduce
  2. 2. Read the error properly
  3. 3. Hypothesize, then prove
  4. 4. Fix at the root
  5. 5. Prevent regression
  6. 6. Report
Sekcje z nagłówków SKILL.md, w oryginale · 55 linii, 469 słów
Podgląd SKILL.md
---
name: debug-root-cause
description: Systematically find and fix the root cause of bugs, errors, failing tests, and crashes in JavaScript/TypeScript and Python. Use whenever the user pastes an error or stack trace, says something is broken, "not working", "error", "kenapa gagal", "bug", a test fails, or behavior is unexpected — instead of guessing at a fix.
---

# Debug: Root Cause First

The most common debugging failure is patching the symptom. This skill forces a reproduce → hypothesize → prove → fix loop.

## 1. Reproduce

- Get the exact failing command (test, script, request). Run it yourself and capture the full output.
- If it doesn't reproduce, stop and gather info: environment, versions (`node -v`, `python --version`, lockfile), input data, env vars. Don't fix what you can't see.
- Make the reproduction as small and fast as possible (a single test, `pytest path::test_name -x`, `npx vitest run file -t "name"`).

## 2. Read the error properly

- Read the **whole** stack trace. The first frame in *the user's own code* (not `node_modules` / `site-packages`) is usually where to look.
- Read the actual code at those lines, plus callers.
- Common decoders:
  - `Cannot read properties of undefined (reading 'x')` / `AttributeError: 'NoneType'` → something upstream returned nothing; find where the value came from.
  - `ERR_MODULE_NOT_FOUND`, `ModuleNotFoundError` → path, ESM/CJS mismatch, virtualenv not active, missing dependency.
  - `UnhandledPromiseRejection`, `RuntimeWarning: coroutine was never awaited` → missing `await`.
  - Works locally, fails in CI → env vars, timezone, file ordering, node/python version, test isolation.
  - Flaky → shared state between tests, time, randomness, network, race conditions.

## 3. Hypothesize, then prove

Write down 1–3 hypotheses ranked by likelihood. For each, pick the cheapest experiment that would confirm or kill it:
- Add a targeted log/print of the suspicious value (remove it after).
- Write a failing test that pins the bug.
- `git bisect` if it "used to work": `git bisect start; git bisect bad; git bisect good <sha>` then run the repro at each step.
- Check what changed recently: `git log -p --since="3 days ago" -- <file>`.

Only move to a fix when one hypothesis is **proven**. If all are killed, go back to step 2 with the new evidence.

## 4. Fix at the root

- Fix where the bad value/state is *created*, not where it *explodes*.
- Avoid symptom patches: blanket `try/except`, `?.` everywhere, `# type: ignore`, raising timeouts, `retry` on deterministic failures. If a guard really is the right answer, explain why.
- Keep the fix minimal; refactors go in a separate step.

## 5. Prevent regression

- Add (or keep) the test that failed before the fix and passes after.
- Run the related test suite, not just the single test.
- Search for the same pattern elsewhere: `grep -rn "<pattern>" src/` — same bug often lives in sibling code.

## 6. Report

```
**Root cause:** <1–2 sentences, name file:line>
**Evidence:** <what proves it — output, a test>
**Fix:** <what changed and why there>
**Prevention:** <test added / similar patterns found>
```

Write the report in the user's language (for example, Indonesian if they wrote in Indonesian); translate the headings too.

Wersje

W bazie nie ma innych skilli o nazwie debug-root-cause.

Migawka bazy z 13.11.2026 · wersja paczki a5c684ed7f9b (skrót SHA-256 całej paczki)

Pobrania w ostatnich 30 dniach: 0 · ranking

Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.

Podobne skille

  • 100debug-detective
    Szuka przyczyny błędu, awarii lub nieudanego testu na podstawie stack trace'u i naprawia ją u źródła.
  • 100systematic-debugging
    Szuka przyczyny awarii, nieudanego testu lub złego działania przed jakąkolwiek zmianą, zamiast zgadywać poprawki.
  • 90Debug
    Tropi błąd do przyczyny źródłowej powtarzalną pętlą zamiast zgadywania: dla testów, awarii, zepsutego UI i niestabilnych zachowań.
  • 92debug
    Szuka przyczyny źródłowej błędu przed poprawką, także wtedy, gdy poprawka wydaje się oczywista.
  • 100systematic-debugging
    Szuka przyczyny błędów, awarii, niestabilnych testów i incydentów produkcyjnych przez odtwarzanie i testowanie jednej zmiany naraz.
  • 100systematic-debugging
    Szuka przyczyny awarii, błędu lub złego wyniku na podstawie dowodów i zapisuje poprawkę w pamięci.

Uwagi i zgłoszenia

Wiadomość trafi do Bartosza Sokolińskiego. Adres e-mail jest potrzebny tylko do odpowiedzi. Szczegóły w polityce prywatności.