Как внедрить AI (Claude) и отследить его влияние на команду. Часть 3 Начинаем собирать базовый минимум для работы команды.

Создание правил / Rules По моему опыту, это самый важный инструмент. Т.к. правила всегда попадают в контекст и почти без исключений учитываются моделью. Хранить их можно в .claude/rules, разбив на несколько md-файлов.

Пример: architecture.md - краткая навигация по проекту, где и какие файлы хранить и какую методологию вы для этого используете (например модульную архитектуру или FSD).  code-style.md - более детальное описание принятых код-стайлов. Проще говоря, всё, что вы ещё не успели закрыть линтерами. best-practice.md - требования к итоговому результату, какие подходы и методологии нужно соблюдать (KISS, DRY, SOLID и т.п.). Также тут можно указать ваши основные паттерны и другие требования.

Дальше всё ограничено вашей фантазией. Можно создавать отдельные файлы для языков, фреймворков, внутренних библиотек и любых других технологий, если это действительно важно для проекта.

Несколько советов: 1. Разбиение на файлы нужно прежде всего вам. AI вообще пофиг, лежат правила в одном документе или в десяти. Поэтому организуйте их так, чтобы команде было удобно поддерживать и обновлять знания. 2. Не пытайтесь сразу описать каждый возможный случай. Начните с краткой справки, а если результат не устраивает - добавляйте конкретные примеры с кодом: "делай вот так, не делай эдак". 3. Не пишите что-то вроде: "Представь, что ты Senior Fullstack Engineer с 20 годами опыта". Окей, AI не тупой и не ленивый. Он примет любые правила игры, но если вы оставили свободу интерпретации, не ждите результат, который существует только у вас в голове. 4. Если собственных знаний не хватает, идите на GitHub и ищите репозитории с правилами или скиллами под нужные технологии. Но не тащите в проект готовые «комбайны», о которых нейро-инфлюенсеры орут из каждого утюга. Там обязательно будет три десятка языков и столько же фреймворков, но главное, всё это, разумеется, сгенерировано самой нейронкой из ничего. Такие наборы неэффективны и лишь забивают контекст тем, с чем LLM никогда не столкнётся в вашем проекте, что повышает риск галлюцинаций. Количество звёздочек тут ничего не гарантирует. Смотрите, внимательнее что автор репы из себя представляет, связан ли он крупным бигтехом, контрибьютит ли что либо полезное, есть ли у него релевантный опыт, кроме собственного AI-стартапа, о котором вы никогда не слышали и, вероятно, не услышите. 5. Проще всего, если у команды уже есть база знаний в условном Confluence. Передайте её AI и попросите сформировать правила. Противоречия с предыдущим пунктом нет - это не генерация из ничего, а миграция накопленных знаний команды в формат, понятный нейронке. 6. На каком языке писать? С точки зрения экономии контекста английский обычно лаконичнее. Но если он усложнит поддержку и масштабирование правил - забейте и используйте тот язык, на котором команде удобнее работать.

А далее мы переходим к изучению skills, agents и mcp. #ClaudeCode_TLSH