Настройка Claude Code: Rules, Skills и Workflow — как сочетать?

Короткий ответ: настройка Claude Code — это не «навалить промптов в один файл», а четыре слоя с разными ролями. CLAUDE.md хранит факты, которые агент должен знать всегда; Rules — жёсткие ограничения и соглашения с привязкой к путям; Skills — повторяемые многошаговые сценарии; Workflow связывает Skills, Hooks, cron и CI в воспроизводимый ритм команды. Самая частая ошибка — смешать слои: 40-строчный чеклист деплоя в CLAUDE.md съедает тысячи токенов при каждом старте сессии, а запрет на force push, разбросанный по Skill, после compaction контекста легко теряется.

Материал для iOS-, Flutter- и AI-разработчиков, которые уже используют или планируют внедрить Claude Code — особенно команд, рассматривающих перенос основной работы на облачный Mac или аренду Remote Mac. Ниже — структура каталогов, примеры YAML frontmatter, таблица решений и нюансы долгого запуска на Apple Silicon по состоянию на август 2026.

Данные сверены 5 августа 2026 г. Поведение конфигурации — по официальной документации Claude Code Skills и блогу Anthropic; поля frontmatter могут слегка отличаться между версиями.

Зачем нужны слои, а не один огромный CLAUDE.md

Первая реакция многих команд: раз Claude Code читает файлы проекта, запишем все договорённости в корневой CLAUDE.md — и готово. Проблема в общем бюджете контекста: чем больше грузится при каждой сессии, тем меньше места остаётся для diff кода и вывода инструментов. Хуже, когда процедурное («сначала тесты, потом bump версии, tag, push») смешано с фактами («главный scheme — MyApp-Prod, профиль XYZ в связке ключей»): правка в одном месте тянет за собой всё остальное.

В официальном гайде Anthropic по steering перечислены семь механизмов: CLAUDE.md, Rules, Skills, Subagents, Hooks, Output Styles и дополнения к системному промпту. Для большинства инженерных команд первых четырёх плюс оркестрация Workflow хватает на ~90 % сценариев. Если вы уже собираете стек Cursor + Claude Code + OpenRouter, слоистость в терминале можно сравнить с .cursor/rules в IDE — но каталоги и моменты загрузки другие, слепое копирование не сработает.

Типичный провал: пятёрка Flutter-разработчиков кладёт в CLAUDE.md чеклист code review, шаги Archive и политику веток — файл переваливает за 400 строк. Claude тащит runbook, пока правит один widget: ответы замедляются, после compaction «забывает» требования к тестам из второй половины файла. После разбиения на path-scoped Rules и три Skills средний расход входных токенов снизился примерно на 30 %, а пропуски в review — наоборот, уменьшились.

Базовые понятия: что решает каждый слой

CLAUDE.md: постоянная память проекта

CLAUDE.md (или .claude/CLAUDE.md) загружается при старте каждой сессии. Сюда кладут короткие, стабильные, общекомандные факты:

• однострочные команды сборки и тестов (например, xcodebuild -scheme MyApp test)
• карту monorepo (apps/ios, packages/core — кто за что отвечает)
• индекс активных Skills и Rules (одна строка описания + путь)
• краткие сводки командных табу (детали — в Rules)

Официальная рекомендация — держать файл читаемым; если перевалило за 200 строк, проверьте, не попали ли туда процедуры. CLAUDE.md — это чеклист «загрузки» агента, а не внутренняя wiki.

Rules: ограничения и соглашения по путям

Rules — Markdown-файлы в .claude/rules/. Ключевые отличия от CLAUDE.md:

• можно задать path-scope — загрузка только при работе с подходящими файлами (например, paths: ["**/*.swift"])
• после compaction контекста Rules инъектируются снова — подходят для красных линий безопасности
• тон формулировок: «обязан / запрещено», а не «вот 12 советов»

Хорошие кандидаты в Rules: запрет коммита секретов, краткие соглашения по именованию Swift, требование откатываемых миграций БД, запрет git push --force для агента. В нашей чеклисте безопасности AI-агентов после Black Hat USA 2026 мы подчёркиваем то же: границы терминального агента должны быть записаны в аудируемых Rules, а не в устных договорённостях.

