Здарова, работяги!

У меня сложилось впечатление, что в сообществе есть определённая путаница на тему мемори-банков, рулсов, MCP и скиллов. Поэтому сегодня хочу поговорить с вами именно на эту тему.

Начнем с определений.

Memory bank — это внешняя память агента о проекте или пользователе.
Туда обычно кладут долгоживущий контекст: архитектурные решения, договорённости, особенности проекта, вкусы команды, важные факты, которые агент должен помнить между сессиями.
По сути, это способ не объяснять одно и то же заново в каждом чате.
Memory bank как “папка с простынями контекста, которую агент должен перечитывать перед работой” — почти устаревший паттерн.

Rules / рулсы — это инструкции для агента, которые задают рамки его поведения.
Например: “используй только pnpm”, “не трогай файлы миграций”, “компоненты называем через PascalCase”, “перед изменением API сначала предложи план”.

MCP — это протокол, через который агент подключается к внешним инструментам и данным.
Например, к GitHub, Jira, Figma, базе данных, Sentry, файловой системе, внутренним сервисам компании.
MCP превращает агента из “чата, который умеет писать текст” в участника рабочего процесса, который может ходить в нужные системы и получать оттуда контекст.

Skills / скиллы — это переиспользуемые сценарии работы агента под конкретные задачи.
Например: “как делать code review”, “как заводить новый пакет в монорепе”, “как писать тесты в этом проекте”, “как оформлять PR”.

Если совсем коротко:
Memory bank хранит контекст.
Rules задают правила поведения.
MCP даёт доступ к инструментам.
Skills описывают рабочие сценарии.

Использовать агента без них сейчас нет совершенно никакого смысла, качество его работы драматически падает без них. Но нужны ли прям все эти инструменты?
Сейчас всё больше фокус смещается в сторону связки rules и skills.

Rules играет роль закона: они всегда в силе и задают рамки, которые агент не должен нарушать. Агент держит их в контексте всегда.

Skills работают как инструменты: агент знает, что они есть и когда их применять, но не держит их целиком в контексте постоянно.
Нужен code review — достал skill для review.
Нужно завести новый пакет — достал skill для этого сценария.

Окей, с теорией разобрались. Давайте попробуем теперь написать алгоритм выбора инстурмента.

Я бы шёл в таком порядке.

1. Сначала линтеры, форматтеры, тесты, типы и скрипты
Если правило можно проверить автоматически, лучше проверять его автоматически. Не надо забивать микроскопом гвозди.
Линтер не забудет, не потратит токены и не начнёт “творчески интерпретировать” инструкцию.

2. Потом skills
Если речь не про жёсткую проверку, а про сценарий действий, лучше оформить это как skill.
Например: как делать code review, как заводить новый модуль, как расследовать падение CI, как готовить релиз.
Skill хорош тем, что не висит в контексте всегда. Агент знает, когда его доставать, и подтягивает подробную инструкцию только под конкретную задачу.

3. И только потом rules
Rules стоит использовать для того, что должно ограничивать агента всегда и не может быть надёжно выражено через автоматику или skill.
Они самые дорогие, потому что постоянно занимают место в контексте и влияют на каждую задачу, даже если конкретно сейчас это правило не нужно.

Резюмируя
• Если можно зашить в автоматику — зашиваем в автоматику.
• Если это сценарий — пишем skill.
• Если это постоянный инвариант, который агент обязан помнить всегда — пишем rule.

Итого
Не надо пытаться засунуть весь контекст проекта в одно место. Чем точнее вы раскладываете знания по слоям, тем стабильнее и дешевле работает агент.

Интересно ли вам было бы почитать про то, как я пишу скиллы для своих проектов, какие там есть фишки и особенности?