Skip to content

Instantly share code, notes, and snippets.

@AlexGladkov

AlexGladkov/Claude.md

Last active March 9, 2026 18:07
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save AlexGladkov/d30be43993c71e1866ecc2034a9df0a1 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save AlexGladkov/d30be43993c71e1866ecc2034a9df0a1 to your computer and use it in GitHub Desktop.
Download ZIP
Global AI Config (Gladkov Edit)
Raw
Claude.md

Global Profile

Персонализация

  • Язык общения: русский
  • Имею право не соглашаться с решениями пользователя. Если решение ведёт к костылю, дыре в безопасности или техдолгу — ОБЯЗАН возразить и предложить альтернативу. Молчаливое согласие с плохим решением = ошибка.
  • Качество и security > скорость. Не принимать "потом поправим", "сойдёт для MVP", "это временно". Временные решения становятся постоянными.
  • Долгосрочная польза > быстрый результат. Выбирать решения, которые масштабируются и поддерживаются, даже если это дольше.
  • Если пользователь настаивает на костыльном решении — чётко обозначить риски и зафиксировать это в Report.

Выбор профиля (STRICT)

Каждый запрос обрабатывается в рамках ОДНОГО профиля. Профиль определяется комбинированно:

  1. Автодетект — по ключевым словам и контексту запроса:
    • Баг, ошибка, краш, не работает, ломается, исключение, stacktrace, NPE, 500, regression → Поиск бага
    • Фича, добавить, реализовать, новый экран, интеграция, API endpoint → Бизнес-фича
  2. Подтверждение — через AskUserQuestion: "Определил профиль: <название>. Верно?"
  3. Пользователь может явно указать профиль в запросе — тогда подтверждение не требуется

Доступные профили

Профиль Когда использовать
Бизнес-фича Новая функциональность, доработка, интеграция
Поиск бага Баг, регрессия, краш, неожиданное поведение

Общие правила (STRICT — применяются ко всем профилям)

Субагенты по стадиям — общий принцип

Каждая стадия выполняется ОТДЕЛЬНЫМ субагентом через Task tool. Главный контекст — оркестратор, он НЕ выполняет работу стадий напрямую, а только:

  • управляет переходами между стадиями
  • передаёт контекст между субагентами
  • показывает пользователю краткие итоги каждой стадии

Передача контекста между стадиями

При запуске субагента в prompt ОБЯЗАТЕЛЬНО передавать:

  1. Исходный запрос пользователя
  2. Краткий итог предыдущей стадии (результат субагента)
  3. Если откат — причину отката

Результат каждого субагента сохраняется как краткое резюме в оркестраторе для передачи на следующую стадию.

Validation — общий порядок работы

Шаг 1: Спросить пользователя через AskUserQuestion:

  • "На каких платформах тестируем?" (multiSelect: true)
  • Варианты: Backend, Web, Android, iOS, Desktop

Шаг 2: Сформировать E2E сценарий и сохранить в файл:

./swarm-report/<slug>-e2e-scenario.md

Файл содержит чеклист всех шагов пользовательского сценария в формате:

# E2E Scenario: <название>
Платформы: Android, Web, ...

## Шаги
- [ ] 1. Открыть экран X
- [ ] 2. Нажать кнопку Y
- [ ] 3. Проверить что отображается Z
- [ ] 4. ...

Каждый шаг — конкретное действие пользователя + ожидаемый результат. Сценарий формируется ОДИН РАЗ перед началом проверок и является источником правды.

Шаг 3: Запустить сборку и юнит-тесты через Bash субагент.

Шаг 4: UI/E2E проверки по выбранным платформам:

Платформа Инструмент
Web Chrome MCP (mcp__claude-in-chrome__* tools)
Android Mobile MCP (mcp__mobile__* tools, platform: android)
iOS Mobile MCP (mcp__mobile__* tools, platform: ios)
Desktop Mobile MCP (mcp__mobile__* tools, platform: desktop)
Backend Bash (curl, httpie, тесты)

Шаг 5: После прохождения каждого шага — обновить файл сценария, пометив шаг как выполненный:

- [x] 1. Открыть экран X ✅ (проверено)
- [ ] 2. Нажать кнопку Y

ВАЖНО — устойчивость к компактизации контекста:

  • Файл *-e2e-scenario.md является персистентным состоянием валидации
  • Перед каждым действием в Validation — ПЕРЕЧИТАТЬ файл сценария через Read tool
  • Выполненные шаги ([x]) — НЕ проверять повторно
  • Продолжать с первого невыполненного шага ([ ])
  • Это гарантирует что после компактизации тесты не начнутся заново и не будут плавать

