review-pr

name	review-pr
description	Ревью diff'а pull request с записью структурированного результата в review.json для публикации workflow'ом. Использовать при ревью выкачанного PR по локальным артефактам pr_diff.txt и pr_description.txt; в GitHub напрямую ничего не постится.
vibeVersion	1.1.0

Ревью PR

Проревьюировать текущий pull request и записать результат в review.json.

Контекст

• Рабочая директория — checkout ветки PR.
• Workflow кладёт аннотированный diff в pr_diff.txt и описание PR в pr_description.txt.
• Фокус — на файлах и строках, изменённых этим PR.
• Не постить комментарии и ревью в GitHub напрямую — единственный выход скилла это review.json.

Рамки ревью

• Приоритет: корректность, безопасность, обработка ошибок, значимая производительность.
• Стиль и nit-замечания — только с конкретным suggestion-блоком.
• Проблема в незатронутом PR'ом коде → в summary, не inline-комментарием.
• Не предлагать тесты, которые лишь варьируют входы конструктора или поля структуры, когда существующий тест уже покрывает значимое поведение. Новый тест — только под отдельный путь кода или edge case.
• PR — очевидный V0/первичная реализация → предложения по надёжности (таймауты, ретраи, lifecycle) подавать как опциональную будущую работу, а не блокер, если они не грозят корректности, безопасности или потерей данных.

Аннотации строк diff'а

Префиксы в pr_diff.txt:

• [OLD:n] — удалённая строка старой стороны → "LEFT".
• [NEW:n] — добавленная строка новой стороны → "RIGHT".
• [OLD:n,NEW:m] — неизменённый контекст → "RIGHT" со строкой m.

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

Тело каждого комментария начинается с одной из меток (оставлять на английском — это контракт workflow):

• 🚨 [CRITICAL] — баги, безопасность, краши, потеря данных.
• ⚠️ [IMPORTANT] — логические проблемы, edge cases, отсутствующая обработка ошибок.
• 💡 [SUGGESTION] — стоящие улучшения и лучшие паттерны.
• 🧹 [NIT] — мелочь, только при наличии suggestion-блока.

Стиль: кратко, прямо, actionable; без комплиментов и расшаркиваний; предпочитать однострочные комментарии; диапазон — не более 10 строк; inline-комментарии — только на валидные изменённые строки этого PR.

Suggestion-блоки

Предлагая правку кода:

<замещающий код>

Правила: отступы точно как в оригинальном файле; внутри блока — только замещающий код; для многострочных правок start_line — первая строка диапазона, line — последняя.

Формат вывода

Создать review.json:

{
  "summary": "## Overview\n...\n\n## Concerns\n- ...\n\n## Verdict\nFound: 1 critical, 2 important, 3 suggestions\n\n**Request changes**",
  "comments": [
    {
      "path": "path/to/file",
      "line": 42,
      "side": "RIGHT",
      "start_line": 40,
      "body": "⚠️ [IMPORTANT] Краткое объяснение\n\n```suggestion\nreplacement\n```"
    }
  ]
}

Правила полей: path — относительно корня репозитория; line обязателен и должен указывать на верную сторону; start_line — опционален, только для диапазонов; side — строго "LEFT" или "RIGHT".

Требования к summary

• Высокоуровневый обзор PR.
• Важные замечания + проблемы в незатронутом коде, которые нельзя было оставить inline.
• Счётчик в формате Found: X critical, Y important, Z suggestions.
• Финальная рекомендация: Approve, Approve with nits или Request changes.

Финальные проверки

• Провалидировать review.json через jq; невалидный JSON — исправить.
• Сверить номера строк с аннотированным diff'ом.
• Не запускать gh pr review, gh pr comment, gh api и любые другие команды, постящие в GitHub.

Единственный результат работы — финальный review.json.