Поиск и исправление ошибок

Шаг за шагом воспроизводит сбой, находит первопричину и предлагает исправление и тесты.

СкиллAnthropicClaudeApache-2.0Нужен терминалПроверка не требуется

Скачать на русскомОригинал на английском (архив)Источник ↗

Что делает: Шаг за шагом воспроизводит сбой, находит первопричину и предлагает исправление и тесты.
Когда брать: Когда есть сообщение об ошибке или после выкладки что-то сломалось, а причина неясна.
Пример запроса: После вчерашней выкладки оплата падает с ошибкой 500, вот текст ошибки. Найди причину.

Входит в плагин engineering. В Cowork и Claude Code можно поставить плагин целиком.

Как включить

Скачайте архив и распакуйте его.
Положите папку debug в ~/.claude/skills/.
Откройте Claude Code и опишите задачу своими словами: Claude подхватит скилл по описанию.

Текст

---
name: debug
description: Структурированная отладка — воспроизвести, изолировать, диагностировать и исправить. Запускай, когда дали сообщение об ошибке или трассировку стека, при фразах «на стенде работает, а в проде нет», «после выкладки что-то сломалось», а также когда поведение расходится с ожидаемым и причина неочевидна.
argument-hint: "<error message or problem description>"
---

/debug

Если встретишь незнакомые подстановки или нужно узнать, какие инструменты подключены, смотри [CONNECTORS.md](../../CONNECTORS.md).

Проведи структурированную отладку, чтобы системно найти и исправить проблемы.

Использование

/debug $ARGUMENTS

Как это работает

┌─────────────────────────────────────────────────────────────────┐
│                       ОТЛАДКА                                   │
├─────────────────────────────────────────────────────────────────┤
│  Шаг 1: ВОСПРОИЗВЕДЕНИЕ                                         │
│  ✓ Понять ожидаемое и фактическое поведение                     │
│  ✓ Определить точные шаги воспроизведения                       │
│  ✓ Определить масштаб (когда началось? кого затронуло?)         │
│                                                                 │
│  Шаг 2: ИЗОЛЯЦИЯ                                                │
│  ✓ Сузить круг: компонент, сервис или путь выполнения кода      │
│  ✓ Проверить недавние изменения (выкладки, настройки, пакеты)   │
│  ✓ Просмотреть логи и сообщения об ошибках                      │
│                                                                 │
│  Шаг 3: ДИАГНОСТИКА                                             │
│  ✓ Выдвинуть гипотезы и проверить их                            │
│  ✓ Проследить путь выполнения кода                              │
│  ✓ Найти первопричину (а не только симптомы)                    │
│                                                                 │
│  Шаг 4: ИСПРАВЛЕНИЕ                                             │
│  ✓ Предложить исправление с объяснением                         │
│  ✓ Учесть побочные эффекты и граничные случаи                   │
│  ✓ Предложить тесты, чтобы ошибка не вернулась                  │
└─────────────────────────────────────────────────────────────────┘

Что мне нужно от тебя

Расскажи о проблеме. Подойдёт что угодно из этого:

Сообщение об ошибке или трассировка стека
Шаги воспроизведения
Что менялось в последнее время
Логи или скриншоты
Ожидаемое и фактическое поведение

Результат

## Отчёт об отладке: [суть проблемы]

### Воспроизведение
- **Ожидалось**: [Что должно происходить]
- **Фактически**: [Что происходит на самом деле]
- **Шаги**: [Как воспроизвести]

### Первопричина
[Объяснение, почему возникает ошибка]

### Исправление
[Нужные изменения кода или настроек]

### Профилактика
- [Какой тест добавить]
- [Какую защиту поставить]

Если подключены коннекторы

Если подключён ~~monitoring:

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

Если подключён ~~source control:

Найди недавние коммиты и PR, которые затрагивали проблемные участки кода
Проверь, связана ли проблема с конкретным изменением

Если подключён ~~project tracker:

Поищи связанные отчёты об ошибках и известные проблемы
Создай тикет на исправление, когда причина найдена

Советы

Присылай сообщения об ошибках дословно — не пересказывай. Точный текст важен.
Расскажи, что менялось — недавние выкладки, обновления зависимостей и изменения настроек — главные подозреваемые.
Добавь контекст — «на стенде работает, в проде нет» или «затрагивает только большие запросы» быстро сужает поиск.

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/knowledge-work-plugins/tree/main/engineering/skills/debug, лицензия Apache-2.0. Изменения: перевод на русский язык.

Оригинал на английском

