Плагины для Claude Code, собранные на основе моей практики.
Этот файл отвечает на два вопроса: что это за набор и как его поставить.
Договор каждого плагина — его возможности, что он даёт и как связан с другими —
описан на страницах docs/plugins/, устройство и расположение
компонентов — в локальных README плагинов.
Документация: состав плагинов, связи между ними, правила проверки и отчёты о
прогонах — в каталоге docs/. Сайт собирается Zensical и
публикуется в GitHub Pages.
Установка и обновление маркетплейса и плагинов описаны на отдельной странице.
sdlc подтянет tdd-master и functional-clarity, fpf-competency-bank — fpf-integration: это объявленные зависимости.
Локально:
claude --plugin-dir plugins/functional-clarity --plugin-dir plugins/tdd-master --plugin-dir plugins/llms-keeper --plugin-dir plugins/planner --plugin-dir plugins/sdlc --plugin-dir plugins/clarity-language --plugin-dir plugins/plugin-testing --plugin-dir plugins/fpf-integration --plugin-dir plugins/fpf-competency-bankЧто за что отвечает, как плагины связаны и в каких случаях каждым лучше не пользоваться — в документации.
Я изучаю методы создания жизнеспособных систем, которые развиваются вместе с требованиями.
В этом смысле органичное развитие идеи должно влечь за собой такое же органичное развитие кода
Жизнеспособная система - модульная система, итеративно адаптирующаяся к внешним вызовам, способная заменить или изменить свои компоненты для сохранения или развития функциональности в условиях динамично меняющихся требований к системе
О жизнеспособности:
- Никогда не находится в состоянии завершенности, всегда неидеальна.
- Не требует полного переписывания, рефакторинг кода локальный, модульный.
- Глобальный рефакторинг ограничивается выделением связей, модулей, не приводит к переписыванию кода.
- Каждое изменение в такой системе сокращает сложность и сроки будущих изменений.
Именно вышеописанные качества делают систему жизнеспособной.
Есть и множество других факторов, которые делают её НЕ жизнеспособной
Всякая структура упрощает один вид работы и усложняет другие, в этом её основная задача - сфокусировать усилия.
На чем же стоит фокусироваться при разработке?
На адаптивности и специализации. Система неизбежно будет развиваться, и всё что она делает должна делать хорошо.
Иными словами каждая доработка инструмента или функциональности должна развивать его: увеличивать потенциал и возможные варианты использования.
Это не значит что мы должны создать "комбайн" и любой инструмент ждет бесконечное усложнение, напротив, этого не стоит допускать, а стоит четко определить идею и не выходить за её рамки.
Помогает писать простой, надёжный и понятный код, а существующий менять без лишнего риска. Полный свод — 22 принципа с отдельным 2A, стиль программирования, семишаговая дисциплина изменения существующего кода и правило комментариев «объясняй почему, а не что». Выжимка попадает в контекст при старте сессии.
Помогает писать код через проверяемое поведение: сначала падающий тест, затем минимальная реализация и рефакторинг. Метод — по Кенту Беку и Роберту Мартину, со сводом трёх законов и принципов FIRST; справочники покрывают pytest и Django.
Помогает держать контекст проекта для ИИ-агентов в актуальном виде — файлом, который читается за один раз, по стандарту llmstxt.org.
Помогает довести замысел до подробного плана — от продуктовой проработки до архитектуры и плана реализации. Каждый шаг оставляет версионируемый файл в репозитории, и реализация не запускается по устаревшему плану. Команды перечислены на отдельной странице.
Главное отличие от готовых инструментов планирования: свой процесс он не навязывает. Продуктовую проработку и исполнение выполняют роли, которые проект объявил в .claude/planner-context.md — свои агенты, sdlc или роли другого фреймворка вроде core-team. За planner остаются формат артефактов, проверка состава ответа, запись файлов и видимый след того, кто и почему был выбран. Разбор — в документации.
Помогает провести изменение через полный цикл разработки — от архитектуры до реализации и ревью. Три роли: architect, code-implementer, code-reviewer. Стек учитывается справочниками по надобности: Python (Django, FastAPI) и React. Тесты и принципы кода берутся из tdd-master и functional-clarity вместо дублирования.
Помогает сделать текст ясным и естественным — от технической документации до художественной прозы. Три скилла: смысловые паттерны в технических документах (каталог из 12, с обоснованием по FPF), естественный русский без кальки и придуманных переводов, стиль художественной прозы по шести методам.
Помогает проверять поведение плагинов Claude Code, запуская их в отдельной песочнице.
Помогает работать по сводам компетенций — писаным принципам, по которым команда принимает решения: находит нужный свод, применяет к задаче и собирает новый по методу. Основа — ailev/FPF; без источника справочника скилл останавливается, а не работает вслепую.
Задаёт правила, по которым компетенция попадает в банк, и служит источником готовых сводов для fpf-integration. Подключается строкой в ~/.claude/frameworks.paths, исполняется резолвером из fpf-integration.
senior-developer-tools расширяет инструментарий разработки: по плагину на язык или связку (rust, python, typescript, web-svelte), плюс System Design для веб-сервисов, GitLab MR-flow, Bruno, SQLite-паттерны. Методологию не дублирует: тесты, принципы ясности и роли разработки его плагины берут отсюда. Поэтому подключать нужно оба маркетплейса, иначе его агенты не найдут нужные скиллы.
core-team организует командную работу над проектом: фасилитатор распределяет работу между ролями, память живёт между сессиями, качество держат гейты. Ставится не через маркетплейс — каталог .claude/ копируется в проект. Для planner это внешний поставщик продуктовой проработки, тот самый «пакет Core Team» из таблицы способностей.
ailev/FPF — First Principles Framework А. Левенчука. На нём стоят fpf-integration и fpf-competency-bank: первый читает спецификацию через MCP или локальную копию и без источника останавливается, второй хранит своды, собранные по её правилам.
spumer