# Ru

> Полное ревью новой фичи или ветки перед мержем/релизом — сверка с требованиями (YouTrack/файл требований, если есть; иначе агент сам восстановит объём изменений по git diff), code review, поиск нестыковок в use cases, проверка регрессии смежных модулей и живое тестирование UI в браузере, с итоговым prod-ready вердиктом. Используй всегда, когда просят проверить готовность фичи/ветки/PR к мержу или релизу, ревьюнуть/протестировать новую функциональность, пройти use cases вживую, проверить регрессию соседних экранов, или сделать QA/приёмку перед продом — даже если явной ссылки на требования/issue в запросе нет.

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

---

# Ревью и тестирование новой фичи (code review + логика + use cases + регрессия)

## ВВОДНЫЕ

Разбери `$ARGUMENTS` и контекст диалога, чтобы извлечь то, что дано; всё,
что не дано явно, определи сам по коду и требованиям — не жди, пока
пользователь перечислит это за тебя:

- **Требования (YouTrack issue)** — ссылка вида `https://youtrack.example.com/issue/...`,
  если есть в аргументах или в диалоге.
- **Требования (файл в репозитории)** — путь вида `docs/qa/requirements/**/requirements.md`,
  если есть.
- **Ветка / диапазон коммитов для ревью** — если не указано, бери текущую
  ветку относительно `main`/`dev`.
- **Затронутый функционал / модуль(и)** — опциональная подсказка; не
  ограничивайся ею, найди все реально затронутые модули сам (шаг 2).
- **Смежные интеграции, которые нельзя ломать** — опциональная подсказка;
  дополни собственным анализом зависимостей.
- **URL/команда для локального запуска UI** — если не указано, определи
  сам по README/package.json/docker-compose соответствующего сервиса.

Если из всех вводных не дано вообще ничего (ни ссылки на issue, ни файла
требований, ни ветки) — прежде чем начинать полноценное ревью, кратко
уточни у пользователя хотя бы один источник требований; без источника
требований пункт 3 (сверка "требование → реализация") невозможен.

## ЗАДАЧА

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

1. **Изучи требования**: открой и прочитай issue по ссылке и (если указан)
   файл requirements.md. Зафиксируй список функциональных и
   нефункциональных требований, acceptance criteria и явных
   ограничений/edge cases, упомянутых в задаче.

