Системная отладка
Этот skill нужен для случаев, когда проблема еще не локализована и есть риск начать угадывать решение по симптомам. Главный принцип: сначала root cause, потом fix.
Когда использовать
Используй skill, если:
- падают тесты и причина еще не доказана;
- есть баг или неожиданное поведение;
- сломалась интеграция между несколькими слоями;
- предыдущая попытка fix не сработала;
- проблема кажется "очевидной", но evidence еще не собран.
Базовый workflow
- Сформулируй наблюдаемый симптом без догадок.
- Зафиксируй reproduction command, exit code и ключевой observed output.
- Добейся воспроизводимости или зафиксируй, что она пока неполная.
- Проверь недавние изменения, конфиг и окружение.
- Собери evidence по границам компонентов и потоку данных.
- Сформулируй одну проверяемую гипотезу root cause.
- Проверь гипотезу минимальным изменением или диагностикой.
- Только после подтверждения причины переходи к исправлению.
- Добавь 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 и шаблон проверки гипотез
Формат ответа
Когда просят расследовать проблему, возвращай:
- Наблюдаемый симптом и текущую воспроизводимость.
- Reproduction command, exit code и ключевой output.
- Какие evidence уже собраны.
- Вероятный слой или границу, где ломается система.
- Основную гипотезу root cause и способ ее проверки.
- Что нужно проверить дальше до реального fix.
Связь с другими skills
Если задача еще не про root cause, а про поиск новых багов, скрытых ограничений и расширение failure surface через системный fuzzing, используй fuzzing-bug-hunter.
Если после расследования нужно превратить уже доказанный дефект в стабильный regression test, используй autotest-engineer.
Если причина зависит от external API/framework behavior, используй source-driven-development.
1---2name: systematic-debugging3description: Доказывать root cause багов, падений тестов и многослойных сбоев через reproduction и evidence; not support triage or workaround selection.4---56# Системная отладка78Этот skill нужен для случаев, когда проблема еще не локализована и есть риск начать угадывать решение по симптомам. Главный принцип: сначала root cause, потом fix.910## Когда использовать1112Используй skill, если:1314- падают тесты и причина еще не доказана;15- есть баг или неожиданное поведение;16- сломалась интеграция между несколькими слоями;17- предыдущая попытка fix не сработала;18- проблема кажется "очевидной", но evidence еще не собран.1920## Базовый workflow21221. Сформулируй наблюдаемый симптом без догадок.232. Зафиксируй reproduction command, exit code и ключевой observed output.243. Добейся воспроизводимости или зафиксируй, что она пока неполная.254. Проверь недавние изменения, конфиг и окружение.265. Собери evidence по границам компонентов и потоку данных.276. Сформулируй одну проверяемую гипотезу root cause.287. Проверь гипотезу минимальным изменением или диагностикой.298. Только после подтверждения причины переходи к исправлению.309. Добавь guard против повторения: regression test, assertion, monitor, log или documented operational check.3132## Ключевые правила3334- Не предлагай fix, пока не собран достаточный evidence о причине.35- Не начинай с правки кода, если нет reproduction command или явной причины, почему воспроизведение невозможно.36- Не смешивай несколько гипотез в одну правку.37- Stop-the-line: unexpected failure нельзя обходить, если он может менять вывод о correctness.38- Для многослойных систем логируй вход и выход на каждой границе, а не только место падения.39- Если уже было несколько неудачных fix-попыток, пересмотри саму архитектурную гипотезу, а не продолжай наращивать патчи.40- При глубоком стеке вызовов ищи источник плохого значения вверх по цепочке, а не лечи последнее место, где оно проявилось.41- Для внешних инструментов, CLI и API проверяй версию и official source через `source-driven-development`.4243## Карта reference-файлов4445- `references/root-cause-investigation.md` -> подробная техника расследования, работа с multi-component systems и шаблон проверки гипотез4647## Формат ответа4849Когда просят расследовать проблему, возвращай:50511. Наблюдаемый симптом и текущую воспроизводимость.522. Reproduction command, exit code и ключевой output.533. Какие evidence уже собраны.544. Вероятный слой или границу, где ломается система.555. Основную гипотезу root cause и способ ее проверки.566. Что нужно проверить дальше до реального fix.5758## Связь с другими skills5960Если задача еще не про root cause, а про поиск новых багов, скрытых ограничений и расширение failure surface через системный fuzzing, используй `fuzzing-bug-hunter`.6162Если после расследования нужно превратить уже доказанный дефект в стабильный regression test, используй `autotest-engineer`.6364Если причина зависит от external API/framework behavior, используй `source-driven-development`.
Maslennikov-Anton