Diagnose

Skill Avalon-27reg/smyslokod-starter/.claude/skills/diagnose

Стек-агностичный шаблон смысло-кодинга для Claude Code: бизнес-контекст в business/, планы фич, ретроспективы, правила и готовые промпты. Стек выбираешь на старте.

Install

npx -y skills add Avalon-27reg/smyslokod-starter --skill diagnose

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use this when the user reports a bug, regression, or "что-то не работает" / "это сломалось" / "почему упало". Drives a systematic debugging cycle instead of guessing fixes. Skip for syntax errors and obvious typos.

SKILL.md

5.2 KB, as published. Nobody here has run it

Skill: diagnose

Систематический цикл отладки. Без него легко «починить» симптом, не тронув причину.

Когда применять

Любое из:

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

Когда НЕ применять

Очевидная опечатка / синтаксическая ошибка — сразу чини.
Пользователь сам уже назвал причину и просит конкретную правку.
Задача — добавить фичу, баги нет.

Цикл диагностики (5 шагов)

Делай по одному шагу за раз. Не перепрыгивай.

1. Воспроизведение

Сначала — стабильный repro. Не по слухам, не «иногда».

Какие точные шаги приводят к багу?
Какие данные / окружение нужны?
Если репорт устный — попроси пользователя дать минимальный сценарий.
Запиши repro в комментарий или в plans/<...>.md блок «Контекст».

Если repro нет — остановись. Без repro отладка превращается в гадание.

2. Минимизация

Урезаем repro до минимума.

Убрать всё, что не нужно для проявления бага.
Если баг в форме — попробовать с одним полем.
Если в API — попробовать минимальным payload.
Если в UI — попробовать без стилей / без обёрток.

Цель: 5–20 строк, которые ломаются. Маленький repro = быстрый цикл проверки гипотез.

3. Гипотеза

Одна конкретная гипотеза. Не «может быть тут или там».

«Я думаю это X, потому что Y».
Проверка: какой эксперимент опровергнет / подтвердит её за 1–2 минуты?

Если гипотез несколько — расставь по приоритету. Проверяй по одной.

4. Инструментирование

Перед правкой — увидеть проблему.

console.log / print / отладчик / breakpoint.
Логировать значения в точке, где ожидается одно, а получается другое.
Если баг в проде — посмотреть Sentry / логи хостинга.
Не правь «вслепую». Если не видишь причину — добавь логирование, повтори repro, посмотри.

5. Исправление

Только после подтверждённой гипотезы.

Минимальная правка, которая чинит причину (не симптом).
Пишем тест, который ловит этот баг (если применимо).
Прогоняем repro — должно работать.
Прогоняем соседние сценарии — не сломалось ли что-то рядом (Impact Analysis в миниатюре).
Убираем добавленные console.log.

Что вернуть пользователю

После исправления — короткий отчёт:

Симптом: что наблюдалось.
Причина: что на самом деле было сломано (одно предложение).
Правка: какой файл / строки изменились (через path:line).
Проверка: как убедились что починили (repro теперь зелёный).
Регрессия-чек: что рядом проверили на предмет «не сломалось ли».

Антипаттерны

«Попробую переустановить зависимости» без понимания причины.
«Закомментирую код, который выкидывает ошибку» — это не починка.
«Добавлю try/catch для тишины» — это не починка.
Пять правок одной кнопкой «может теперь сработает».
Чинить симптом и не написать тест.