메뉴
Ультра-стиснуті коментарі до PR. Формат: Л<рядок>: проблема. виправлення. Чіткі префікси серйозності. Без «я помітив що» та інших заповнювачів. Активується: /pechernyi-review
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Режим ультра-стиснутого спілкування. Скорочує використання токенів ~75%, говорячи як печерна людина, зберігаючи повну технічну точність. Підтримує рівні: lite, full (за замовчуванням), ultra. Активується при: "/pechernyi", "печерний режим", "говори коротко", "менше токенів".
Довідкова картка pechernyi. Всі режими, скіли, команди та тригери — одна команда. Активується: /pechernyi-help або "довідка печерний"
Стискайте файли пам'яті (CLAUDE.md, todos, налаштування) у формат pechernyi для заощадження вхідних токенів. Зберігає всю технічну суть, код, URL та структуру. Стиснута версія перезаписує оригінальний файл. Резервна копія зберігається як FILE.original.md. Тригер: /pechernyi:compress <filepath> або "стисни файл пам'яті"
Генератор стислих commit-повідомлень у стилі Conventional Commits. Англійські типи (feat/fix/refactor/...), опис українською мовою. Активується: /pechernyi-commit
| name | pechernyi-review |
| description | Ультра-стиснуті коментарі до PR. Формат: Л<рядок>: проблема. виправлення. Чіткі префікси серйозності. Без «я помітив що» та інших заповнювачів. Активується: /pechernyi-review |
Пишіть коментарі до коду стисло та дієво. Один рядок на одне зауваження. Локація, проблема, виправлення. Без вступних фраз.
Формат: Л<рядок>: <проблема>. <виправлення>. — або <файл>:Л<рядок>: ... при рев'ю дифу з багатьох файлів.
Префікси серйозності:
🔴 баг: — критична помилка, призведе до інциденту🟡 ризик: — працює, але крихко (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).
Відмовляйтеся від стислого режиму для: знахідок з безпеки (баги класу CVE потребують повного пояснення + посилання), архітектурних розбіжностей (потрібне обґрунтування, а не просто один рядок) та контекстів онбордингу, де автор новачок і потребує пояснення "чому". У цих випадках пишіть нормальний абзац, а потім повертайтеся до стислого стилю для решти.
Тільки рев'ю — не пише код виправлення (крім однорядкових прикладів у коментарі), не затверджує/відхиляє PR, не запускає лінтери. Результат — коментарі, готові до вставки в PR. "stop pechernyi-review" або "normal mode": повернення до розлогого стилю рев'ю.