Навыки systematic-debugging
🔍

systematic-debugging

Безопасно ⚡ Содержит скрипты📁 Доступ к файловой системе

Применение систематической отладки для любых ошибок

Также доступно от: Cycleaddict,DMJGilbert,Doyajin174,obra,Asmayaseen,DYAI2025,ChrisWiles,davila7,CodingCossack

Случайные исправления тратят время и создают новые ошибки. Этот навык предоставляет четырёхфазную методологию для поиска первопричины перед попыткой исправления. Он предотвращает исправление симптомов и обеспечивает долговременные решения.

Поддерживает: Claude Codex Code(CC)
📊 70 Адекватно
1

Скачать ZIP навыка

2

Загрузить в Claude

Перейдите в Settings → Capabilities → Skills → Upload skill

3

Включите и начните использовать

Протестировать

Использование «systematic-debugging». Тест падает с ошибкой 'Expected status completed but received pending'

Ожидаемый результат:

  • Фаза 1 - Первопричина: Отследить, когда устанавливается статус и когда мы его проверяем
  • Фаза 2 - Паттерн: Найти работающие тесты, которые проверяют обновления статуса
  • Фаза 3 - Гипотеза: Возможно, асинхронная операция не ожидается перед проверкой
  • Фаза 4 - Реализация: Добавить условие waitFor для обнаружения фактического изменения состояния

Использование «systematic-debugging». Файл создаётся не в той директории во время тестов

Ожидаемый результат:

  • Фаза 1 - Первопричина: Использовать find-polluter.sh для определения, какой тест создаёт файл
  • Фаза 2 - Паттерн: Сравнить с тестами, которые выполняются чисто
  • Фаза 3 - Гипотеза: Пустая переменная пути разрешается в cwd
  • Фаза 4 - Реализация: Добавить уровень валидации, который отклоняет операции вне tmpdir

Использование «systematic-debugging». Секреты окружения не доходят до уровня сборки

Ожидаемый результат:

  • Фаза 1 - Доказательства: Логировать переменные окружения на каждом уровне (workflow, build, signing)
  • Фаза 2 - Паттерн: Найти, где прерывается распространение
  • Фаза 3 - Гипотеза: Переход между уровнями удаляет окружение
  • Фаза 4 - Реализация: Добавить эшелонированную проверку на каждой границе уровня

Аудит безопасности

Безопасно
v5 • 1/17/2026

This is a legitimate debugging methodology skill containing only documentation and code examples. All 138 static findings are FALSE POSITIVES. The flagged patterns are markdown documentation showing example debugging commands, shell variable expansion, environment checks, and standard filesystem operations - all used for legitimate debugging documentation purposes. No malicious code or intent present.

12
Просканировано файлов
1,489
Проанализировано строк
2
находки
5
Всего аудитов

Факторы риска

⚡ Содержит скрипты (1)
📁 Доступ к файловой системе (1)

Оценка качества

38
Архитектура
100
Сопровождаемость
87
Контент
22
Сообщество
100
Безопасность
91
Соответствие спецификации

Что вы можете построить

Правильное исправление падающих тестов

Прекратите добавлять операторы sleep. Отслеживайте причину падения тестов у источника для постоянных исправлений.

Избегание исправления симптомов

Следуйте документированному процессу вместо угадывания исправлений при столкновении с неожиданным поведением.

Отслеживание сложных стеков вызовов

Находите источник невалидных данных в многокомпонентных системах с помощью проверенных техник трассировки.

Попробуйте эти промпты

Базовое исследование ошибки
Load skills/debugging/systematic-debugging and help me investigate this test failure. The test expects X but received Y.
Отладка многоуровневой системы
Use the root cause tracing technique to trace this bug backward through the call chain. The error appears at line N.
Паттерн нестабильного теста
Apply the condition-based waiting pattern to replace arbitrary timeouts in this test file.
Предотвращение исправления симптомов
Check my work against the systematic debugging process. Have I actually found the root cause?

Лучшие практики

  • Всегда завершайте Фазу 1 (первопричина) перед предложением любого исправления, даже под давлением времени
  • Отслеживайте назад по цепочке вызовов, чтобы найти, где возникли неверные данные, а не где они проявляются
  • Добавляйте валидацию на каждом уровне прохождения данных, чтобы сделать ошибки структурно невозможными

Избегать

  • Добавление операторов sleep вместо ожидания фактических условий
  • Исправление там, где проявляется ошибка, вместо трассировки к источнику
  • Предложение нескольких исправлений одновременно для 'большего охвата'

Часто задаваемые вопросы

Могу ли я перейти сразу к исправлению, если проблема кажется очевидной?
Нет. Навык требует завершения Фазы 1 перед любым исправлением. У простых ошибок тоже есть первопричины. Систематический подход быстрее, чем хаотичные попытки.
Что делать, если я недостаточно хорошо понимаю кодовую базу для отслеживания первопричины?
Скажите 'Я не понимаю X' вместо угадывания. Попросите помощи или проведите больше исследований. Навык явно ценит честность выше притворства.
Как справляться с производственными чрезвычайными ситуациями с этим навыком?
Навык признаёт давление, но требует сначала провести исследование. Быстрые исправления маскируют проблемы, которые повторяются. Систематическая отладка справляется с чрезвычайными ситуациями быстрее, чем игра в 'ударь крота' с симптомами.
Когда следует использовать ожидание на основе условий?
Заменяйте произвольные вызовы sleep или timeout опросом фактического условия. Это устраняет нестабильные тесты, которые проходят на быстрых машинах, но падают в CI.
Что делать, если три исправления уже не сработали?
Остановитесь и поставьте архитектуру под вопрос. Три неудачных исправления часто указывают на структурную проблему, а не на симптом для латания. Обсудите это с вашим человеком-партнёром.
Чем это отличается от разработки через тестирование?
TDD пишет тесты перед кодом. Этот навык исследует ошибки, когда они происходят. Оба требуют понимания первопричины, но служат разным фазам разработки.

Сведения для разработчиков

Автор

Cygnusfear

Лицензия

MIT

Ссылка

main