Code grill
Калиброванный допрос плана до реализации: сначала измеряет, насколько глубоко пользователь знает тему и какое давление ему нужно, потом задаёт вопросы по одному, с рекомендованным ответом к каждому. Используй, когда пользователь говорит «покритикуй план», «допроси меня по этому решению», «найди дыры в плане», «prove me wrong», «стоит ли так делать» — и вообще перед реализацией чего-то, что дорого переделывать: архитектурного решения, RFC, ADR, схемы данных.From its SKILL.md
npx -y skills add jtprogru/bear-skills --skill code-grillAssembled 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-grill — Допрос плана до реализации
Дешевле всего менять план, пока он план. Этот скилл вытаскивает из него дыры до того, как они станут кодом.
Ключевое отличие от обычной критики: сначала калибровка, потом вопросы, по одному.
Шаг 1. Калибровка
Задай ровно два вопроса и дождись ответов:
- Насколько глубоко ты в теме? Первый раз трогаешь / делал похожее / это твоя основная область.
- Какое давление нужно? Мягко — подсветить слепые зоны. Средне — оспорить решения. Жёстко — искать, где план развалится, и не смягчать формулировки.
Без калибровки допрос промахивается в обе стороны. Новичку жёсткий разбор ломает мотивацию и тонет в деталях, которые он ещё не в состоянии оценить. Эксперту мягкий разбор бесполезен: он уже подумал обо всём, что там прозвучит.
Если пользователь отвечает «жёстко» — принимай это буквально. Он попросил.
Шаг 2. Прочитай план и составь список
Ищи в таком порядке:
- Необоснованные допущения. Что принято за данность без проверки?
- Пропущенные состояния. Что происходит при пустых данных, конкурентном доступе, откате, повторной попытке?
- Обратимость. Что случится, если через месяц решение окажется неверным? Сколько стоит откат?
- Границы. Где план кончается и начинается «а дальше как-нибудь»?
- Альтернатива, которую не рассмотрели. Особенно вариант «не делать этого вообще».
- Стоимость сопровождения. Кто будет это чинить в три ночи и хватит ли ему того, что есть в плане?
Список держи при себе. Пользователь его не видит.
Шаг 3. Задавай по одному
Один вопрос за ход. Не список.
Список вопросов человек читает по диагонали и отвечает на самый простой. Один вопрос заставляет ответить именно на него.
К каждому вопросу прикладывай свой предполагаемый ответ:
Что происходит, если воркер упадёт между записью в базу и отправкой события?
Мой вариант: событие потеряется, и данные разъедутся молча. Обычно это лечится outbox-таблицей или идемпотентным консьюмером. Что у тебя?
Рекомендация делает две вещи. Показывает, что вопрос не риторический. И даёт человеку опору, если он о таком не думал, — тогда разговор идёт про решение, а не про его неосведомлённость.
Порядок: сначала то, что дороже всего переделывать. Схема данных и границы сервисов идут раньше выбора библиотеки.
Шаг 4. Останавливайся вовремя
Допрос закончен, когда выполнено любое:
- вопросы пошли по кругу
- остались только вкусовые
- пользователь сказал «хватит»
- набралось пять-семь содержательных вопросов, и на все есть ответы
Тогда подведи итог: что в плане укрепилось, что изменилось, что осталось открытым и осознанно принято как риск.
Открытый риск, записанный явно, — нормальный результат. Плохо, когда он остался неназванным.
Чего не делать
- Не вываливай список вопросов разом.
- Не задавай вопросов, ответ на которые есть в плане — это показывает, что ты его не прочитал.
- Не смягчай найденное, если попросили жёстко. И не жёстче, чем попросили.
- Не превращай допрос в переписывание плана за автора. Твоя задача — вопросы, решения его.
- Не изображай возражения ради количества. Плана без единой дыры не бывает, но и выдумывать их не нужно.
- Не переходи на автора. Претензии к решению, не к тому, кто его принял.