---
name: debug
description: Structured debugging session — reproduce, isolate, diagnose, and fix. Trigger with an error message or stack trace, "this works in staging but not prod", "something broke after the deploy", or when behavior diverges from expected and the cause isn't obvious.
argument-hint: "<error message or problem description>"
---

# /debug

> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).

Run a structured debugging session to find and fix issues systematically.

## Usage

```
/debug $ARGUMENTS
```

## How 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

```markdown
## 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

1. **Share error messages exactly** — Don't paraphrase. The exact text matters.
2. **Mention what changed** — Recent deploys, dependency updates, and config changes are top suspects.
3. **Include context** — "This works in staging but not prod" or "Only affects large payloads" narrows things fast.

Источник: anthropics/knowledge-work-plugins / engineering / debug ↗. Ссылка проверена 2026-10-10.

---
name: debug
description: Структурированная отладка — воспроизвести, изолировать, диагностировать и исправить. Запускай, когда дали сообщение об ошибке или трассировку стека, при фразах «на стенде работает, а в проде нет», «после выкладки что-то сломалось», а также когда поведение расходится с ожидаемым и причина неочевидна.
argument-hint: "<error message or problem description>"
---

# /debug

> Если встретишь незнакомые подстановки или нужно узнать, какие инструменты подключены, смотри [CONNECTORS.md](../../CONNECTORS.md).

Проведи структурированную отладку, чтобы системно найти и исправить проблемы.

## Использование

```
/debug $ARGUMENTS
```

## Как это работает

```
┌─────────────────────────────────────────────────────────────────┐
│                       ОТЛАДКА                                   │
├─────────────────────────────────────────────────────────────────┤
│  Шаг 1: ВОСПРОИЗВЕДЕНИЕ                                         │
│  ✓ Понять ожидаемое и фактическое поведение                     │
│  ✓ Определить точные шаги воспроизведения                       │
│  ✓ Определить масштаб (когда началось? кого затронуло?)         │
│                                                                 │
│  Шаг 2: ИЗОЛЯЦИЯ                                                │
│  ✓ Сузить круг: компонент, сервис или путь выполнения кода      │
│  ✓ Проверить недавние изменения (выкладки, настройки, пакеты)   │
│  ✓ Просмотреть логи и сообщения об ошибках                      │
│                                                                 │
│  Шаг 3: ДИАГНОСТИКА                                             │
│  ✓ Выдвинуть гипотезы и проверить их                            │
│  ✓ Проследить путь выполнения кода                              │
│  ✓ Найти первопричину (а не только симптомы)                    │
│                                                                 │
│  Шаг 4: ИСПРАВЛЕНИЕ                                             │
│  ✓ Предложить исправление с объяснением                         │
│  ✓ Учесть побочные эффекты и граничные случаи                   │
│  ✓ Предложить тесты, чтобы ошибка не вернулась                  │
└─────────────────────────────────────────────────────────────────┘
```

## Что мне нужно от тебя

Расскажи о проблеме. Подойдёт что угодно из этого:
- Сообщение об ошибке или трассировка стека
- Шаги воспроизведения
- Что менялось в последнее время
- Логи или скриншоты
- Ожидаемое и фактическое поведение

## Результат

```markdown
## Отчёт об отладке: [суть проблемы]

### Воспроизведение
- **Ожидалось**: [Что должно происходить]
- **Фактически**: [Что происходит на самом деле]
- **Шаги**: [Как воспроизвести]

### Первопричина
[Объяснение, почему возникает ошибка]

### Исправление
[Нужные изменения кода или настроек]

### Профилактика
- [Какой тест добавить]
- [Какую защиту поставить]
```

## Если подключены коннекторы

Если подключён **~~monitoring**:
- Подтяни логи, долю ошибок и метрики за время, когда возникла проблема
- Покажи недавние выкладки и изменения настроек, которые могут быть связаны с ней

Если подключён **~~source control**:
- Найди недавние коммиты и PR, которые затрагивали проблемные участки кода
- Проверь, связана ли проблема с конкретным изменением

Если подключён **~~project tracker**:
- Поищи связанные отчёты об ошибках и известные проблемы
- Создай тикет на исправление, когда причина найдена

## Советы

1. **Присылай сообщения об ошибках дословно** — не пересказывай. Точный текст важен.
2. **Расскажи, что менялось** — недавние выкладки, обновления зависимостей и изменения настроек — главные подозреваемые.
3. **Добавь контекст** — «на стенде работает, в проде нет» или «затрагивает только большие запросы» быстро сужает поиск.

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/knowledge-work-plugins/tree/main/engineering/skills/debug, лицензия Apache-2.0. Изменения: перевод на русский язык.