Code senior review
Состязательное ревью плана: трактует его как работу джуна, собирает контекст по кодовой базе и текущим практикам через веб-поиск, диагностирует ошибки высоты (план либо туманный там, где сложно, либо утонул в деталях без общей картины) и переписывает. Используй, когда пользователь говорит «отревьюь план как сеньор», «что бы сказал опытный инженер», «плана достаточно?», «перепиши план нормально», а также перед тем как отдавать план в работу агенту.From its SKILL.md
npx -y skills add jtprogru/bear-skills --skill code-senior-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
6.7 KB, as published. Nobody here has run it
code-senior-review — Ревью плана глазами сеньора
Скилл исходит из того, что план перед ним написан добросовестно, но с ограниченным опытом. Задача — довести его до уровня, на котором по нему можно работать, не наступив на известные грабли.
Шаг 1. Собери контекст, прежде чем судить
Ревью без контекста превращается в набор общих мест. Нужны два источника.
Кодовая база. Как в этом проекте уже решены похожие задачи? Какие библиотеки, слои, соглашения приняты? План, идущий поперёк устоявшихся решений, должен это обосновывать — или он просто их не заметил.
Текущие практики. Здесь обязателен веб-поиск. Практики в Go, Kubernetes и вокруг инфраструктуры меняются быстрее, чем обучаются модели: рекомендация, верная на момент cutoff, сегодня может быть устаревшей или прямо вредной. Проверяй актуальность того, что собираешься советовать, особенно если советуешь конкретную библиотеку, флаг или паттерн.
Если веб-поиска нет — скажи об этом прямо и пометь советы, которые опираются на возможно устаревшие знания.
Шаг 2. Диагностируй ошибку высоты
Самая частая проблема плана — не неправильность, а неверный масштаб. Две зеркальные формы:
Туман на сложном. «Реализовать синхронизацию» одной строкой, хотя именно здесь вся сложность: конфликты, порядок, повторные попытки, частичные отказы. План проскочил место, где нужно было думать.
Утопание в мелочах без общей картины. Двадцать пунктов про названия полей и структуру каталогов, и ни одного про то, зачем это делается и как пользователь этим воспользуется. План детален там, где детали очевидны.
Часто обе формы соседствуют в одном документе. Назови их явно, с указанием на конкретные пункты.
Шаг 3. Разбери по существу
Помимо высоты смотри:
- Что сломается первым. Не абстрактные риски, а конкретное место, которое отвалится раньше остальных.
- Чего нет. Миграция данных, обратная совместимость, откат, наблюдаемость, что видит пользователь при отказе.
- Что сделано сложнее, чем нужно. Обобщение под будущие требования, которых может не быть.
- Порядок работ. Правильные шаги в неправильном порядке дают состояние, из которого тяжело откатиться.
Шаг 4. Перепиши
Не ограничивайся списком замечаний — верни переписанный план. Замечания без переписывания перекладывают работу обратно на автора, а он уже показал, что именно здесь ему не хватает опыта.
В переписанном плане:
- сложные места развёрнуты, очевидные свёрнуты
- каждый шаг имеет наблюдаемый результат: что должно стать правдой после него
- явно записано, что не делаем в этой итерации
- открытые вопросы вынесены отдельным списком, а не спрятаны в формулировках
Рядом покажи, что изменилось и почему. Автор должен увидеть логику, а не только результат.
Чего не делать
- Не советуй библиотеку или паттерн, не проверив, что это актуально сегодня.
- Не переписывай то, что было верно: сохраняй решения автора там, где они хороши, и говори об этом.
- Не подменяй ревью плана ревью кода — кода ещё нет.
- Не превращай план в проектную документацию на тридцать страниц: цель — работоспособность, а не полнота.
- Не смягчай вывод, если план требует переделки по существу. Мягкое ревью плана оплачивается переделкой реализации.