Skills: повторяемые пошаговые сценарии

Skills лежат в ~/.claude/skills/ (пользовательский уровень) или .claude/skills/ (уровень проекта). Каждый Skill — каталог с SKILL.md внутри. По документации Skills действует постепенная загрузка:

• при старте сессии — только name и description
• при вызове — полный текст и привязанные скрипты
• несколько Skills делят общий token budget; ранние вызовы могут вытесняться

Типичные задачи для Skill: чеклист релиза в TestFlight, шаги PR review, пакетная замена строк i18n во Flutter, регенерация OpenAPI-клиента. В YAML frontmatter можно задать allowed-tools (предварительно разрешённые инструменты), disable-model-invocation: true (только ручной /skill-name) и context: fork (запуск в субагенте).

Workflow: связка компонентов в ритм команды

Workflow — не пятая папка, а ответ на вопрос кто и когда запускает какой слой. Hooks форматируют код перед git commit; cron или launchd ночью вызывает /refactor-module; CI в неинтерактивном режиме гоняет Claude Code для миграционных скриптов; облачный Mac через Git держит ту же структуру .claude, что и локальная машина.

Таблица: что куда класть

Практика: конфигурация iOS-команды с нуля

Ниже — структура, проверенная в смешанных iOS/Flutter-репозиториях на 2–6 человек; адаптируйте под себя:

your-repo/
├── CLAUDE.md                    # команды сборки, schemes, индекс skills
├── .claude/
│   ├── settings.json            # общие настройки команды (без секретов)
│   ├── settings.local.json      # локальные переопределения, gitignore
│   ├── rules/
│   │   ├── global-security.md   # не читать .env, не force push
│   │   ├── ios-swift.md         # paths: ["**/*.swift"]
│   │   └── flutter-dart.md      # paths: ["lib/**/*.dart"]
│   └── skills/
│       ├── release-testflight/
│       │   └── SKILL.md
│       └── pr-review/
│           └── SKILL.md

Шаг 1: CLAUDE.md (80–120 строк). Вверху — таблица schemes, минимальная версия iOS, точка входа тестов; в середине — обзор каталогов; внизу — bullet-список Skills (имя + одно предложение). Пошаговых процедур здесь быть не должно.

Шаг 2: разнести Rules. Глобальная безопасность — отдельный файл; языковые правила — по путям. Пример frontmatter для path-scoped Rule:

---
paths:
  - "**/*.swift"
  - "**/*.xcodeproj/**"
---

# Ограничения iOS / Swift
- Новый UI — с Preview или объяснением, почему без него
- Не менять Team ID в Signing & Capabilities
- Изменения сетевого слоя — с обновлением unit-тестов

Шаг 3: первый Skill. Начните с самого частого и ошибкоопасного сценария — у iOS-команд это обычно TestFlight или PR review:

---
name: release-testflight
description: "Archive главного scheme и загрузка в TestFlight; в день релиза или по слову «релиз»"
disable-model-invocation: true
allowed-tools: Bash(xcodebuild *) Bash(fastlane *)
---

## Перед релизом
1. `main` смержен, CI зелёный
2. Запись в `CHANGELOG` совпадает с номером версии
3. `xcodebuild -scheme MyApp -destination 'generic/platform=iOS' archive`
4. fastlane lane `upload_testflight`
5. Комментарий в PR с номером билда

disable-model-invocation: true означает, что Skill загрузится только при ручном /release-testflight — Claude не запустит релиз, пока вы правите UI. Для чувствительных операций это обязательно.

Шаг 4: подключить Workflow. В .claude/settings.json настройте Hooks (например, PreToolUse блокирует опасные команды). Один и тот же каталог .claude на облачном Mac и локально — SSH на Remote Mac ведёт себя как локальный терминал. Общая конфигурация команды — через Git; API-ключи и settings.local.json — в gitignore.

Облачный Mac / Apple Silicon: где это реально помогает

Claude Code — терминальный агент, и качество среды выполнения определяет, насколько смело вы ему доверяете. В сценариях VPSSpark Cloud Mac / аренды Remote Mac слоистая конфигурация даёт три практических выигрыша:

