# Ru

> Адверсариально проверяет валидность баг-репорта — не оформление, а саму проблему по первоисточникам (код, спека, git history), с попыткой опровергнуть репорт прежде чем подтвердить его. Используй, когда просят проверить/провалидировать/подтвердить баг-репорт, усомниться в баг-репорте, или перед тем как начинать работу над заведённым багом, чтобы убедиться что он реальный, а не галлюцинация агента.

- Skill: `smirnovalex-qa/ru-15` (Agent Skill)
- Install (CLI): `npx skillmds@latest add smirnovalex-qa/ru-15`
- Raw SKILL.md: https://api.skillmd.com/api/skills/smirnovalex-qa/ru-15/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: smirnovalex-qa (https://skillmd.com/u/smirnovalex-qa)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/smirnovalex-qa/ru-15

---

# Верификация валидности баг-репорта

Твоя задача — НЕ проверка оформления, а адверсариальная верификация самой
проблемы. Исходи из презумпции, что репорт может быть галлюцинацией агента
или ложным выводом на основе неполного контекста. Твоя цель — попытаться
ОПРОВЕРГНУТЬ репорт, и только если опровергнуть не удалось — подтвердить его.

## Входные данные

`$ARGUMENTS` — путь к файлу баг-репорта или сам текст репорта.

- Если аргумент похож на путь (`docs/bugs/**`, `*.md`, `*.txt`) — прочитай файл.
- Если это текст репорта, вставленный прямо в сообщение, — используй его как есть.
- Если аргумент пуст — возьми баг-репорт из последнего сообщения пользователя
  в диалоге; если и там его нет, спроси, какой репорт проверить (не выдумывай).

## Порядок работы

1. **Извлеки утверждения.** Разбей репорт на атомарные фактические утверждения:
   - что именно воспроизводится (шаги, входные данные, окружение);
   - какое поведение наблюдается (actual);
   - какое поведение ожидается (expected) и НА ЧЁМ основано это ожидание
     (спека, документация, код, здравый смысл автора репорта?);
   - какая причина/локализация заявлена (если заявлена).

2. **Проверь каждое утверждение независимо, по первоисточникам:**
   - найди в коде реальную реализацию описанного поведения — читай код, а не
     пересказ в репорте; упомянутые файлы/функции/эндпоинты/конфиги должны
     существовать и делать то, что заявлено;
   - проверь, что "ожидаемое поведение" действительно ожидаемо: есть ли
     требование/спека/контракт, или автор репорта сам его придумал;
   - проверь, не является ли поведение намеренным (feature, известное
     ограничение, осознанный trade-off — ищи комментарии, ADR, git log/blame,
     существующие тикеты и доки);
   - проверь, не устарел ли репорт: возможно, проблема уже исправлена в
     текущей ветке.

3. **Воспроизведи проблему.** Если это возможно в текущем окружении — выполни
   шаги воспроизведения (запусти код, тест, запрос, скрипт) и зафиксируй
   фактический результат. Если воспроизвести напрямую нельзя — напиши
   минимальный тест/скрипт, изолирующий заявленное поведение, и прогони его.
   Если воспроизведение невозможно в принципе (нужен прод, внешний сервис,
   специфичные данные) — явно скажи это и оцени проблему только по коду,
   пометив вывод как косвенный.

4. **Проверь выводы, а не только факты.** Даже если наблюдаемое поведение
   реально, заявленная причина может быть неверной. Отдельно оцени:
   наблюдение (симптом) vs интерпретацию (диагноз) — они подтверждаются
   независимо.

## Вердикт

Дай один из вердиктов с обоснованием:

- **ПОДТВЕРЖДЁН** — проблема воспроизведена / однозначно доказана кодом.
  Приложи доказательства: вывод воспроизведения, ссылки на код (file:line).
- **ПОДТВЕРЖДЁН ЧАСТИЧНО** — симптом реален, но причина/масштаб/ожидаемое
  поведение в репорте описаны неверно. Укажи, что именно скорректировать.
- **НЕ ПОДТВЕРЖДЁН** — проблема не воспроизводится или репорт основан на
  ложной посылке. Объясни, откуда взялся ложный вывод (какой контекст
  автор репорта не учёл).
- **НЕДОСТАТОЧНО ДАННЫХ** — перечисли конкретные вопросы/данные, без которых
  верификация невозможна (окружение, версия, входные данные, доступы).

## Требования к ответу

- Каждый вывод — только со ссылкой на доказательство: код (file:line),
  вывод команды, результат теста. Утверждения без доказательств запрещены.
- Если уверенность не 100% — явно укажи степень уверенности и что осталось
  непроверенным.
- НЕ исправляй баг и не меняй код (кроме временных тестов/скриптов для
  воспроизведения — их удали после проверки). Инструменты редактирования
  файлов недоступны этому скиллу намеренно — это read-only аудит.
- Если репорт частично неверен — сформулируй уточнения/правки к репорту,
  чтобы он стал корректным.