Продуктивность

“Исправил баг” — а тесты никто не запускал. Модель уверенно пишет отчёт об успехе, потому что код выглядит правильно, а не потому что он реально прошёл проверку. Skill verification-before-completion блокирует этот шаг: нельзя написать “готово”, пока команда или тест не были реально запущены и не показали зелёный результат. Не “должно работать по логике”, а “вот вывод команды, вот exit code”. За неделю в серии прошли семь скиллов: brainstorming — уточнить требования до кода, TDD — тест раньше реализации, code-review — чеклист вместо усталого глаза, writing-plans и systematic-debugging — план и гипотезы вместо правок наугад, worktrees — изоляция параллельных задач, и этот — не врать себе про готовность. ...

Просишь “добавь кэш” — без уточнений получаешь functools.lru_cache с дефолтным размером, без TTL, без инвалидации. Формально задача выполнена. Через неделю продакшен отдаёт протухшее значение, и разбираться будешь не ты, а дежурный в 3 ночи. Skill brainstorming встаёт между запросом и кодом: не пишет реализацию сразу, а спрашивает то, что ты забыл проговорить. TTL нужен? Кэш на процесс или общий между воркерами? При инвалидации ждём протухания или сбрасываем явно? Диалог выглядит так: “добавь кэш” → Claude уточняет размер, TTL, стратегию инвалидации → и только потом пишет реализацию под твой конкретный случай, а не первый попавшийся шаблон. ...

Попроси Claude сделать код-ревью пять раз подряд — получишь пять разных наборов придирок. Один раз зацепится за нейминг, другой раз пропустит забытый await. Не потому что модель плохая — у неё нет фиксированного чек-листа, только твой промпт здесь и сейчас. Skill — файл с инструкцией и, если нужно, скриптами, который Claude подхватывает по команде /имя-скилла или по совпадению с задачей. Написал раз — используешь месяцами один и тот же процесс, а не лотерею. ...