# Systematic Debugging

> Доказывать root cause багов, падений тестов и многослойных сбоев через reproduction и evidence; not support triage or workaround selection.

- Skill: `maslennikov-anton/systematic-debugging` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add maslennikov-anton/systematic-debugging`
- Raw SKILL.md: https://api.skillmd.com/api/skills/maslennikov-anton/systematic-debugging/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Maslennikov-Anton (https://skillmd.com/u/maslennikov-anton)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/maslennikov-anton/systematic-debugging

---


# Системная отладка

Этот skill нужен для случаев, когда проблема еще не локализована и есть риск начать угадывать решение по симптомам. Главный принцип: сначала root cause, потом fix.

## Когда использовать

Используй skill, если:

- падают тесты и причина еще не доказана;
- есть баг или неожиданное поведение;
- сломалась интеграция между несколькими слоями;
- предыдущая попытка fix не сработала;
- проблема кажется "очевидной", но evidence еще не собран.

## Базовый workflow

1. Сформулируй наблюдаемый симптом без догадок.
2. Зафиксируй reproduction command, exit code и ключевой observed output.
3. Добейся воспроизводимости или зафиксируй, что она пока неполная.
4. Проверь недавние изменения, конфиг и окружение.
5. Собери evidence по границам компонентов и потоку данных.
6. Сформулируй одну проверяемую гипотезу root cause.
7. Проверь гипотезу минимальным изменением или диагностикой.
8. Только после подтверждения причины переходи к исправлению.
9. Добавь guard против повторения: regression test, assertion, monitor, log или documented operational check.

## Ключевые правила

- Не предлагай fix, пока не собран достаточный evidence о причине.
- Не начинай с правки кода, если нет reproduction command или явной причины, почему воспроизведение невозможно.
- Не смешивай несколько гипотез в одну правку.
- Stop-the-line: unexpected failure нельзя обходить, если он может менять вывод о correctness.
- Для многослойных систем логируй вход и выход на каждой границе, а не только место падения.
- Если уже было несколько неудачных fix-попыток, пересмотри саму архитектурную гипотезу, а не продолжай наращивать патчи.
- При глубоком стеке вызовов ищи источник плохого значения вверх по цепочке, а не лечи последнее место, где оно проявилось.
- Для внешних инструментов, CLI и API проверяй версию и official source через `source-driven-development`.

## Карта reference-файлов

- `references/root-cause-investigation.md` -> подробная техника расследования, работа с multi-component systems и шаблон проверки гипотез

## Формат ответа

Когда просят расследовать проблему, возвращай:

1. Наблюдаемый симптом и текущую воспроизводимость.
2. Reproduction command, exit code и ключевой output.
3. Какие evidence уже собраны.
4. Вероятный слой или границу, где ломается система.
5. Основную гипотезу root cause и способ ее проверки.
6. Что нужно проверить дальше до реального fix.

## Связь с другими skills

Если задача еще не про root cause, а про поиск новых багов, скрытых ограничений и расширение failure surface через системный fuzzing, используй `fuzzing-bug-hunter`.

Если после расследования нужно превратить уже доказанный дефект в стабильный regression test, используй `autotest-engineer`.

Если причина зависит от external API/framework behavior, используй `source-driven-development`.