メニュー
Ревью diff'а pull request с записью структурированного результата в review.json для публикации workflow'ом. Использовать при ревью выкачанного PR по локальным артефактам pr_diff.txt и pr_description.txt; в GitHub напрямую ничего не постится.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Когда нужна короткая демонстрация Agent Skill или проверка команд /skill: в этом проекте.
Реализация утверждённой фичи по PRODUCT.md и TECH.md с поддержанием спек и кода синхронными в одном PR. Использовать после утверждения спек, когда следующий шаг — сборка фичи. Канонический источник правил «спеки и код в одном PR» и «держи спеки актуальными».
Разрешение Git-конфликтов через компактные выжимки (хвосты ours/base/theirs и diff) вместо загрузки целых файлов в контекст. Использовать, когда merge, rebase, cherry-pick или stash pop остановились на конфликтах, git status показывает unmerged paths или в файлах есть маркеры конфликтов.
Исполняемый плейбук автономных прогонов roadmap — механика порций, процедура defer/отката, гигиена коммитов, критерии hard stop. Принципы и активация — в .vibe/rules/roadmap-autopilot.mdc.
Spec-first процесс для существенных фич — оркестратор: PRODUCT.md до реализации, TECH.md когда оправдан, реализация по утверждённым спекам. Использовать при старте значимой фичи, планировании агентной реализации или когда спеки нужно хранить в репозитории.
Создание и обновление скиллов — генерация, правка и доводка SKILL.md. Использовать при авторинге новых скиллов или ревизии структуры, фронтматтера и инструкций существующих.
| name | review-pr |
| description | Ревью diff'а pull request с записью структурированного результата в review.json для публикации workflow'ом. Использовать при ревью выкачанного PR по локальным артефактам pr_diff.txt и pr_description.txt; в GitHub напрямую ничего не постится. |
| vibeVersion | 1.1.0 |
Проревьюировать текущий pull request и записать результат в review.json.
pr_diff.txt и описание PR в pr_description.txt.review.json.Префиксы в 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.
Предлагая правку кода:
<замещающий код>
Правила: отступы точно как в оригинальном файле; внутри блока — только замещающий код; для многострочных правок 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".
Found: X critical, Y important, Z suggestions.Approve, Approve with nits или Request changes.review.json через jq; невалидный JSON — исправить.gh pr review, gh pr comment, gh api и любые другие команды, постящие в GitHub.Единственный результат работы — финальный review.json.