Дом
Структурированный сеанс отладки — воспроизведение, изолирование, диагностика и устранение неполадок. Начинать следует с сообщения об ошибке или трассировки стека, фраз типа «это работает на тестовой среде, но не на производственной», «что-то сломалось после развертывания» или в тех случаях, когда поведение отличается от ожидаемого, а причина не очевидна.
...Расширить всеО debug
Скилл « debug » предназначен для сопровождения пользователей по структурированному рабочему процессу устранения ошибок ( debug) в случаях, когда поведение программного обеспечения является некорректным, непонятным или наблюдается регрессия. Он предназначен для ситуаций, когда сообщение об ошибке, трассировка стека или неожиданное поведение указывают на проблему, которую невозможно диагностировать сразу. Разбивая процесс устранения неполадок ( debug) на четкие этапы, он помогает пользователям систематически продвигаться от наблюдения за симптомами к выявлению первопричины, а не полагаться на догадки.
Этот навык следует четырехэтапной методологии: воспроизведение, изоляция, диагностика и исправление. На этапе воспроизведения основное внимание уделяется выяснению разницы между ожидаемым и фактическим поведением, а также определению надежных шагов для воспроизведения проблемы. На этапе изоляции круг затронутых компонентов сужается путем анализа недавних изменений, таких как развертывания, обновления конфигурации или изменения зависимостей, а также анализа журналов и сообщений об ошибках. На этапе диагностики процесс делает акцент на формировании и проверке гипотез, отслеживании путей выполнения и выявлении коренной причины, а не поверхностных симптомов. Наконец, этап устранения направлен на предложение корректирующих изменений с учётом побочных эффектов и рекомендацию профилактических тестов для предотвращения регрессий.
Этот навык в первую очередь предназначен для разработчиков, инженеров DevOps, тестировщиков QA и инженеров по надежности систем, которые регулярно устраняют проблемы в производственной среде и на этапе разработки. Он особенно полезен в таких сценариях, как регрессии при развертывании, ошибки, специфичные для конкретной среды (например, различия между тестовой и производственной средами), или необъяснимые сбои после недавних изменений. Внедрение дисциплинированной структуры « debug» позволяет сократить количество действий методом проб и ошибок debugи повысить согласованность рабочих процессов устранения инцидентов.
Часто задаваемые вопросы
Какую информацию нужно предоставить для использования этого навыка debugging?
Вам следует предоставить сообщение об ошибке, трассировку стека, описание непредвиденного поведения, шаги для воспроизведения или контекст, например, недавние изменения или журналы. Чем точнее информация, тем эффективнее будет процесс debugging.
Требует ли этот навык доступа к внешним инструментам или коннекторам?
Он может опционально использовать доступные коннекторы, такие как системы мониторинга, системы управления версиями или инструменты отслеживания проектов, если они подключены. Однако он может работать и только на основе предоставленного описания, журналов и контекста.
Для решения каких проблем этот навык не подходит?
Он не предназначен для ответов на чисто теоретические вопросы или общих объяснений. Он специально ориентирован на диагностику и устранение конкретных проблем с программным обеспечением, сопровождающихся наблюдаемым некорректным поведением.
/debug
If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md.
Run a structured debugging session to find and fix issues systematically.
Usage
/debug $ARGUMENTSHow It Works
┌─────────────────────────────────────────────────────────────────┐│ DEBUG │├─────────────────────────────────────────────────────────────────┤│ Step 1: REPRODUCE ││ ✓ Understand the expected vs. actual behavior ││ ✓ Identify exact reproduction steps ││ ✓ Determine scope (when did it start? who is affected?) ││ ││ Step 2: ISOLATE ││ ✓ Narrow down the component, service, or code path ││ ✓ Check recent changes (deploys, config changes, dependencies) ││ ✓ Review logs and error messages ││ ││ Step 3: DIAGNOSE ││ ✓ Form hypotheses and test them ││ ✓ Trace the code path ││ ✓ Identify root cause (not just symptoms) ││ ││ Step 4: FIX ││ ✓ Propose a fix with explanation ││ ✓ Consider side effects and edge cases ││ ✓ Suggest tests to prevent regression │└─────────────────────────────────────────────────────────────────┘What I Need From You
Tell me about the problem. Any of these help:
- Error message or stack trace
- Steps to reproduce
- What changed recently
- Logs or screenshots
- Expected vs. actual behavior
Output
## Debug Report: [Issue Summary]### Reproduction- **Expected**: [What should happen]- **Actual**: [What happens instead]- **Steps**: [How to reproduce]### Root Cause[Explanation of why the bug occurs]### Fix[Code changes or configuration fixes needed]### Prevention- [Test to add]- [Guard to put in place]
If Connectors Available
If ~~monitoring is connected:
- Pull logs, error rates, and metrics around the time of the issue
- Show recent deploys and config changes that may correlate
If ~~source control is connected:
- Identify recent commits and PRs that touched affected code paths
- Check if the issue correlates with a specific change
If ~~project tracker is connected:
- Search for related bug reports or known issues
- Create a ticket for the fix once identified
Tips
- Share error messages exactly — Don't paraphrase. The exact text matters.
- Mention what changed — Recent deploys, dependency updates, and config changes are top suspects.
- Include context — "This works in staging but not prod" or "Only affects large payloads" narrows things fast.
Установить debug
Скачайте файлы навыков и распакуйте их в каталог .claude/skills/.
Скачать ZIPКлонируйте репозиторий и скопируйте файлы навыка в свой проект.
git clone https://github.com/anthropics/knowledge-work-plugins/blob/main/engineering/skills/debug/SKILL.md # Copy SKILL.md to your .claude/skills/ directory
Копировать
