Мастер CLAUDE.md

---
name: claude-md-master
description: Главный навык для жизненного цикла CLAUDE.md: создание, обновление и улучшение на основе проверенных данных репозитория с поддержкой нескольких модулей. Используй при создании или обновлении файлов CLAUDE.md.
---

# Мастер CLAUDE.md (создание, обновление, улучшение)

## Когда использовать
- Пользователь просит создать, улучшить, обновить или стандартизировать файлы CLAUDE.md.

## Основные правила
- Включай только сведения, проверенные по репозиторию или конфигурации.
- Никогда не добавляй секреты, токены, учётные данные или пользовательские данные.
- Никогда не добавляй временные инструкции или правила для отдельной задачи.
- Пиши кратко: корневой файл — не более 200 строк, файл модуля — не более 120.
- Используй списки, избегай длинной прозы.
- Команды должны быть пригодны для копирования и взяты из документации, скриптов или CI репозитория.
- Пропускай пустые разделы, не добавляй текст ради объёма.

## Обязательные исходные данные (изучи перед созданием)
- Конфигурация сборки и пакетов для обнаруженного стека (корень и модули).
- Конфигурация статического анализа, если она есть.
- Фактическая структура модулей и паттерны исходного кода: проверь реальные каталоги и файлы.
- Характерные корни исходников каждого модуля, чтобы извлечь структуру пакетов и функций, ключевые типы и используемые аннотации.

## Исследование (быстрое и адресное)
1. Найди существующие варианты: `CLAUDE.md`, `.claude.md`, `.claude.local.md`.
2. Определи стек и точки входа с помощью минимального чтения:
   - `README.md`, нужные разделы `docs/*`;
   - файлы сборки и пакетов (см. справочники по стекам);
   - конфигурацию среды: `Dockerfile`, `docker-compose.yml`, `.env.example`, `config/*`;
   - CI: `.github/workflows/*`, `.gitlab-ci.yml`, `.circleci/*`.
3. Бери команды только если они существуют в скриптах, конфигурации или документации репозитория.
4. Определи структуру из нескольких модулей:
   - Android/Gradle: прочитай подключения в `settings.gradle` или `settings.gradle.kts`;
   - iOS: найди несколько targets/workspaces в `*.xcodeproj`/`*.xcworkspace`;
   - если у нескольких модулей или targets есть `src/` либо конфигурация сборки, запланируй для них отдельные CLAUDE.md.
5. Для каждого предполагаемого модуля прочитай файл сборки и минимум документации, чтобы узнать назначение, точки входа и команды.
6. Проверь корни исходников на:
   - верхнеуровневые каталоги пакетов или функций и правила разделения слоёв;
   - используемые ключевые аннотации и типы (по справочнику стека);
   - правила именования в кодовой базе.
7. Собери неочевидные рабочие процедуры и подводные камни из документации или повторяющихся паттернов кода.

Производительность:
- Предпочитай список файлов и адресное чтение.
- Не читай файл целиком, если достаточно раздела или символа.
- Пропускай большие каталоги: `node_modules`, `vendor`, `build`, `dist`.

## Справочники по стекам (шаблон 2)
Читай нужный справочник только при обнаружении признаков стека:
- Android/Gradle → `references/android.md`
- iOS/Xcode/Swift → `references/ios.md`
- PHP → `references/php.md`
- Go → `references/go.md`
- React (web) → `references/react-web.md`
- React Native → `references/react-native.md`
- Rust → `references/rust.md`
- Python → `references/python.md`
- Java/JVM → `references/java.md`
- Node tooling → `references/node.md`
- .NET/C# → `references/dotnet.md`
- Dart/Flutter → `references/flutter.md`
- Ruby/Rails → `references/ruby.md`
- Elixir/Erlang → `references/elixir.md`
- C/C++/CMake → `references/cpp.md`
- Другое или неизвестное → `references/generic.md` (запасной вариант, когда нет подходящего специального справочника)

Если обнаружено несколько стеков, читай несколько справочников. Если стек не распознан, используй общий справочник.

## Правило вывода для нескольких модулей (обязательно при их наличии)
- Всегда создавай корневой `CLAUDE.md`.
- Также создавай `CLAUDE.md` в корне каждого значимого модуля или target.
  - «Значимый» — со своей конфигурацией сборки и `src/` (или аналогом).
  - Пропускай каталоги только для инструментов: `buildSrc`, `gradle`, `scripts`, `tools`.
- Файл модуля должен описывать именно модуль и избегать повторов:
  - назначение, ключевые пути, точки входа, тесты и команды модуля, если они есть;
  - общую информацию подключай через `@/CLAUDE.md`.

## Правило CLAUDE.md для бизнес-модулей (все стеки)
Для каталогов бизнес-логики монорепозитория (`src/`, `lib/`, `packages/`, `internal/`):
- создавай `CLAUDE.md` для модулей, где больше пяти файлов ИЛИ есть собственный README;
- пропускай каталоги только со вспомогательным кодом: `Helper`, `Utils`, `Common`, `Shared`, `Exception`, `Trait`, `Constants`;
- слоистая структура не обязательна: описывай модуль независимо от архитектуры;
- не больше 120 строк на модульный CLAUDE.md;
- для общей архитектуры и паттернов ссылайся на корень через `@/CLAUDE.md`;
- включай назначение, структуру, ключевые классы, зависимости и точки входа.

## Обязательные разделы результата (в каждом модульном CLAUDE.md)
Включай эти разделы, если они обнаружены в кодовой базе; пропускай лишь при их отсутствии:
- **Перечень функций и компонентов:** верхнеуровневые каталоги в корне исходников.
- **Основные и общие модули:** каталоги вспомогательного или общего кода.
- **Навигация и маршруты:** графы навигации, маршруты или роутеры.
- **Шаблон сетевого/API-слоя:** клиенты API, конечные точки, оболочки ответов.
- **Шаблон DI/внедрения:** модули, контейнеры или настройка внедрения.
- **Файлы сборки и конфигурации:** конфигурация модуля (ProGuard, манифесты и т. д.).

Точные паттерны обнаружения и описания смотри в справочниках по стекам.

## Порядок обновления (обязателен)
1. Предлагай только точечные добавления; показывай различия для каждого файла.

2. До применения обновлений спрашивай разрешение:

**Cursor IDE:**
Используй инструмент AskQuestion с вариантами:
- id: "approval"
- prompt: "Применить эти обновления CLAUDE.md?"
- options: [{"id": "yes", "label": "Да, применить"}, {"id": "no", "label": "Нет, отменить"}]

**Claude Code (терминал):**
Покажи предлагаемые изменения и спроси:
«Одобряешь эти обновления? (yes/no)»
Остановись и дождись ответа пользователя.

**Другие окружения (запасной путь):**
Если структурированного инструмента вопросов нет:
1. Чётко покажи предлагаемые изменения.
2. Спроси: «Одобряешь эти обновления? Ответь yes, чтобы применить, или no, чтобы отменить».
3. Дождись явного подтверждения пользователя.

3. Примени изменения, сохраняя пользовательский текст.

Если CLAUDE.md отсутствует, предложи новый файл на утверждение.

## Правила извлечения содержания (обязательно)
- Только из кодовой базы:
  - извлекай используемые имена типов, классов и аннотаций, реальные шаблоны путей и правила именования;
  - никогда не извлекай жёстко заданные значения, секреты, ключи API и предметную бизнес-логику;
  - никогда не вставляй фрагменты кода в правила «Делай/Не делай».

## Проверка перед записью
- [ ] Каждое правило ссылается на реальные типы и пути кодовой базы.
- [ ] В разделах «Делай/Не делай» нет примеров кода.
- [ ] Паттерны соответствуют текущей кодовой базе, а не устарели.

## Правила содержания
- Включай команды, обзор архитектуры, ключевые пути, тестирование, подводные камни и особенности работы.
- Исключай общие советы, очевидные сведения и непроверенные утверждения.
- Используй импорты `@path/to/file`, чтобы избежать повторов.
- Формат «Делай/Не делай» необязателен; сохраняй его только если он уже использован в файле.
- Избегай примеров кода, кроме коротких команд для копирования.

## Стратегия для существующего файла
Определение:
- Если есть `<!-- Generated by claude-md-editor skill -->` → повторный запуск.
- Иначе → первый запуск.

Первый запуск при существующем файле:
- создай резервную копию `CLAUDE.md` → `CLAUDE.md.bak`;
- используй `.bak` как источник и извлекай только полезные сведения, относящиеся к проекту;
- создай новый краткий файл и добавь маркер.

Повторный запуск:
- сохраняй пользовательские разделы и формулировки, кроме устаревших и неверных;
- исправляй только то, что расходится с текущим состоянием репозитория;
- добавляй недостающие разделы, только если они дают реальную пользу.

Никогда не меняй `.claude.local.md`.

## Результат
После обновлений выведи краткий отчёт:
```
## Отчёт об обновлении CLAUDE.md
- /CLAUDE.md [CREATED | BACKED_UP+CREATED | UPDATED]
- /<module>/CLAUDE.md [CREATED | UPDATED]
- Резервные копии: перечисли все файлы `.bak`
```

## Контрольный список
- Описание конкретно и содержит слова-триггеры.
- Не осталось заполнителей.
- Не включены секреты.
- Соблюдено правило «сначала отчёт».
- Справочные файлы вложены не глубже одного уровня.

# claude-md-master

Главный навык для жизненного цикла CLAUDE.md: создание, обновление и улучшение
на основе проверенных данных репозитория, с поддержкой нескольких модулей и правил для разных стеков.

## Обзор
- Цель: создавать точные и краткие `CLAUDE.md` из реальных данных репозитория.
- Объём: корень и значимые модули с определением особенностей стека.
- Защита: без секретов и пустого текста; перед записью нужно явное одобрение.

## Как ИИ находит и применяет навык
- Обнаружение: инструмент узнаёт о навыке, потому что тот есть в каталоге навыков репозитория (установлен или доступен в окружении).
- Автоматическое применение: если запрос содержит «создать/обновить/улучшить CLAUDE.md», инструмент выбирает этот навык как наиболее подходящий.
- Ручной запуск: оператор может явно вызвать `/claude-md-master`, чтобы применить этот процесс.
- При работе навык изучает документацию, конфигурацию и исходники, предлагает изменения и ждёт явного согласия до записи файлов.

## Для кого
- Для операторов ИИ, применяющих навыки в Cursor или Claude Code.
- Для сопровождающих, которые развивают правила и справочники.

## Что делает
- Создаёт или обновляет `CLAUDE.md` с проверенным содержанием из репозитория.
- Соблюдает строгие правила безопасности и краткости: без секретов и пустого текста.
- Обнаруживает репозитории с несколькими модулями и создаёт модульные `CLAUDE.md`.
- Использует справочники по стекам, чтобы точно описать паттерны.

## Когда использовать
- Пользователь просит создать, улучшить, обновить или стандартизировать `CLAUDE.md`.
- Репозиторию нужны последовательные, проверенные инструкции для работы ИИ.

## Обязательные исходные данные (изучи их)
- Документация репозитория: `README.md`, `docs/*`, если есть.
- Файлы сборки и конфигурации для найденного стека или стеков.
- Конфигурация запуска: `Dockerfile`, `.env.example`, `config/*`, если есть.
- CI: `.github/workflows/*`, `.gitlab-ci.yml`, `.circleci/*`, если есть.
- Корни исходников, чтобы извлечь реальные структуру, типы, аннотации и имена.

## Результат
- Корневой `CLAUDE.md` — всегда.
- Модульные `CLAUDE.md` для значимых модулей (с конфигурацией сборки и `src/`).
- Краткий отчёт об изменениях с перечнем созданных и обновлённых файлов и резервных копий.

## Порядок работы (в общих чертах)
1. Найти существующие варианты `CLAUDE.md` и определить, первый это запуск или повторный.
2. Определить стек или стеки и структуру модулей.
3. Прочитать нужные документы, конфигурацию и CI ради реальных команд и процедур.
4. Проверить корни исходников на структуру, ключевые типы, аннотации и паттерны.
5. Создать корневой и модульные файлы без повторов, используя `@/CLAUDE.md`.
6. Перед применением изменений запросить явное одобрение.
7. Применить изменения и вывести отчёт.

## Основные правила и ограничения
- Только проверенные по репозиторию сведения; никаких секретов.
- Краткость: корень — не более 200 строк, модуль — не более 120.
- Команды должны быть реальными и пригодными для копирования из документации, скриптов или CI репозитория.
- Пропускай пустые разделы и общие советы.
- Никогда не меняй `.claude.local.md`.
- Не добавляй примеры кода в разделы «Делай/Не делай».

## Правило для нескольких модулей (кратко)
- Всегда создавай корневой `CLAUDE.md`.
- Отдельные модульные файлы создавай только для значимых модулей.
- Пропускай каталоги только для инструментов (например, `buildSrc`, `gradle`, `scripts`, `tools`).
- Бизнес-модулю нужен свой файл, если в нём более пяти файлов или есть собственный README.

## Справочники по стекам
Каждый справочник задаёт признаки обнаружения, источники для подготовки, цели проверки кодовой базы, обязательные пункты результата, источники команд и ключевые пути.