• Зафиксировать окружение: .claude/, Homebrew, версию fastlane — в образ; новый узел без переустановки Skills.
• Стабильные длинные сессии: Apple Silicon M4 с unified memory тянет Xcode, симулятор и Claude Code параллельно; standby ~4 Вт — удобно для ночных /refactor-Skills.
• Изоляция: отдельный системный пользователь для агента на облачном Mac; Rules ограничивают пути к связке ключей — безопаснее, чем «голый» запуск на личной машине.

Типичный Workflow: правки в Cursor локально → push → CI на облачном Mac подтягивает репозиторий и в неинтерактивном режиме гоняет миграционный Skill → fastlane загружает билд. Rules не дают сделать force push из CI; Skills держат шаги идентичными ручному релизу. Flutter-команды могут оформить flutter build ipa и iOS-подпись такими же Skills и разделить общие security Rules.

Если для снижения стоимости API используете OpenRouter, allowed-tools и выбор модели не связаны — но в Workflow стоит следить за пиками памяти: два fork-Skill плюс Xcode Archive на M4 с 16 ГБ могут упереться в лимит. Зафиксируйте в Rule или Skill: «во время Archive не запускать второй fork-Skill».

Стоимость, производительность и риски

Стоимость токенов: раздутый CLAUDE.md — «налог на фон» при каждой сессии; Skills экономят за счёт постепенной загрузки, но несколько Skills в одной сессии делят бюджет. Периодически смотрите /context или официальную статистику токенов — какой слой доминирует.

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

Риски: allowed-tools снижает порог подтверждения на раунд Skill — включайте только для доверенных сценариев. На общих узлах облачного Mac личные ключи — только в settings.local.json. Ошибочные Hooks могут заблокировать commit — сначала проверяйте на ветке.

По сравнению с «ничего не настраивать и каждый раз объяснять заново» 2–4 часа на первичную настройку обычно окупаются к третьей неделе за счёт меньшего числа повторов и неудачных попыток. По сравнению с «всё в CLAUDE.md» счёт за токены и доля пропусков в долгую управляемее.

FAQ

Можно ли совместить Rules Claude Code и Cursor Rules?

Идея похожа, пути и формат — нет. Cursor использует .cursor/rules, Claude Code — .claude/rules/. Можно держать один Markdown-источник и скриптом зеркалить в оба каталога, но автосинхронизации нет.

Может ли Skill вызывать внешние скрипты?

Да. В каталоге Skill — папка scripts/, в тексте — указание выполнить; с allowed-tools: Bash(./scripts/*) меньше лишних подтверждений. Скрипты reviewьте как продакшен-код — не давайте агенту неаудированный shell.

Как команде ревьюить новые Rules и Skills?

В том же PR, что и код: новый .claude/rules/foo.md или skills/bar/SKILL.md требует человеческого review на конфликты с security Rules и дубли с CLAUDE.md. По документации Claude Code Settings skillOverrides позволяет временно отключить Skill без удаления файла.

Claude «забывает» шаги Skill после compaction — что делать?

Ранние вызовы Skill могут выпасть из общего бюджета. Меры: критичные шаги — в Hook; в конце Skill — вывод чеклиста в файл; релизные Skills с disable-model-invocation: true и короткой сессией.

Имеет ли смысл настраивать всё это в одиночку?

Да, но минимально: CLAUDE.md на ~50 строк, две Rules (безопасность + язык), один Skill для самой частой задачи (например, /ship). Плюс соло-разработчика — быстрая итерация: 15 минут в неделю на уборку конфигурации дешевле, чем снова набирать команды сборки в чате.

Итог: сначала workflow, потом файлы

Сочетание Rules, Skills и Workflow в Claude Code — это разбиение человеческого опыта на модули, которые машина может подгружать по правилам. CLAUDE.md отвечает на «что это за проект», Rules — на «что категорически нельзя», Skills — на «как пройти сложный сценарий», Workflow — на «когда это происходит автоматически». Четыре слоя прояснить заранее — проще, чем писать пятьсот строк промпта в первый день.

Рекомендуемый порядок: на этой неделе — скелет CLAUDE.md → на следующей — две security Rules → затем самый частый Skill → в конце Hook на облачном Mac или в CI. Каждый слой один раз прогоните на реальной задаче и замерьте токены и пропуски.