2. **Самостоятельно найди все затронутые модули/сервисы/функции** — не
   жди, пока их перечислит пользователь:
   - Посмотри git log/diff по указанной ветке относительно базовой ветки
     (main/dev) и составь полный список изменённых файлов.
   - Для каждого изменённого файла определи, к какому сервису/модулю/
     пакету он относится (в монорепе — конкретный сервис в services/*,
     конкретный фронтенд/пакет и т.д.).
   - Пройди "на один уровень вглубь": какие функции/классы/эндпоинты/
     обработчики событий реально изменены или добавлены (не только имена
     файлов) — построй список конкретных точек входа (API-эндпоинты,
     обработчики webhook, консьюмеры очередей, cron-джобы,
     UI-компоненты/страницы).
   - Найди вызывающий и потребляющий код: кто вызывает изменённые функции/
     эндпоинты и кто зависит от изменённых контрактов данных (grep по
     использованию, поиск импортов/ссылок) — это и есть кандидаты на
     регрессию, даже если они не были явно упомянуты в требованиях.
   - Зафиксируй итоговый список затронутых модулей/сервисов/функций — он
     используется во всех последующих шагах вместо/в дополнение к
     подсказке из "ВВОДНЫЕ".

3. **Сопоставь требования и реализацию**:
   - Каждое требование из issue/requirements.md — реализовано полностью,
     частично или не реализовано? Укажи конкретно, каких пунктов не
     хватает.
   - Есть ли расхождения между документацией/требованиями и фактическим
     поведением кода?
   - Есть ли скрытые допущения разработчика, которые не были явно
     оговорены в требованиях?

4. **Проведи code review изменений** (по полному списку модулей/файлов из
   шага 2, а не только по тем, что упомянуты в подсказке):
   - Корректность логики (граничные условия, обработка ошибок, race
     conditions, идемпотентность, повторные попытки/ретраи,
     транзакционность там, где это применимо).
   - Валидация входных данных и защита от некорректных/вредоносных данных
     (в т.ч. типовые уязвимости OWASP: инъекции, XSS, небезопасная
     десериализация и т.п., если применимо).
   - Логирование и наблюдаемость: достаточно ли логов для диагностики в
     проде, нет ли утечки чувствительных данных в логи.
   - Конфигурация/секреты: не захардкожены ли значения, которые должны
     быть конфигурируемыми (URL, токены, ключи, feature-флаги).
   - Совместимость со стилем и архитектурой существующего кода в модуле/
     сервисе.
   - Наличие и адекватность тестов (unit/integration) на новую логику;
     чего не хватает.
   - Миграции БД (если есть) — обратимость, безопасность для продакшена,
     отсутствие блокировок на больших таблицах.

5. **Проверь use cases на нелогичные моменты и несостыковки**:
   - Пройди по всем сценариям использования (счастливый путь +
     альтернативные ветки) и проверь, нет ли противоречий между шагами.
   - Проверь граничные/крайние случаи: пустые значения, дубликаты,
     конкурентные запросы, повторная обработка одного и того же события,
     отсутствие сети/недоступность внешнего сервиса, некорректные форматы
     данных, устаревшие/просроченные данные.
   - Проверь мультиаккаунт/мультитенантность (если применимо к модулю) —
     нет ли утечки данных между аккаунтами/пользователями/проектами.
   - Проверь идемпотентность обработчиков webhook/событий (если
     применимо) — не создаётся ли дублирующаяся сущность при повторном
     получении события.

6. **Проверь регрессию** (по полному списку модулей/сервисов/интеграций из
   шага 2, включая те, что явно не были упомянуты в вводных, но зависят от
   изменённого кода):
   - Не сломан ли существующий функционал затронутых модулей и смежные
     интеграции.
   - Проверь обратную совместимость API/контрактов данных, если они
     менялись.
   - Если есть автотесты — прогони их и зафиксируй результат; если тестов
     нет — явно это укажи как риск.

7. **Проверь UI**, если изменения затрагивают фронтенд/интерфейс (страницы,
   компоненты, формы, виджеты, боты с UI-подобным сценарием — например
   диалоги телеграм-бота):
   - Подними приложение локально (используй URL/команду из вводных; если
     не указано — определи команду запуска сам по README/package.json/
     docker-compose соответствующего сервиса) и открой затронутые экраны
     в браузере (или пройди сценарий бота вживую).
   - Не ограничивайся статическим чтением кода компонентов — реально
     пройди фичу руками: заполни формы, нажми кнопки, отправь сообщения
     боту и т.д.
   - Проверь golden path (основной сценарий из требований) и как минимум
     2-3 граничных сценария (пустые/невалидные данные, повторный ввод,
     отмена действия, потеря соединения).
   - Проверь, что не появилось визуальных/поведенческих регрессий в
     соседних экранах/шагах флоу, которые не менялись напрямую, но могли
     быть задеты (общие компоненты, layout, состояние формы, роутинг).
   - Проверь состояния загрузки/ошибок/пустых данных (loading/error/empty
     states), если применимо.
   - Если UI поднять не удалось (нет окружения, нет доступа, headless-
     среда) — явно укажи это в отчёте как ограничение проверки, не выдавай
     статическое чтение кода за подтверждённую проверку UI.

8. **Оцени готовность к продакшену** (enterprise / best practice / prod-ready):
   - Обработка ошибок и graceful degradation при сбое внешних сервисов.
   - Производительность: нет ли N+1 запросов, лишних синхронных вызовов в
     горячем пути.
   - Безопасность: аутентификация/авторизация на новых эндпоинтах,
     ограничение доступа.
   - Мониторинг/алертинг: возможно ли отследить сбой этой фичи в проде.
   - Документация: обновлена ли документация/README/требования под
     фактическую реализацию.

## РЕЗУЛЬТАТ (формат ответа)

1. Краткое резюме: готова ли фича к релизу (да / да с замечаниями / нет).
2. Список фактически затронутых модулей/сервисов/функций/точек входа,
   найденный самостоятельно на шаге 2 (в т.ч. те, что не были указаны в
   подсказке).
3. Таблица соответствия "требование → статус реализации → комментарий".
4. Список найденных проблем, разбитый по категориям: Критично / Важно /
   Незначительно — для каждой проблемы: файл:строка, описание, конкретный
   сценарий воспроизведения, рекомендация по исправлению.
5. Список найденных нестыковок в use cases (если есть).
6. Результат проверки UI: что именно проверено вживую (шаги, скриншоты/
   описание), какие найдены визуальные/поведенческие проблемы, было ли
   ограничение по проверке (если UI не поднимался — явно указать это).
7. Результат проверки регрессии (что проверено, что сломано, что не
   покрыто тестами).
8. Итоговый чек-лист "prod-ready" с отметками done/not done.

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