Pechernyi review
Ультра-стиснуті коментарі до PR. Формат: Л<рядок>: проблема. виправлення. Чіткі префікси серйозності. Без «я помітив що» та інших заповнювачів. Активується: /pechernyi-reviewFrom its SKILL.md
npx -y skills add Kerber0ss/pechernyi --skill pechernyi-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
- 4 stars4 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
4.7 KB, as published. Nobody here has run it
Пишіть коментарі до коду стисло та дієво. Один рядок на одне зауваження. Локація, проблема, виправлення. Без вступних фраз.
Правила
Формат: Л<рядок>: <проблема>. <виправлення>. — або <файл>:Л<рядок>: ... при рев'ю дифу з багатьох файлів.
Префікси серйозності:
🔴 баг:— критична помилка, призведе до інциденту🟡 ризик:— працює, але крихко (race condition, відсутня перевірка на null, проковтнута помилка)🔵 нюанс:— стиль, іменування, мікро-оптимізація. Автор може ігнорувати❓ запит:— щире запитання, а не пропозиція
Викинути:
- "Я помітив що...", "Схоже що...", "Варто розглянути можливість..."
- "Це просто пропозиція, але..." — використовуйте
🔵 нюанс: - "Чудова робота!", "Загалом виглядає добре, але..." — скажіть це один раз вгорі, а не в кожному коментарі
- Переказування того, що робить рядок — рев'юер може прочитати диф
- Невпевненість ("можливо", "мабуть", "я думаю") — якщо не впевнені, використовуйте
❓ запит:
Залишити:
- Точні номери рядків
- Точні назви символів/функцій/змінних у зворотних лапках
` - Конкретне виправлення, а не "варто рефакторити це"
- Пояснення "чому", якщо виправлення не є очевидним із опису проблеми
Приклади
Погано ❌
Я помітив, що на рядку 42 об'єкт user може бути не визначений перед доступом до властивості email. Це потенційно може призвести до помилки, якщо користувача не знайдено в базі. Можливо, варто додати перевірку на null тут?
Добре ✅
Л42: 🔴 баг: user null після .find(). Додати guard перед .email.
Погано ❌
Схоже, ця функція робить занадто багато речей одночасно, було б добре розбити її на менші частини для кращої читаємості.
Добре ✅
Л88-140: 🔵 нюанс: функція на 50 рядків робить 4 речі. Винести validate/normalize/persist.
Погано ❌
Ви не думали про те, що станеться, якщо API поверне помилку 429? Я гадаю, нам слід обробити цей випадок.
Добре ✅
Л23: 🟡 ризик: немає повторів при 429. Огорнути у withBackoff(3).
Авто-чіткість (Auto-Clarity)
Відмовляйтеся від стислого режиму для: знахідок з безпеки (баги класу CVE потребують повного пояснення + посилання), архітектурних розбіжностей (потрібне обґрунтування, а не просто один рядок) та контекстів онбордингу, де автор новачок і потребує пояснення "чому". У цих випадках пишіть нормальний абзац, а потім повертайтеся до стислого стилю для решти.
Межі
Тільки рев'ю — не пише код виправлення (крім однорядкових прикладів у коментарі), не затверджує/відхиляє PR, не запускає лінтери. Результат — коментарі, готові до вставки в PR. "stop pechernyi-review" або "normal mode": повернення до розлогого стилю рев'ю.