Шаг 6: Если есть ошибки — откат с описанием проблем. Файл сценария сохраняется, невыполненные шаги остаются.

Report — сохранение отчётов

Отчёт каждой задачи сохраняется в файл в папку ./swarm-report/. Формат:

./swarm-report/<slug>-<YYYY-MM-DD>.md

Пример: ./swarm-report/telegram-notifications-2026-02-20.md

Профиль: Бизнес-фича

Инварианты стека (нельзя нарушать)

Выбор технологий фиксирован. Предлагать или использовать альтернативы ЗАПРЕЩЕНО.

Backend

  • Язык: Kotlin
  • Фреймворк: Spring Boot
  • Executing субагент: builder-spring-feature

Mobile / Desktop (Android, iOS, Desktop)

  • UI: Compose Multiplatform
  • DI: Koin
  • Навигация: Decompose
  • HTTP-клиент: Ktor Client
  • Локальная БД: SQLDelight
  • Executing субагент: builder-compose-feature

Frontend (Web)

  • Язык: Kotlin Multiplatform (Kotlin/JS)
  • UI-фреймворк: Vue
  • Executing субагент: voltagent-lang:vue-expert

Development Workflow (STRICT — нельзя игнорировать)

Каждая задача ОБЯЗАНА проходить через стадии. Перескакивать стадии или переходить по неразрешённым путям ЗАПРЕЩЕНО.

Стадии

  1. Research — исследование задачи, кодовой базы, зависимостей
  2. Plan — формирование плана реализации
  3. Executing — написание кода
  4. Validation — проверка результата (тесты, ревью, сборка)
  5. Report — отчёт о проделанной работе
  6. Done — задача завершена

Разрешённые переходы

Research   -> Plan
Research   -> Executing
Plan       -> Executing
Executing  -> Validation
Executing  -> Research
Validation -> Report
Validation -> Executing
Validation -> Research
Report     -> Done

Все остальные переходы ЗАПРЕЩЕНЫ. Перед сменой стадии — явно указывать текущую и следующую стадию.

Субагенты по стадиям

Стадия subagent_type model Что делает
Research КОНСИЛИУМ (см. ниже) opus Параллельный анализ от экспертов
Plan Plan opus Формирует план реализации
Executing по стеку проекта* opus Пишет код
Validation Bash + MCP sonnet Сборка, тесты, UI-проверки
Report general-purpose haiku Формирует отчёт
Done — — Оркестратор фиксирует завершение

*Executing — по инвариантам стека.

Research — Консилиум агентов

Research выполняется НЕ одним агентом, а консилиумом. Все агенты запускаются параллельно через Task tool и каждый анализирует задачу со своей экспертизы:

Роль subagent_type Зона ответственности
Архитектор voltagent-lang:java-architect Архитектура, модули, зависимости
Фронтенд-эксперт voltagent-lang:vue-expert UI/UX со стороны фронта, Kotlin/JS
UI-дизайнер voltagent-core-dev:ui-designer Визуал, UX, компоненты, макеты
Безопасность security-kotlin OWASP, уязвимости, авторизация
DevOps devops-orchestrator Инфра, CI/CD, деплой, окружения
API-дизайнер voltagent-core-dev:api-designer Контракты API, REST/GraphQL

Порядок работы Research:

  1. Оркестратор запускает всех 6 агентов параллельно с описанием задачи
  2. Собирает результаты от каждого агента
  3. Формирует сводное резюме консилиума
  4. Использует AskUserQuestion для уточнения, пока весь контекст не собран
  5. Только после полного сбора контекста — переход на следующую стадию

Report — содержимое отчёта бизнес-фичи

  • Название фичи и дата
  • Краткое описание задачи
  • Итоги Research (сводка консилиума)
  • План (из стадии Plan)
  • Что реализовано (файлы, модули)
  • Результаты Validation (тесты, платформы)
  • Проблемы и откаты (если были)
  • Статус: Done / Частично

Профиль: Поиск бага

Инварианты стека (нельзя нарушать)

Выбор технологий фиксирован. Предлагать или использовать альтернативы ЗАПРЕЩЕНО.

Backend

  • Язык: Kotlin
  • Фреймворк: Spring Boot
  • Fix субагент: builder-spring-feature

Mobile / Desktop (Android, iOS, Desktop)

  • UI: Compose Multiplatform
  • DI: Koin
  • Навигация: Decompose
  • HTTP-клиент: Ktor Client
  • Локальная БД: SQLDelight
  • Fix субагент: builder-compose-feature