- `references/android.md` — Android/Gradle
- `references/ios.md` — iOS/Xcode/Swift
- `references/react-web.md` — веб-приложения React
- `references/react-native.md` — React Native
- `references/node.md` — инструменты Node в общем случае
- `references/python.md` — Python
- `references/java.md` — Java/JVM
- `references/dotnet.md` — .NET (C#/F#)
- `references/go.md` — Go
- `references/rust.md` — Rust
- `references/flutter.md` — Dart/Flutter
- `references/ruby.md` — Ruby/Rails
- `references/php.md` — PHP (Laravel/Symfony/CI/Phalcon)
- `references/elixir.md` — Elixir/Erlang
- `references/cpp.md` — C/C++
- `references/generic.md` — запасной вариант, если ни один стек не подошёл

## Расширение навыка
- Добавляй новый `references/<stack>.md` по тому же шаблону.
- Признаки обнаружения и обязательные пункты должны быть конкретными и проверяемыми.
- Не вводи непроверенные команды или общие советы.

## Контроль качества
- Каждое правило ссылается на реальные типы или пути репозитория.
- Нет незаполненных шаблонов.
- Нет секретов.
- Команды реальны и пригодны для копирования.
- Соблюдено правило «сначала отчёт»; справочники вложены на один уровень.

# Android (Gradle)

## Признаки обнаружения
- `settings.gradle` или `settings.gradle.kts`
- `build.gradle` или `build.gradle.kts`
- `gradle.properties`
- `gradle/libs.versions.toml`
- `gradlew`
- `gradle/wrapper/gradle-wrapper.properties`
- `app/src/main/AndroidManifest.xml`

## Признаки нескольких модулей
- Несколько записей `include(...)` или `includeBuild(...)` в `settings.gradle*`.
- Более одного каталога модуля с `build.gradle*` и `src/`.
- Общие корни модулей вроде `feature/`, `core/`, `library/`, если есть.

## Перед созданием изучи
- `settings.gradle` или `settings.gradle.kts`.
- `build.gradle` или `build.gradle.kts` в корне и модулях.
- `gradle/libs.versions.toml`.
- `gradle.properties`.
- `config/detekt/detekt.yml`, если есть.
- `app/src/main/AndroidManifest.xml` или манифесты модулей.

## Проверка кодовой базы (Android)
- Корни исходников по модулям: `*/src/main/java/`, `*/src/main/kotlin/`.
- Дерево пакетов для функций и слоёв (отмечай только при наличии):
  `features/`, `core/`, `common/`, `data/`, `domain/`, `presentation/`,
  `ui/`, `di/`, `navigation/`, `network/`.
- Используемые аннотации (отмечай только при наличии):
  Hilt (`@HiltAndroidApp`, `@AndroidEntryPoint`, `@HiltViewModel`,
  `@Module`, `@InstallIn`, `@Provides`, `@Binds`),
  Compose (`@Composable`, `@Preview`),
  Room (`@Entity`, `@Dao`, `@Database`),
  WorkManager (`@HiltWorker`, `ListenableWorker`, `CoroutineWorker`),
  сериализация (`@Serializable`, `@Parcelize`),
  Retrofit (`@GET`, `@POST`, `@PUT`, `@DELETE`, `@Body`, `@Query`).
- Навигационные паттерны (отмечай только при наличии): `NavHost`, `composable`.

## Обязательный результат (CLAUDE.md модуля Android)
Включай обнаруженное, перечисляя реальные имена:
- **Функции:** каталоги внутри `features/` (например, главная страница, оплата, аутентификация).
- **Основные модули:** каталоги внутри `core/` (например, данные, сеть, локализация).
- **Графы навигации:** файлы `*Graph.kt` или `*Navigator*.kt`.
- **Модули Hilt:** классы `@Module` или содержимое пакета `di/`.
- **API Retrofit:** интерфейсы `*Api.kt`.
- **Базы Room:** классы `@Database`.
- **Фоновые задачи:** классы `@HiltWorker`.
- **Proguard:** упомяни `proguard-rules.pro`, если он есть.

## Источники команд
- README, документация или CI с вызовом Gradle wrapper.
- Скрипты репозитория, вызывающие `./gradlew`.
- Использование `./gradlew assemble`, `./gradlew test`, `./gradlew lint` в документации или скриптах.
- Включай только команды, реально имеющиеся в репозитории.

## Ключевые пути (только при наличии)
- `app/src/main/`, `app/src/main/res/`
- `app/src/main/java/`, `app/src/main/kotlin/`
- `app/src/test/`, `app/src/androidTest/`

# C / C++

## Признаки обнаружения
- `CMakeLists.txt`
- `meson.build`
- `Makefile`
- `conanfile.*`, `vcpkg.json`
- `compile_commands.json`
- `src/`, `include/`

## Признаки нескольких модулей
- `CMakeLists.txt` с `add_subdirectory(...)`.
- Несколько `CMakeLists.txt` или `meson.build` во вложенных каталогах.
- `libs/`, `apps/` или `modules/` с собственными файлами сборки.

## Перед созданием изучи
- `CMakeLists.txt` / `meson.build` / `Makefile`.
- `conanfile.*`, `vcpkg.json`, если есть.
- `compile_commands.json`, если есть.
- `src/`, `include/`, `tests/`, `libs/`.

## Проверка кодовой базы (C/C++)
- Корни исходников: `src/`, `include/`, `tests/`, `libs/`.
- Разделение библиотек и приложений (отмечай только при наличии): `src/lib`, `src/app`, `src/bin`.
- Пространства имён и префиксы классов — только если встречаются.
- Цели CMake (отмечай только при наличии): `add_library`, `add_executable`.

## Обязательный результат (CLAUDE.md модуля C/C++)
Включай обнаруженное, перечисляя реальные имена:
- **Библиотеки:** цели библиотек.
- **Исполняемые файлы:** исполняемые цели.
- **Заголовки:** каталоги открытых заголовочных файлов.
- **Модули и компоненты:** подкаталоги с файлами сборки.
- **Зависимости:** зависимости Conan/vcpkg, если есть.

## Источники команд
- README, документация или CI с вызовами `cmake`, `ninja`, `make` или `meson`.
- Скрипты репозитория, вызывающие инструменты сборки.
- Включай только команды, реально имеющиеся в репозитории.

## Ключевые пути (только при наличии)
- `src/`, `include/`
- `tests/`, `libs/`

# .NET (C# / F#)

## Признаки обнаружения
- `*.sln`
- `*.csproj`, `*.fsproj`, `*.vbproj`
- `global.json`
- `Directory.Build.props`, `Directory.Build.targets`
- `nuget.config`
- `Program.cs`
- `Startup.cs`
- `appsettings*.json`

## Признаки нескольких модулей
- `*.sln` с несколькими проектами.
- Несколько файлов `*.*proj` в `src/` и `tests/`.
- `Directory.Build.*`, управляющий общими настройками проектов.

## Перед созданием изучи
- `*.sln`, `*.csproj` / `*.fsproj` / `*.vbproj`.
- `Directory.Build.props`, `Directory.Build.targets`.
- `global.json`, `nuget.config`.
- `Program.cs` / `Startup.cs`.
- `appsettings*.json`.

## Проверка кодовой базы (.NET)
- Корни исходников: `src/`, `tests/`, каталоги проектов с `*.csproj`.
- Каталоги слоёв (отмечай только при наличии): `Controllers`, `Services`, `Repositories`, `Domain`, `Infrastructure`.
- Атрибуты ASP.NET (отмечай только при наличии): `[ApiController]`, `[Route]`, `[HttpGet]`, `[HttpPost]`, `[Authorize]`.
- Использование EF Core (отмечай только при наличии): `DbContext`, `Migrations`, `[Key]`, `[Table]`.

## Обязательный результат (CLAUDE.md модуля .NET)
Включай обнаруженное, перечисляя реальные имена:
- **Контроллеры:** классы `[ApiController]`.
- **Сервисы:** классы сервисов.
- **Репозитории:** классы репозиториев.
- **Сущности:** классы сущностей EF Core.
- **DbContext:** классы контекстов базы данных.
- **Middleware:** собственные компоненты промежуточной обработки.
- **Конфигурация:** разделы конфигурации или классы настроек.

## Источники команд
- README, документация или CI с вызовом `dotnet`.
- Скрипты репозитория, например `build.ps1` и `build.sh`.
- Использование `dotnet run` и `dotnet test` в документации или скриптах.
- Включай только команды, реально имеющиеся в репозитории.

## Ключевые пути (только при наличии)
- `src/`, `tests/`
- `appsettings*.json`
- `Controllers/`, `Models/`, `Views/`, `wwwroot/`

# Elixir / Erlang

## Признаки обнаружения
- `mix.exs`, `mix.lock`
- `config/config.exs`
- `lib/`, `test/`
- `apps/` (umbrella-проект)
- `rel/`

## Признаки нескольких модулей
- Umbrella-проект с несколькими `mix.exs` в `apps/`.
- Корневой `mix.exs` с `apps_path`.

## Перед созданием изучи
- Корневые `mix.exs` и `mix.lock`.
- `config/config.exs`.
- `apps/*/mix.exs` для umbrella-проекта.
- `lib/`, `test/`, `rel/`.

## Проверка кодовой базы (Elixir)
- Корни исходников: `lib/`, `test/`, `apps/*/lib` для umbrella-проекта.
- Структура Phoenix (отмечай только при наличии): `lib/*_web/`, `controllers`, `views`, `channels`, `routers`.
- Использование Ecto (отмечай только при наличии): `schema`, `Repo`, `migrations`.
- Контексты и модули (отмечай только при наличии): модули контекстов в `lib/*/` и `*_context.ex`.

## Обязательный результат (CLAUDE.md модуля Elixir)
Включай обнаруженное, перечисляя реальные имена:
- **Контексты:** модули контекстов.
- **Схемы:** модули схем Ecto.
- **Контроллеры:** модули контроллеров Phoenix.
- **Каналы:** модули каналов Phoenix.
- **Фоновые задачи:** модули фоновых задач (Oban и другие).
- **Umbrella-приложения:** приложения внутри umbrella-проекта, если есть.

## Источники команд
- README, документация или CI с вызовом `mix`.
- Скрипты репозитория, вызывающие `mix`.
- Включай только команды, реально имеющиеся в репозитории.

## Ключевые пути (только при наличии)
- `lib/`, `test/`, `config/`
- `apps/`, `rel/`

# Dart / Flutter

## Признаки обнаружения
- `pubspec.yaml`, `pubspec.lock`
- `analysis_options.yaml`
- `lib/`
- `android/`, `ios/`, `web/`, `macos/`, `windows/`, `linux/`

## Признаки нескольких модулей
- `melos.yaml` (монорепозиторий Flutter).
- Несколько `pubspec.yaml` в `packages/`, `apps/` или `plugins/`.

## Перед созданием изучи
- `pubspec.yaml`, `pubspec.lock`.
- `analysis_options.yaml`.
- `melos.yaml`, если это монорепозиторий.
- `lib/`, `test/` и платформенные каталоги (`android/`, `ios/` и другие).

## Проверка кодовой базы (Flutter)
- Корни исходников: `lib/`, `test/`.
- Точка входа (отмечай только при наличии): `lib/main.dart`.
- Каталоги слоёв (отмечай только при наличии): `features/`, `core/`, `data/`, `domain/`, `presentation/`.
- Управление состоянием (отмечай только при наличии): `Bloc`, `Cubit`, `ChangeNotifier`, `Provider`, `Riverpod`.
- Именование виджетов (отмечай только при наличии): `*Screen`, `*Page`.

## Обязательный результат (CLAUDE.md модуля Flutter)
Включай обнаруженное, перечисляя реальные имена:
- **Функции:** каталоги в `features/` или `lib/`.
- **Основные модули:** каталоги в `core/`, если есть.
- **Управление состоянием:** конфигурация Bloc/Cubit/Provider.
- **Репозитории:** классы репозиториев.
- **Источники данных:** классы удалённых и локальных источников данных.
- **Виджеты:** каталоги общих виджетов.

## Источники команд
- README, документация или CI с вызовом `flutter`.
- Скрипты репозитория, вызывающие `flutter` или `dart`.
- Использование `flutter run`, `flutter test`, `flutter pub get` в документации или скриптах.
- Включай только команды, реально имеющиеся в репозитории.

## Ключевые пути (только при наличии)
- `lib/`, `test/`
- `android/`, `ios/`

# Общий или неизвестный стек

Используй этот справочник, если не подошёл ни один справочник для конкретного стека.

## Признаки обнаружения (общие паттерны)
- `README.md`, `CONTRIBUTING.md`
- `Makefile`, `Taskfile.yml`, `justfile`
- `Dockerfile`, `docker-compose.yml`
- `.env.example`, `config/`
- Файлы CI: `.github/workflows/`, `.gitlab-ci.yml`, `.circleci/`

## Перед созданием изучи
- `README.md`: обзор проекта, инструкции по настройке, команды.
- Файлы сборки и пакетов в корне (любой распознаваемый формат).
- `Makefile`, `Taskfile.yml`, `justfile`, `scripts/`, если есть.
- Конфигурацию CI/CD для команд сборки и тестирования.
- `Dockerfile` ради сведений о среде выполнения.

## Проверка кодовой базы (общая)
- Определи корень исходников: `src/`, `lib/`, `app/`, `pkg/` или корень репозитория.
- Каталоги слоёв (отмечай только при наличии): `controllers`, `services`, `models`, `handlers`, `utils`, `config`.
- Точки входа: `main.*`, `index.*`, `app.*`, `server.*`.
- Расположение тестов: `tests/`, `test/`, `spec/`, `__tests__/` или рядом с кодом.

## Обязательный результат (общий CLAUDE.md)
Включай обнаруженное, перечисляя реальные имена:
- **Точки входа:** основные файлы и скрипты запуска.
- **Структура исходников:** верхнеуровневые каталоги под корнем исходников.
- **Файлы конфигурации:** окружение, настройки, шаблон секретов.
- **Система сборки:** найденный инструмент и путь к его конфигурации.
- **Тестирование:** тестовый фреймворк и команда запуска.

## Источники команд
- Разделы README о настройке и использовании.
- Цели `Makefile`, задачи `Taskfile.yml`, рецепты `justfile`.
- Шаги CI (сборка, тесты, линтер).
- Каталог `scripts/`.
- Включай только команды, реально имеющиеся в репозитории.

## Ключевые пути (только при наличии)
- Корень исходников и его верхнеуровневая структура.
- Файлы конфигурации и окружения.
- Каталог тестов.
- Расположение документации.
- Каталог результатов сборки.

# Go

## Признаки обнаружения
- `go.mod`, `go.sum`, `go.work`
- `cmd/`, `internal/`
- `main.go`
- `magefile.go`
- `Taskfile.yml`

## Признаки нескольких модулей
- `go.work` с путями к нескольким модулям.
- Несколько файлов `go.mod` во вложенных каталогах.
- `apps/` или `services/`, где у каждого проекта свой `go.mod`.

## Перед созданием изучи
- `go.work`, `go.mod`, `go.sum`.
- Структуру `cmd/`, `internal/`, `pkg/`.
- `Makefile`, `Taskfile.yml`, `magefile.go`, если есть.

## Проверка кодовой базы (Go)
- Корни исходников: `cmd/`, `internal/`, `pkg/`, `api/`.
- Каталоги слоёв (отмечай только при наличии): `handler`, `service`, `repository`, `store`, `config`.
- Признаки фреймворков (отмечай только при наличии): импорты `gin`, `echo`, `fiber`, `chi`.
- Точки входа (отмечай только при наличии): `cmd/*/main.go`, `main.go`.

## Обязательный результат (CLAUDE.md модуля Go)
Включай обнаруженное, перечисляя реальные имена:
- **Команды:** исполняемые программы в `cmd/`.
- **Обработчики:** пакеты HTTP-обработчиков.
- **Сервисы:** пакеты сервисов.
- **Репозитории:** пакеты репозиториев или хранилищ.
- **Модели:** пакеты предметных моделей.
- **Конфигурация:** пакеты загрузки настроек.

## Источники команд
- README, документация или CI.
- `Makefile`, `Taskfile.yml` или скрипты репозитория с вызовом инструментов Go.
- Использование `go test ./...` и `go run` в документации или скриптах.
- Включай только команды, реально имеющиеся в репозитории.

## Ключевые пути (только при наличии)
- `cmd/`, `internal/`, `pkg/`, `api/`
- Структура `tests/` или `*_test.go`

# iOS (Xcode/Swift)

## Признаки обнаружения
- `Package.swift`
- `*.xcodeproj` или `*.xcworkspace`
- `Podfile`, `Cartfile`
- `Project.swift`, `Tuist/`
- `fastlane/Fastfile`
- `*.xcconfig`
- `Sources/` или `Tests/` (структура SPM)

## Признаки нескольких модулей
- Несколько targets или проектов в `*.xcworkspace` либо `*.xcodeproj`.
- `Package.swift` с несколькими targets или продуктами.
- Структура `Sources/<TargetName>` и `Tests/<TargetName>`.
- `Project.swift`, определяющий несколько targets (Tuist).

## Перед созданием изучи
- `Package.swift` (SPM).
- `*.xcodeproj/project.pbxproj` или `*.xcworkspace/contents.xcworkspacedata`.
- `Podfile`, `Cartfile`, если есть.
- `Project.swift` / `Tuist/`, если есть.
- `fastlane/Fastfile`, если есть.
- Структуру `Sources/` и `Tests/` по targets.

## Проверка кодовой базы (iOS)
- Корни исходников: `Sources/`, `Tests/`, `ios/`, если есть.
- Каталоги функций и слоёв (отмечай только при наличии): `Features/`, `Core/`, `Services/`, `Networking/`, `UI/`, `Domain/`, `Data/`.
- Использование SwiftUI (отмечай только при наличии): `@main`, `App`, `@State`, `@StateObject`, `@ObservedObject`, `@Environment`, `@EnvironmentObject`, `@Binding`.
- UIKit и жизненный цикл (отмечай только при наличии): `UIApplicationDelegate`, `SceneDelegate`, `UIViewController`.
- Combine и конкурентность (отмечай только при наличии): `@Published`, `Publisher`, `AnyCancellable`, `@MainActor`, `Task`.

## Обязательный результат (CLAUDE.md модуля iOS)
Включай обнаруженное, перечисляя реальные имена:
- **Функции:** каталоги в `Features/` или соответствующие targets.
- **Основные модули:** каталоги в `Core/`, `Services/`, `Networking/`.
- **Навигация:** координаторы, роутеры или файлы навигации SwiftUI.
- **Контейнер DI:** настройка внедрения зависимостей (Swinject, Factory или собственные контейнеры).
- **Сетевой слой:** клиенты API или сетевые сервисы.
- **Хранение:** модели CoreData или другие классы хранилищ.

## Источники команд
- README, документация или CI с вызовом инструментов Xcode или Swift.
- Скрипты репозитория с вызовом инструментов Xcode/Swift.
- Использование `xcodebuild`, `swift build`, `swift test` в документации или скриптах.
- Включай только команды, реально имеющиеся в репозитории.

## Ключевые пути (только при наличии)
- `Sources/`, `Tests/`
- `fastlane/`
- `ios/` (React Native или многоплатформенные репозитории)

# Java / JVM

## Признаки обнаружения
- `pom.xml` или `build.gradle*`
- `settings.gradle`, `gradle.properties`
- `mvnw`, `gradlew`
- `gradle/wrapper/gradle-wrapper.properties`
- `src/main/java`, `src/test/java`, `src/main/kotlin`
- `src/main/resources/application.yml`, `src/main/resources/application.properties`

## Признаки нескольких модулей
- `settings.gradle*` подключает несколько модулей.
- Родительский `pom.xml` с `<modules>` (тип пакета `pom`).
- Несколько файлов `build.gradle*` или `pom.xml` во вложенных каталогах.

## Перед созданием изучи
- `settings.gradle*` и `build.gradle*` для Gradle.
- Родительский и модульные `pom.xml` для Maven.
- `gradle/libs.versions.toml`, если есть.
- `gradle.properties` / `mvnw` / `gradlew`.
- `src/main/resources/application.yml|application.properties`, если есть.

## Проверка кодовой базы (Java/JVM)
- Корни исходников: `src/main/java`, `src/main/kotlin`, `src/test/java`, `src/test/kotlin`.
- Каталоги пакетов и слоёв (отмечай только при наличии): `controller`, `service`, `repository`, `domain`, `model`, `dto`, `config`, `client`.
- Аннотации фреймворков (отмечай только при наличии): `@SpringBootApplication`, `@RestController`, `@Controller`, `@Service`, `@Repository`, `@Component`, `@Configuration`, `@Bean`, `@Transactional`.
- Хранение и валидация (отмечай только при наличии): `@Entity`, `@Table`, `@Id`, `@OneToMany`, `@ManyToOne`, `@Valid`, `@NotNull`.
- Точки входа (отмечай только при наличии): классы `*Application` с `main`.

## Обязательный результат (CLAUDE.md модуля Java/JVM)
Включай обнаруженное, перечисляя реальные имена:
- **Контроллеры:** классы `@RestController` или `@Controller`.
- **Сервисы:** классы `@Service`.
- **Репозитории:** классы `@Repository` или интерфейсы JPA.
- **Сущности:** классы `@Entity`.
- **Конфигурация:** классы `@Configuration`.
- **Безопасность:** конфигурация защиты или фильтры аутентификации.
- **Профили:** используемые профили Spring.

## Источники команд
- Скрипты-обёртки Maven/Gradle.
- README, документация или CI.
- Использование `./mvnw spring-boot:run` и `./gradlew bootRun` в документации или скриптах.
- Включай только команды, реально имеющиеся в репозитории.

## Ключевые пути (только при наличии)
- `src/main/java`, `src/test/java`
- `src/main/kotlin`, `src/test/kotlin`
- `src/main/resources`, `src/test/resources`
- `src/main/java/**/controller`, `src/main/java/**/service`, `src/main/java/**/repository`

# Инструменты Node (общий случай)

## Признаки обнаружения
- `package.json`
- `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`
- `.nvmrc`, `.node-version`
- `tsconfig.json`
- `.npmrc`, `.yarnrc.yml`
- `next.config.*`, `nuxt.config.*`
- `nest-cli.json`, `svelte.config.*`, `astro.config.*`

## Признаки нескольких модулей
- `pnpm-workspace.yaml`, `lerna.json`, `nx.json`, `turbo.json`, `rush.json`.
- Корневой `package.json` с `workspaces`.
- Несколько `package.json` в `apps/` и `packages/`.

## Перед созданием изучи
- Корневой `package.json` и конфигурацию рабочих пространств (`pnpm-workspace.yaml`, `lerna.json`, `nx.json`, `turbo.json`, `rush.json`).
- `apps/*/package.json`, `packages/*/package.json`, если это монорепозиторий.
- `tsconfig.json` или `jsconfig.json`.
- Конфигурацию фреймворка: `next.config.*`, `nuxt.config.*`, `nest-cli.json`, `svelte.config.*`, `astro.config.*`, если есть.

## Проверка кодовой базы (Node)
- Корни исходников: `src/`, `lib/`, `apps/`, `packages/`.
- Паттерны каталогов (отмечай только при наличии): `routes`, `controllers`, `services`, `middlewares`, `handlers`, `utils`, `config`, `models`, `schemas`.
- Признаки фреймворков (отмечай только при наличии): Express (`express()`, `Router`), Koa (`new Koa()`), Fastify (`fastify()`), Nest (`@Controller`, `@Module`, `@Injectable`).
- Структура полностековых приложений (отмечай только при наличии): Next/Nuxt (`pages/`, `app/`, `server/`).

## Обязательный результат (CLAUDE.md модуля Node)
Включай обнаруженное, перечисляя реальные имена:
- **Маршруты и страницы:** файлы маршрутов или компоненты страниц.
- **Контроллеры и обработчики:** соответствующие файлы.
- **Сервисы:** классы или модули сервисов.
- **Middleware:** файлы промежуточной обработки.
- **Модели и схемы:** модели данных или схемы валидации.
- **Управление состоянием:** настройка хранилища (Redux, Zustand и другие).
- **Клиенты API:** модули клиентов внешних API.

## Источники команд
- Скрипты `package.json`.
- README, документация или CI.
- Использование скриптов `npm|yarn|pnpm` в документации или скриптах.
- Включай только команды, реально имеющиеся в репозитории.

## Ключевые пути (только при наличии)
- `src/`, `lib/`
- `tests/`
- `apps/`, `packages/` (монорепозитории)
- `pages/`, `app/`, `server/`, `api/`
- `controllers/`, `services/`

# PHP

## Признаки обнаружения
- `composer.json`, `composer.lock`
- `public/index.php`
- `artisan`, `spark`, `bin/console` (точки входа фреймворков)
- `phpunit.xml`, `phpstan.neon`, `phpstan.neon.dist`, `psalm.xml`
- `config/app.php`
- `routes/web.php`, `routes/api.php`
- `config/packages/` (Symfony)
- `app/Config/` (CI4)
- `ext-phalcon` в composer.json (Phalcon)
- `phalcon/ide-stubs`, `phalcon/devtools` (Phalcon)

## Признаки нескольких модулей
- `modules/` или `app/Modules/` (структура HMVC).
- `app/Config/Modules.php`, `app/Config/Autoload.php` (CI4).
- Несколько корней PSR-4 в `composer.json`.
- Несколько `composer.json` в `packages/` или `apps/`.
- `apps/` с подкаталогами, содержащими `Module.php` или `controllers/`.

## Перед созданием изучи
- `composer.json`, `composer.lock`.
- `config/` и `routes/` (конфигурация фреймворка).
- `app/Config/*` (CI4).
- `modules/` или `app/Modules/` для HMVC.
- `phpunit.xml`, `phpstan.neon*`, `psalm.xml`, если есть.
- `bin/worker.php`, `bin/console.php` (точки входа CLI).

## Проверка кодовой базы (PHP)
- Корни исходников: `app/`, `src/`, `modules/`, `packages/`, `apps/`.
- Структура Laravel (отмечай только при наличии): `app/Http/Controllers`, `app/Models`, `database/migrations`, `routes/*.php`, `resources/views`.
- Структура Symfony (отмечай только при наличии): `src/Controller`, `src/Entity`, `config/packages`, `templates`.
- Структура CodeIgniter (отмечай только при наличии): `app/Controllers`, `app/Models`, `app/Views`, `app/Config/Routes.php`, `app/Database/Migrations`.
- Структура Phalcon (отмечай только при наличии): `apps/*/controllers/`, `apps/*/Module.php`, `models/`.
- Атрибуты и аннотации (отмечай только при наличии): `#[Route]`, `#[Entity]`, `#[ORM\Column]`.

## Обнаружение бизнес-модулей
Проверяй пути в соответствии с найденным фреймворком:
- Laravel: `app/Services/`, `app/Domains/`, `app/Modules/`, `packages/`.
- Symfony: верхнеуровневые каталоги `src/`.
- CodeIgniter: `app/Modules/`, `modules/`.
- Phalcon: `src/`, `apps/*/`.
- Общий случай: `src/`, `lib/`.

Для каждого пути:
- перечисли 5–10 крупнейших модулей по числу файлов;
- для каждого значимого модуля (больше пяти файлов) укажи назначение, если его можно понять по имени;
- отметь слоистые паттерны, если есть: `*/Repository/`, `*/Service/`, `*/Controller/`, `*/Action/`.

## Признаки модульного CLAUDE.md
Ищи значимые модули в следующих путях с учётом фреймворка:
- `src/` — Symfony, Phalcon, собственные фреймворки;
- `app/Services/`, `app/Domains/` — предметная структура Laravel;
- `app/Modules/`, `modules/` — HMVC в Laravel/CI4;
- `packages/` — внутренние пакеты Laravel;
- `apps/` — несколько приложений Phalcon.

Создавай `<path>/<Module>/CLAUDE.md`, если:
- модуль содержит больше пяти файлов ИЛИ собственный `README.md`;
- это не вспомогательный каталог: пропускай `Helper/`, `Exception/`, `Trait/`, `Contract/`, `Interface/`, `Constants/`, `Support/`;
- слоистая структура не обязательна: описывай модуль независимо от архитектуры.

### Содержание модульного CLAUDE.md (не более 120 строк)
- Назначение: описание модуля в одном-двух предложениях.
- Структура: список подкаталогов (Service/, Repository/ и другие).
- Ключевые классы: основные классы сервисов, менеджеров и действий.
- Зависимости: другие модули, от которых он зависит (по операторам use).
- Точки входа: основные открытые интерфейсы и фасады.
- Особенности фреймворка: ServiceProvider (Laravel), Module.php (Phalcon/CI4).

## Обнаружение фоновых задач
- `bin/worker.php` или похожие точки входа обработчика.
- Каталоги `*/Job/`, `*/Jobs/`, `*/Worker/`.
- Файлы конфигурации очередей (`queue.php`, `rabbitmq.php`, `amqp.php`).
- Если есть, перечисли классы фоновых задач.

## Обнаружение версий API
- Паттерны `routes_v*.php` или `routes/v*/`.
- Структура каталогов `controllers/v*/`.
- Определи текущую или активную версию API по файлам маршрутов либо конфигурации.

## Обязательный результат (CLAUDE.md модуля PHP)
Включай обнаруженное, перечисляя реальные имена:
- **Контроллеры:** каталоги и классы контроллеров.
- **Модели:** классы моделей и сущностей или каталог.
- **Сервисы:** классы сервисов или каталог.
- **Репозитории:** классы репозиториев или каталог.
- **Маршруты:** файлы маршрутов и паттерн версионирования.
- **Миграции:** каталог миграций и число файлов.
- **Middleware:** классы промежуточной обработки.
- **Представления и шаблоны:** шаблонизатор и структура.
- **Фоновые задачи:** классы, если есть.
- **Бизнес-модули:** крупнейшие модули по размеру в обнаруженных путях.

## Источники команд
- Скрипты `composer.json`.
- README, документация или CI.
- Использование `php artisan` и `bin/console` в документации или скриптах.
- Команды `bin/worker.php`.
- Включай только команды, реально имеющиеся в репозитории.

## Ключевые пути (только при наличии)
- `app/`, `src/`, `apps/`
- `public/`, `routes/`, `config/`, `database/`
- `app/Http/`, `resources/`, `storage/` (Laravel)
- `templates/` (Symfony)
- `app/Controllers/`, `app/Views/` (CI4)
- `apps/*/controllers/`, `models/` (Phalcon)
- `tests/`, `tests/acceptance/`, `tests/unit/`

# Python

## Признаки обнаружения
- `pyproject.toml`
- `requirements.txt`, `requirements-dev.txt`, `Pipfile`, `poetry.lock`
- `tox.ini`, `pytest.ini`
- `manage.py`
- `setup.py`, `setup.cfg`
- `settings.py`, `urls.py` (Django)

## Признаки нескольких модулей
- Несколько `pyproject.toml`/`setup.py`/`setup.cfg` во вложенных каталогах.
- `packages/` или `apps/`, где у каждого свой файл конфигурации пакета.
- `apps/` в стиле Django с несколькими `apps.py`, если есть.

## Перед созданием изучи
- `pyproject.toml` или `setup.py` / `setup.cfg`.
- `requirements*.txt`, `Pipfile`, `poetry.lock`.
- `tox.ini`, `pytest.ini`.
- `manage.py`, `settings.py`, `urls.py`, если это Django.
- Корни пакетов в `src/`, `app/`, `packages/`, если есть.

## Проверка кодовой базы (Python)
- Корни исходников: `src/`, `app/`, `packages/`, `tests/`.
- Паттерны каталогов (отмечай только при наличии): `api`, `routers`, `views`, `services`, `repositories`, `models`, `schemas`, `utils`, `config`.
- Структура Django (отмечай только при наличии): `apps.py`, `models.py`, `views.py`, `urls.py`, `migrations/`, `settings.py`.
- Признаки FastAPI/Flask (отмечай только при наличии): `FastAPI()`, `APIRouter`, `@app.get`, `@router.post`, `Flask(__name__)`, `Blueprint`.
- Использование типизированных моделей (отмечай только при наличии): `pydantic.BaseModel`, `TypedDict`, `dataclass`.

## Обязательный результат (CLAUDE.md модуля Python)
Включай обнаруженное, перечисляя реальные имена:
- **Роутеры и представления:** файлы роутеров API или представлений.
- **Сервисы:** модули сервисов.
- **Модели и схемы:** модели данных Pydantic, SQLAlchemy, Django.
- **Репозитории:** модули репозиториев или DAO.
- **Миграции:** каталог миграций.
- **Middleware:** классы промежуточной обработки.
- **Приложения Django:** установленные приложения, если это Django.

## Источники команд
- Разделы инструментов в `pyproject.toml`.
- README, документация или CI.
- Скрипты репозитория, вызывающие инструменты Python.
- Использование `python manage.py`, `pytest`, `tox` в документации или скриптах.
- Включай только команды, реально имеющиеся в репозитории.

## Ключевые пути (только при наличии)
- `src/`, `app/`, `scripts/`
- `templates/`, `static/`
- `tests/`

# React Native

## Признаки обнаружения
- `package.json` с `react-native`
- `react-native.config.js`
- `metro.config.js`
- `ios/`, `android/`
- `babel.config.js`, `app.json`, `app.config.*`
- `eas.json`, `expo` в `package.json`

## Признаки нескольких модулей
- `pnpm-workspace.yaml`, `lerna.json`, `nx.json`, `turbo.json`.
- Корневой `package.json` с `workspaces`.
- `packages/` или `apps/`, где у каждого свой `package.json`.

## Перед созданием изучи
- Корневой `package.json` и конфигурацию рабочих пространств (`pnpm-workspace.yaml`, `lerna.json`, `nx.json`, `turbo.json`).
- `react-native.config.js`, `metro.config.js`.
- Нативные каталоги `ios/` и `android/`.
- `app.json` / `app.config.*` / `eas.json`, если используется Expo.

## Проверка кодовой базы (React Native)
- Корни исходников: `src/`, `app/`.
- Точки входа (отмечай только при наличии): `index.js`, `index.ts`, `App.tsx`.
- Нативные каталоги (отмечай только при наличии): `ios/`, `android/`.
- Навигация и состояние (отмечай только при наличии): `react-navigation`, `redux`, `mobx`.
- Паттерны нативных модулей (отмечай только при наличии): `NativeModules`, `TurboModule`.

## Обязательный результат (CLAUDE.md модуля React Native)
Включай обнаруженное, перечисляя реальные имена:
- **Экраны и навигаторы:** компоненты экранов и навигаторы.
- **Компоненты:** каталоги общих компонентов.
- **Сервисы и API:** модули клиентов API.
- **Управление состоянием:** настройка хранилища.
- **Нативные модули:** собственные нативные модули.
- **Платформенные каталоги:** настройка ios/ и android/.

## Источники команд
- Скрипты `package.json`.
- README, документация или CI.
- Файлы нативной сборки в `ios/` и `android/`.
- Использование скриптов `expo` в документации или скриптах, если используется Expo.
- Включай только команды, реально имеющиеся в репозитории.

## Ключевые пути (только при наличии)
- `ios/`, `android/`
- `src/`, `app/`

# React (веб)

## Признаки обнаружения
- `package.json`
- `src/`, `public/`
- `vite.config.*`, `next.config.*`, `webpack.config.*`
- `tsconfig.json`
- `turbo.json`
- `app/` или `pages/` (Next.js)

## Признаки нескольких модулей
- `pnpm-workspace.yaml`, `lerna.json`, `nx.json`, `turbo.json`.
- Корневой `package.json` с `workspaces`.
- `apps/` и `packages/`, где у каждого свой `package.json`.

## Перед созданием изучи
- Корневой `package.json` и конфигурацию рабочих пространств (`pnpm-workspace.yaml`, `lerna.json`, `nx.json`, `turbo.json`).
- `apps/*/package.json`, `packages/*/package.json`, если это монорепозиторий.
- `vite.config.*`, `next.config.*`, `webpack.config.*`.
- `tsconfig.json` / `jsconfig.json`.

## Проверка кодовой базы (веб на React)
- Корни исходников: `src/`, `app/`, `pages/`, `components/`, `hooks/`, `services/`.
- Паттерны каталогов (отмечай только при наличии): `routes`, `store`, `state`, `api`, `utils`, `assets`.
- Признаки маршрутизации (отмечай только при наличии): React Router (`Routes`, `Route`), Next (`app/`, `pages/`).
- Управление состоянием (отмечай только при наличии): `redux`, `zustand`, `recoil`.
- Правила именования (отмечай только при наличии): hooks `use*`, компоненты PascalCase.

## Обязательный результат (CLAUDE.md веб-модуля React)
Включай обнаруженное, перечисляя реальные имена:
- **Страницы и маршруты:** компоненты страниц или файлы маршрутов.
- **Компоненты:** каталоги общих компонентов.
- **Хуки:** собственные хуки.
- **Сервисы и API:** модули клиентов API.
- **Управление состоянием:** настройка хранилища (Redux, Zustand и другие).
- **Утилиты:** вспомогательные модули.

## Источники команд
- Скрипты `package.json`.
- README, документация или CI.
- Включай только команды, реально имеющиеся в репозитории.

## Ключевые пути (только при наличии)
- `src/`, `public/`
- `app/`, `pages/`, `components/`
- `hooks/`, `services/`
- `apps/`, `packages/` (монорепозитории)

# Ruby / Rails

## Признаки обнаружения
- `Gemfile`, `Gemfile.lock`
- `Rakefile`
- `config.ru`
- `bin/rails` или `bin/rake`
- `config/application.rb`
- `config/routes.rb`

## Признаки нескольких модулей
- Несколько `Gemfile` или файлов `.gemspec` во вложенных каталогах.
- `gems/`, `packages/` или `engines/` с отдельными спецификациями gem.
- Несколько приложений Rails в `apps/`, каждое с `config/application.rb`.

## Перед созданием изучи
- `Gemfile`, `Gemfile.lock` и все `.gemspec`.
- `config/application.rb`, `config/routes.rb`.
- `Rakefile` / `bin/rails`, если есть.
- `engines/`, `gems/`, `apps/`, если несколько приложений или движков.

## Проверка кодовой базы (Ruby/Rails)
- Корни исходников: `app/`, `lib/`, `engines/`, `gems/`.
- Слои Rails (отмечай только при наличии): `app/models`, `app/controllers`, `app/views`, `app/jobs`, `app/services`.
- Конфигурация и инициализаторы (отмечай только при наличии): `config/routes.rb`, `config/application.rb`, `config/initializers/`.
- ActiveRecord и миграции (отмечай только при наличии): `db/migrate`, `ActiveRecord::Base`.
- Тесты (отмечай только при наличии): `spec/`, `test/`.

## Обязательный результат (CLAUDE.md модуля Ruby)
Включай обнаруженное, перечисляя реальные имена:
- **Контроллеры:** классы контроллеров.
- **Модели:** модели ActiveRecord.
- **Сервисы:** объекты-сервисы.
- **Фоновые задачи:** их классы.
- **Маршруты:** основные пространства имён маршрутов.
- **Миграции:** число файлов в `db/migrate`.
- **Движки:** подключённые движки, если есть.

## Источники команд
- README, документация или CI с вызовом `bundle`, `rails`, `rake`.
- Задачи `Rakefile`.
- Использование `bundle exec` в документации или скриптах.
- Включай только команды, реально имеющиеся в репозитории.

## Ключевые пути (только при наличии)
- `app/`, `config/`, `db/`
- `app/controllers/`, `app/models/`, `app/views/`
- `spec/` или `test/`

# Rust

## Признаки обнаружения
- `Cargo.toml`, `Cargo.lock`
- `rust-toolchain.toml`
- `src/main.rs`, `src/lib.rs`
- Участники рабочего пространства в `Cargo.toml`, `crates/`

## Признаки нескольких модулей
- `[workspace]` с `members` в `Cargo.toml`.
- Несколько `Cargo.toml` в `crates/` или `apps/`.

## Перед созданием изучи
- Корневые `Cargo.toml`, `Cargo.lock`.
- `rust-toolchain.toml`, если есть.
- `Cargo.toml` рабочего пространства в `crates/` или `apps/`.
- `src/main.rs` / `src/lib.rs`.

## Проверка кодовой базы (Rust)
- Корни исходников: `src/`, `crates/`, `tests/`, `examples/`.
- Структура модулей (отмечай только при наличии): `lib.rs`, `main.rs`, `mod.rs`, `src/bin/*`.
- Использование Serde (отмечай только при наличии): `#[derive(Serialize, Deserialize)]`.
- Асинхронность и среда выполнения (отмечай только при наличии): `tokio`, `async-std`.
- Веб-фреймворки (отмечай только при наличии): `axum`, `actix-web`, `warp`.

## Обязательный результат (CLAUDE.md модуля Rust)
Включай обнаруженное, перечисляя реальные имена:
- **Крейты:** назначение крейтов рабочего пространства.
- **Исполняемые программы:** цели `src/bin/*` или `[[bin]]`.
- **Модули:** верхнеуровневые объявления `mod`.
- **Обработчики и маршруты:** модули веб-обработчиков для веб-приложения.
- **Модели:** модули предметных моделей.
- **Конфигурация:** модули загрузки настроек.

## Источники команд
- README, документация или CI.
- Скрипты репозитория с вызовом `cargo`.
- Использование `cargo test`, `cargo run` в документации или скриптах.
- Включай только команды, реально имеющиеся в репозитории.

## Ключевые пути (только при наличии)
- `src/`, `crates/`
- `tests/`, `examples/`, `benches/`