инструменты 1 авг 2026 1 мин

Десять граблей при разработке плагина для Claude Code

Автор делится опытом создания production-ready плагина для Claude Code — не игрушечного, а полнофункционального инструмента для аудита и контроля. Официальная документация покрывает только базовые сценарии, но реальная разработка полна неочевидных ловушек, каждая из которых стоила автору нескольких часов отладки.

Разработчикам Claude Code плагинов и инструментов для LLM стоит прочитать, чтобы избежать типичных, но неочевидных ошибок, которые не описаны в документации и проявляются только в реальной работе. Особенно ценно для тех, кто строит production-системы с аудитом, безопасностью и кросс-платформенной поддержкой.

Это аннотация к авторской статье. Мы не публикуем и не пересказываем чужие тексты целиком — полная версия у автора.

О чём статья

Кеширование плагинов по версии приводит к тому, что изменения не применяются при переустановке с тем же номером версии — самая коварная проблема, потому что всё выглядит рабочим
Подсчёт токенов в JSONL-логах Claude содержит дубликаты usage-объектов для каждого блока контента, что приводит к многократному завышению стоимости
Наивный парсинг транскриптов по подстрокам (например, 'mcp__github__') некорректен — контент из внешних источников (веб-страницы) может содержать те же паттерны и исказить статистику
Кросс-платформенность требует внимания с первого коммита: различия в путях (слеши vs бэкслеши), права на симлинки в Windows, hardcoded /tmp — всё это ломается при переносе между ОС