Навыки systematic-debugging

🔍

systematic-debugging

Name: systematic-debugging
Author: ZhanlinCui

Низкий риск ⚙️ Внешние команды

Отлаживайте систематически, чтобы найти первопричины перед исправлением

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

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

Поддерживает: Claude Codex Code(CC)

🥉 72 Бронза

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

Загрузить в Claude

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

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

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

Использование «systematic-debugging». Тест падает с ошибкой git init в неправильной директории

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

Фаза 1 — Расследование первопричины:
1. Ошибка показывает запуск git init в /source/code вместо /tmp
2. Трассировка назад: git init <- WorktreeManager <- Session.create <- test
3. Найдено: projectDir была пустой строкой, разрешена в process.cwd()
4. Первопричина: тест обращался к context.tempDir до инициализации beforeEach
Первопричина определена: проблема порядка инициализации переменных

Использование «systematic-debugging». Нестабильный тест, который иногда пропускает результаты инструментов

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

Диагноз: Тест использует произвольные ожидания setTimeout вместо проверки условий
Решение: Заменить таймауты на ожидание по условию
ДО: await new Promise(r => setTimeout(r, 300))
ПОСЛЕ: await waitForEventCount(threadManager, id, 'TOOL_RESULT', 2)
Результат: процент успешных прохождений улучшен с 60% до 100%

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

Низкий риск

v1 • 2/24/2026

Static analyzer flagged 126 patterns but 125 are false positives from markdown documentation (backticks are code formatting, not shell execution). One legitimate shell script (find-polluter.sh) uses npm test for test debugging - acceptable for a debugging skill. No cryptographic code exists despite scanner claims. Skill teaches debugging methodology safely.

Просканировано файлов

1,262

Проанализировано строк

находки

Всего аудитов

Проблемы низкого риска (1)

find-polluter.sh:42

Shell Script for Test Debugging

find-polluter.sh executes npm test commands to identify which test creates unwanted files or state. This is legitimate test infrastructure for a debugging skill.

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

⚙️ Внешние команды (1)

find-polluter.sh:42

Проверено: claude

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

Архитектура

100

Сопровождаемость

Контент

Сообщество

Безопасность

Соответствие спецификации

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

Расследование сбоев тестов

Когда тесты падают периодически или неожиданно, используйте этот навык для систематической трассировки сбоя к первопричине вместо применения быстрых исправлений.

Устранение ошибок в продакшене

Когда ошибки появляются в продакшене, следуйте четырёхфазному процессу для понимания первопричины перед развёртыванием исправлений, которые могут создать новые проблемы.

Отладка многокомпонентных систем

При отладке сложных систем с множеством слоёв используйте диагностику глубинной обороны для точной идентификации компонента, который выходит из строя.

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

Базовое расследование ошибки

Я вижу эту ошибку: [вставьте ошибку]. Я хочу исправить её быстро, но знаю, что сначала нужно расследовать. Помогите мне следовать Фазе 1 систематической отладки для понимания первопричины перед предложением любых исправлений.

Отладка нестабильных тестов

Этот тест падает периодически: [вставьте тест]. Иногда проходит, иногда падает. Направьте меня через систематическую отладку для поиска причины нестабильности, включая добавление диагностической инструментации.

Сбой в многослойной системе

Моя система имеет [опишите слои: например, CI workflow, скрипт сборки, процесс подписания]. Что-то ломается, но я не знаю, какой слой. Покажите, как добавить инструментацию сбора доказательств на каждой границе для изоляции неисправного компонента.

Восстановление после неудачного исправления

Я уже попробовал [N] исправлений, и ни одно не сработало. Каждое исправление выявляло новую проблему. Помогите мне остановиться и подвергнуть сомнению, есть ли архитектурная проблема, перед попыткой очередного исправления. Направьте меня через повторный анализ с Фазы 1.

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

Всегда завершайте расследование Фазы 1 перед предложением любого исправления — понимание первопричины быстрее, чем метание со случайными исправлениями
Трассируйте ошибки назад через стек вызовов для поиска оригинального триггера, а не только места появления ошибки
После 3 неудачных попыток исправления остановитесь и подвергните сомнению архитектуру вместо продолжения исправлений симптомов

Избегать

Предложение исправлений до завершения расследования первопричины — это лечит симптомы, а не причины
Внесение множественных изменений одновременно — вы не можете изолировать, что сработало, и можете внедрить новые ошибки
Пропуск создания падающего теста — непроверенные исправления не держатся, и регрессии остаются незамеченными

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

Разве систематическая отладка не медленнее, чем просто пробовать быстрые исправления?

Нет. Исследования из реальных сессий показывают, что систематическая отладка занимает 15-30 минут против 2-3 часов метания со случайными исправлениями. Процент успешных исправлений с первого раза — 95% против 40%.

Что делать, если у меня чрезвычайная ситуация и нужно исправление сейчас?

Чрезвычайные ситуации делают догадки заманчивыми, но систематический подход всё равно быстрее. Спешка гарантирует переделку. Процесс спроектирован так, чтобы противостоять рационализации временным давлением.

Как узнать, что я нашёл настоящую первопричину?

Вы можете трассировать полную цепочку от симптома назад к источнику. Если вы исправляете в источнике и добавляете валидацию на каждом слое, ошибка становится невозможной.

Что делать, если моя первая гипотеза неверна?

Это ожидаемо. Сформулируйте единственную гипотезу, протестируйте её минимально, и если она не подтвердится, вернитесь к Фазе 1 с новой информацией. Никогда не добавляйте больше исправлений поверх неудачных.

Когда стоит подвергнуть сомнению архитектуру вместо продолжения отладки?

После 3 неудачных попыток исправления, когда каждая выявляет новые проблемы в разных местах, остановитесь. Это указывает на архитектурные проблемы, а не просто на ошибки. Обсудите рефакторинг перед дальнейшими исправлениями.

Работает ли это для не-кодовых ошибок, таких как проблемы конфигурации?

Да. Четырёхфазный процесс применим к любой технической проблеме: воспроизведение, сбор доказательств, трассировка потока данных, идентификация отличий от работающих конфигураций.