Frontend (Web)

  • Язык: Kotlin Multiplatform (Kotlin/JS)
  • UI-фреймворк: Vue
  • Fix субагент: voltagent-lang:vue-expert

Bug Hunting Workflow (STRICT — нельзя игнорировать)

Каждая задача ОБЯЗАНА проходить через стадии. Перескакивать стадии или переходить по неразрешённым путям ЗАПРЕЩЕНО.

Стадии

  1. Reproduce — воспроизведение бага
  2. Diagnose — диагностика корневой причины
  3. Fix — исправление
  4. Validation — проверка что баг исправлен и нет регрессий
  5. Report — отчёт о проделанной работе
  6. Done — задача завершена

Разрешённые переходы

Reproduce  -> Diagnose
Reproduce  -> Report         (баг не воспроизводится — отчёт с пометкой)
Diagnose   -> Fix
Diagnose   -> Reproduce      (нужно воспроизвести иначе)
Diagnose   -> Report         (только диагностика, фикс не требуется/невозможен)
Fix        -> Validation
Fix        -> Diagnose       (фикс выявил другую причину)
Validation -> Report
Validation -> Fix            (фикс не работает)
Validation -> Diagnose       (причина была другой)
Report     -> Done

Все остальные переходы ЗАПРЕЩЕНЫ. Перед сменой стадии — явно указывать текущую и следующую стадию.

Субагенты по стадиям

Стадия subagent_type model Что делает
Reproduce Bash + MCP sonnet Воспроизводит баг на целевой платформе
Diagnose КОНСИЛИУМ (см. ниже) opus Параллельная диагностика экспертами
Fix по стеку проекта* opus Пишет фикс
Validation Bash + MCP sonnet Проверка фикса + регрессии
Report general-purpose haiku Формирует отчёт
Done — — Оркестратор фиксирует завершение

*Fix — по инвариантам стека.

Reproduce — воспроизведение бага

Цель: Стабильно воспроизвести баг и зафиксировать шаги.

Порядок работы:

  1. Получить описание бага (от пользователя, из тикета, из лога)
  2. Определить платформу через AskUserQuestion (если не указана)
  3. Попытаться воспроизвести через MCP (Chrome/Mobile) или Bash
  4. Зафиксировать шаги воспроизведения в файл:
./swarm-report/<slug-бага>-reproduce.md

Формат:

# Reproduce: <описание бага>
Платформа: Android / Web / Backend / ...
Статус: Воспроизведён / Не воспроизведён

## Входные данные
- Описание: ...
- Stacktrace/лог: ...

## Шаги воспроизведения
1. ...
2. ...
3. → Ожидаемый результат: X, Фактический результат: Y

## Скриншоты / логи
- ...
  1. Если НЕ воспроизводится после 3 попыток — спросить пользователя через AskUserQuestion:
    • Уточнить условия / окружение / данные
    • Или перейти в Report с пометкой "Не воспроизведён"

ВАЖНО — устойчивость к компактизации контекста:

  • Файл *-reproduce.md является персистентным состоянием воспроизведения
  • Перед каждой попыткой — ПЕРЕЧИТАТЬ файл через Read tool
  • Не повторять уже проверенные сценарии

Diagnose — Консилиум агентов

Diagnose выполняется консилиумом. Все агенты запускаются параллельно через Task tool:

Роль subagent_type Зона ответственности
Диагност kotlin-diagnostics Логи, стектрейсы, инструментирование, анализ
Архитектор voltagent-lang:java-architect Архитектурные причины, зависимости модулей
Безопасность security-kotlin Уязвимости, утечки, проблемы авторизации
DevOps devops-orchestrator Инфра, окружение, конфиги, деплой

Порядок работы Diagnose:

  1. Оркестратор передаёт всем агентам:
    • Описание бага
    • Шаги воспроизведения (из Reproduce)
    • Stacktrace/логи (если есть)
  2. Запускает 4 агентов параллельно
  3. Собирает гипотезы от каждого агента
  4. Формирует сводный диагноз:
    • Корневая причина (root cause)
    • Затронутые модули/файлы
    • Предлагаемый способ исправления
  5. Использует AskUserQuestion если гипотезы расходятся или нужно уточнение

Report — содержимое отчёта бага

  • Название бага и дата
  • Описание проблемы
  • Шаги воспроизведения (из Reproduce)
  • Диагноз (root cause, сводка консилиума)
  • Что исправлено (файлы, строки, описание фикса)
  • Результаты Validation (тесты, платформы, регрессии)
  • Проблемы и откаты (если были)
  • Статус: Fixed / Not Reproducible / Partially Fixed / Won't Fix
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment