Ai

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

Работаешь над фичей, прилетает срочный багфикс — начинается ритуал: git stash, переключение бранча, фикс, git stash pop, и молишься, чтобы не было конфликта. С одним Claude в одном каталоге та же боль умножается на контекст: агент путает, какую задачу решает сейчас. Skill using-git-worktrees решает буквально: под каждую параллельную задачу — свой worktree, отдельная директория с тем же репозиторием на другом бранче. Git видит один .git, рабочих копий сколько нужно. git worktree add ../fix-urgent-bug hotfix/urgent Одна команда — и багфикс живёт в соседней папке, никак не задевая незакоммиченную фичу в основной. Переключаться cd, а не stash’ем. ...

Без плана правка “по-быстрому” превращается в три часа блуждания по коду и два новых бага взамен старого. Проблема не в скорости мышления, а в отсутствии зафиксированных шагов, которые можно откатить. Skill writing-plans перед сложной задачей выписывает шаги, риски и откат: ошибку на шаге 3 видно сразу, а не после того, как она потянула шаг 7. Skill systematic-debugging работает похоже для багов: гипотеза → проверка → вывод, вместо “поменяю тут, авось заработает”. ...

Пятница, вечер, десятый PR за день — живой ревьюер устаёт и начинает пропускать. Не со зла, просто внимание не резиновое. У Claude такой проблемы нет: у него нет пятницы. Skill code-review гоняет диф по фиксированному набору проверок — корректность, дублирование, лишняя абстракция — и делает это одинаково для первого PR за день и для десятого. Найденное репортит по одной строке на замечание, без похвалы и без размытых формулировок. Реальный кейс: правка асинхронной функции, где забыли await перед вызовом — код формально работал (промис создавался), но результат нигде не дожидался. Skill нашёл это за секунды, просто пройдя по чеклисту на неотловленные промисы. ...

Тест, написанный после реализации, почти всегда проверяет то, что код уже делает — не то, что он должен делать. Баг в логике проскальзывает мимо, потому что тест написан по мотивам той же логики. Skill test-driven-development меняет порядок: сначала падающий тест на нужное поведение, потом минимальный код, который его зеленит. def test_discount_applies_only_above_threshold(): assert calc_discount(cart_total=500) == 0 assert calc_discount(cart_total=1500) == 150 Тест падает первым — функции calc_discount ещё нет. Код пишется под конкретно эти два случая, а не абстрактную “скидочную систему вообще”. В git-логе видно: коммит с тестом идёт раньше коммита с кодом. ...

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

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

Claude Code — агент с доступом к shell, файлам и git, а не чат с подсказками. Он сам открывает терминал, сам гоняет команды, сам правит файлы — тебе остаётся подтвердить или отклонить. Что реально держит его в рамках: settings.json → permissions.ask/permissions.deny — конкретные тулы (Bash, WebFetch) требуют подтверждения или блокируются жёстко, независимо от того что решил сам агент hooks PreToolUse/PostToolUse — валидация до и после любого действия на уровне харнесса, не промпта; PreToolUse может вернуть deny на опасную команду ещё до её запуска bypassPermissions — режим без подтверждений вообще, но с 2026 уважает org-политику disableBypassPermissionsMode: админ запрещает обход даже если сам агент попробует его включить sandbox-блок — network.allowedDomains, excludedCommands — сеть и список команд закрываются ещё до слоя пермишенов Агент безопасен не потому что “хорошо себя ведёт”, а потому что харнесс проверяет каждое действие снаружи промпта. Без этого слоя — не агент, а root-доступ с уверенным тоном. ...

Для Claude Code есть skill’ы вроде Caveman — экономят токены, выкидывая артикли и служебные слова. Автор репозитория pohuy предлагает другой подход: русский мат — генеративная морфология, четыре корня плюс приставки и суффиксы дают больше смысла на слово, чем экономия артиклей. Одно «на*бнулось» — это “the service has unexpectedly crashed and requires investigation”, но сразу понятно. Что внутри: Словарь на 70+ идиом с инженерным маппингом (SKILL.md + references/slovar.md), часть — из народного словаря russian-swears (417 статей). Эталонные сцены в references/sceny.md: ревью гвнокода, флаки-тест, дока врёт, признание своего проба. Железные правила: код, коммиты, PR и доки — чисто, без мата. На security-предупреждениях и DROP TABLE — без шуток. https://github.com/smixs/pohuy ...