kyy-logs code-review-skill
code-review-skill
Скилл ревью кода: четыре независимых прохода, замечания с доказательствами и допуск к слиянию из JSON
- 305 ★ репозитория
- Последний коммит
- MIT
Расширенный доступ
Почему такой уровень
- Скрипты скилла запускаются в корне вашего проекта через Bash, а отчеты пишутся в `docs/work/`
- Четыре прохода передают дифф и окружающий код модели, поэтому закрытый код уходит ее провайдеру
Установка
- Работает в
В терминале, через SkillFoxx CLI
npx skillfoxx add skills/kyy-logs-code-review-skillОпределит агенты на машине, покажет уровень доступа и зафиксирует версию.
Другие способы установки
Доступ и проверки
Как мы проверяемРасширенный доступИнструмент запускает код или ходит в сеть, а внешние данные только читает.
- Скрипты скилла запускаются в корне вашего проекта через Bash, а отчеты пишутся в `docs/work/`
- Четыре прохода передают дифф и окружающий код модели, поэтому закрытый код уходит ее провайдеру
Это чужой код. Посмотрите файлы в репозитории перед установкой.
Что делает
Скилл `code-review` для Claude Code и Codex проверяет изменения без сборки, запуска тестов и отчета о покрытии. Он берет диффы, окружающий код, тесты и правила проекта в одном из двух режимов: `worktree` для изменений в рабочем дереве или `commits` для диапазона `base..head`. Код проекта скилл не меняет. Четыре прохода работают в свежих контекстах и пишут каждый свой JSON. `behavior-review` сверяет поведение изменения с контрактом, `test-coverage` оценивает смысл тестов, `repo-guard` ищет нарушения правил репозитория, `impact-analysis` показывает вызывающих, затронутые контракты и последствия для производительности. Обязательные проходы — первые три. Замечание без места, описания и проверяемого довода замечанием не считается. Серьезность бывает `high`, `medium` или `low`. Отчет `code-review.md` и итог допуска собираются из JSON, поэтому цифры не перепечатываются моделью вручную. Незакрытые замечания уровня high и сбой обязательного прохода блокируют слияние. Скилл есть на английском и китайском (`code-review-zh`).
Для кого. Командам и одиночным разработчикам, которые просят агента проверять диффы перед коммитом или слиянием и хотят видеть ссылки на строки и контракты.
Подходит, если
- Перед коммитом хочется получить ревью, где каждое замечание указывает на файл, строку и нарушенный контракт
- Пулл-реквест надо пропустить через формальный допуск, который читается по JSON-записям проходов
- Репозиторий на Java, TypeScript или Vue с собственными правилами в `.code-review/rules/`
- Рефакторинг затрагивает общий контракт, и нужно знать, кто его вызывает
Не подходит, если
- Хочется заменить тесты, CI или проверку человеком: автор пишет, что чистый отчет не доказывает правильность изменения
- Требуется независимый человеческий аудит: все четыре прохода запускает одна и та же модель
- Проект с многопоточным кодом: обнаружение дефектов конкурентности не проверялось
- Изменение состоит только из документации или опечаток, которые поведение кода не затрагивают
Пример запроса к агенту
Проверь текущие изменения скиллом code-review и скажи, можно ли их сливатьОграничения
Версия `v0.1.0-beta.3` от 31 октября 2026 года — тестовая: формат проходов, схема отчета и поведение допуска могут измениться до 1.0. Записи со старой четырехуровневой серьезностью, включая `critical`, несовместимы, `collect-metrics` их отвергает. Стандартный проход `repo-guard` выбирает файлы `.java`, `.ts`, `.tsx` и `.vue`, встроенные правила рассчитаны на Java и Spring, и полное покрытие других стеков авторы не заявляют. Нужны Node.js 22.20 или новее, Python 3.9 с PyYAML, Bash, Git, awk, grep и sed. Правила проекта целиком заменяют встроенные и с ними не объединяются.
Как отключить. Удалите папку `.claude/skills/code-review` (для Codex `.agents/skills/code-review`) в проекте. Отчеты остаются в `docs/work/active/` и удаляются вручную.
Частые вопросы
Как поставить code-review-skill в Claude Code?
Выполните в корне проекта `npx -y skills add kyy-logs/code-review-skill --agent codex --skill code-review --yes` и замените `codex` на `claude-code`. Скилл окажется в `.claude/skills/code-review/`, для Codex путь `.agents/skills/code-review/`.
Какой результат остается после ревью?
В папке `docs/work/active/<slug>/` появляется отчет `code-review.md` и каталог `probes/` с четырьмя JSON. Допуск и счетчики берутся из этих файлов.
Можно ли поставить китайскую версию?
Да, ставьте скилл `code-review-zh` той же командой. В проекте нужна только одна языковая версия, а установщики на Python принимают `--lang en` или `--lang zh-CN`.
Как добавить правила своего проекта?
Положите их в `.code-review/rules/` или укажите папку через переменную `CODE_REVIEW_RULES_DIR`. Пакет правил проекта полностью заменяет встроенный.
Нужны ли сборка и запуск тестов?
Нет, ревью статическое: скилл читает дифф, код вокруг, тесты и правила проекта. Если данные о покрытии есть, он их учитывает. Когда тесты падают или не запускались, отчет это указывает и не заявляет, что условия слияния выполнены.
Обсуждение
Вопросов и отзывов пока нет.
Похожие
СкиллыСкилл для ревью кода по многим языкам и фреймворкам: архитектура, производительность, безопасность, антипаттерны и типичные ошибки
Два скилла: ревью pull request в споре двух моделей и помощник, который разбирает замечания по кругам до слияния
Codex-скилл для проверки кода после вайбкодинга: объясняет блоки, называет файлы и строки, сверяет цель с доказательствами.
Скиллы-контроли для кодовых агентов: второй проход по диффу, который ловит типичные ошибки в коде, тестах и документации от ИИ
CLI и плагин для ревью кода агентом: читает git diff и пишет замечания по строкам с учетом контекста
cross-review отдает планы и код на проверку второй модели: Codex, Claude Code или Antigravity ревьюит работу вашего агента.
Сравнение с похожими
Карточки с тем же главным запросом: чем они отличаются.
| Инструмент | Официальный | Авторизация | Звезды репозитория | Главное отличие |
|---|---|---|---|---|
| kyy-logs code-review-skill (эта карточка) | нет | 305 | ||
| code-review-graph | нет | не нужна | 32 612 | строит граф кода и отдает его через MCP-сервер |
| open-code-review | нет | 49 561 | запускает ревью из командной строки |
Коротко о README
README открывают новости последней беты и раздел о статусе релиза с перечнем несовместимых изменений. Дальше идут схема работы, контракт замечания, настройка правил, список ограничений скилла, и сведения о проверке: 74 офлайн-теста и сквозные прогоны на чистых проектах.
Бейдж для README
Исходный SKILL.md
---
name: code-review
description: Use when code has been written, before committing, or when merging a PR; also when the user says "review my code", "check before commit", "take a look at this change", "PR review", or asks for a strict review/merge gate.
---
# Code Review
> Check for code defects, test quality, and change impact, and confirm that the issues found are closed.
## Resources and Execution Location
- `references/`, `scripts/`, and `assets/` are relative to the directory containing the `SKILL.md` read for this run.
- Run shell commands from the **reviewed project root**; `docs/work/`, code paths, and project rules all belong to the reviewed project.
- `CODE_REVIEW_SKILL_DIR` below is the absolute path of the skill installation directory. Set it on every shell invocation, or replace it directly with the actual absolute path; do not assume variables persist across different shell invocations.
- Scripts require basic commands such as Bash 3.2+, Git, awk, grep, and sed. Invoke them via `bash`; no executable bit is needed.
- Report parsing requires Python 3.9+ and PyYAML; `python` is invoked by default, and `CODE_REVIEW_PYTHON` can specify the interpreter's absolute path.
For installation, see the release repository README; the in-repo entry point is `scripts/install.py`.
## Scope
- Review functional, bug-fix, refactoring, or configuration changes that affect code behavior.
- Pure documentation, formatting, or typo changes that do not affect code behavior may be skipped.
- Static review is still possible when tests fail or have not been run; the report must state the test status and must not claim that merge conditions are met.
## Inputs
| Input | Required | Description |
|---|---|---|
| git repository + diffable changes | Yes | Specify whether to review uncommitted changes or a committed base/head range |
| Acceptance criteria | No | When provided, check them off one by one under "Optional Wrap-up" |
| Coverage data / command | No | When provided, used for the optional measurement in `test-coverage`; without it, static quality checks on the relevant test code still run |
| Rule pack | No | Defaults to the skill's built-in `references/rules/`; can be overridden with `CODE_REVIEW_RULES_DIR` |
| Review identifier | No | `{slug}`, defaults to `<date>-<topic>` |
The artifact root `{output_root}` defaults to `docs/work`; override it with project `.code-review/config.json` `output_dir` or `CODE_REVIEW_OUTPUT_DIR`. This run's artifacts are written to `{output_root}/active/{slug}/`.
## Review Process
> Check items are not hardcoded in this file; they are driven by the `references/probes.yaml` registry.
> Probe implementation details are in `references/probes/<probe-name>.md`; this file covers **main workflow orchestration and shared probe execution boundaries**.
>
> **Execution boundary: static review by default.** For coverage checks, prefer reusing an existing report;
> when measurement is needed, coverage commands may be run within what this round's task allows. Other checks remain read-only evidence.
> Do not modify the reviewed source code during review. Test and CI output are review evidence;
> **all tests green does not mean the behavior is correct**.