Extra Mode

extra-mode — Режим максимальных возможностей

Описание

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

Когда активировать

• Пользователь просит «режим максимальных возможностей», «глубокий анализ», «полный подход»
• Проекты с множеством файлов, зависимостей и компонентов
• Архитектурные изменения и рефакторинг
• Задачи, требующие понимания всей кодовой базы
• Когда нужно изменить что-то, что влияет на многие части системы

Философия

> Делаем столько, сколько нужно. Каждое действие — результат глубокого осмысления. > Сложный проект требует системного подхода: понимание, планирование, выполнение, проверка.

Принципы extra-mode

1. Системное мышление. Проект — это не набор файлов, а система взаимосвязанных компонентов.
2. Понимание до изменения. Не меняем ничего, пока не поймём, как работает система целиком.
3. Постепенное внедрение. Сложные изменения — поэтапно, с проверкой на каждом шаге.
4. Учёт зависимостей. Каждое изменение влияет на другие компоненты — проверяем последствия.
5. Документирование решений. Почему сделали именно так — важно для будущего.

Обязательный цикл

Фаза 1: Полное понимание проекта

Перед любыми изменениями — глубокое погружение в проект:

1. Карта проекта. Структура директорий, назначение каждого файла.
2. Зависимости. Как компоненты связаны между собой (импорты, вызовы, данные).
3. Архитектура. Паттерны проектирования, слои, границы модулей.
4. Критические точки. Где чаще всего возникают баги? Что самое хрупкое?
5. Контекст. История изменений (git log), почему решения были приняты.

Фаза 2: Стратегическое планирование

Формируем план с учётом всей системы:

1. Scope изменений. Что именно меняем и что НЕ трогаем.
2. Последовательность. В каком порядке вносить изменения, чтобы не сломать систему.
3. Точки проверки. Где остановиться и проверить, что всё работает.
4. Fallback-план. Что делать, если изменение пойдёт не по плану.
5. Критерии успеха. Как поймём, что изменение успешно.

Фаза 3: Выполнение с осознанностью

Выполняем план, но остаёмся гибкими:

• Перед каждым действием — краткое обоснование: «Делаю X, потому что Y, ожидаю Z»
• После каждого действия — быстрая проверка: «Получил Z, это ожидаемо»
• При unexpected поведении — остановка и анализ, а не продолжение вслепую

Фаза 4: Комплексная проверка

После выполнения всех изменений:

1. Проверка каждой точки. Каждая точка проверки из плана — верифицирована.
2. Проверка зависимостей. Компоненты, которые зависят от изменённого кода — проверены.
3. Проверка регрессии. То, что раньше работало — продолжает работать.
4. Сверка с запросом. Результат соответствует тому, что просил пользователь.

Чек-лист

• [ ] Я составил карту проекта перед началом
• [ ] Я понял зависимости между компонентами
• [ ] Я учёл историю изменений
• [ ] Я сформировал стратегический план с последовательностью
• [ ] Каждая точка проверки из плана верифицирована
• [ ] Зависимые компоненты проверены на регрессию
• [ ] Результат сверен с исходным запросом
• [ ] Я сформулировал вывод о проделанной работе

Пример правильного поведения

Пользователь: «Добавь поддержку WebSocket в бота»

Фаза 1 — Понимание проекта:
   - Читаю структуру проекта
   - Нахожу основной файл бота, обработчики команд, систему плагинов
   - Вижу, что бот использует aiogram 3.x
   - Нахожу систему конфигурации и логирования
   - Понимаю, что WebSocket нужно интегрировать в основной цикл обработки

Фаза 2 — Планирование:
   1. Создать WebSocket-сервер как отдельный модуль
   2. Интегрировать в основной цикл бота (не блокируя обработку команд)
   3. Добавить конфигурацию порта и адреса
   4. Добавить систему аутентификации подключений
   5. Добавить логирование WebSocket-событий
   6. Проверить, что основной функционал бота не сломан

Фаза 3 — Выполнение:
   [read_file main.py] [read_file config.py] [read_file handlers.py]
   <-- понимаю структуру

   [create_new_file websocket_server.py]
   [edit_file main.py] <-- интегрирую в основной цикл
   [edit_file config.py] <-- добавляю конфигурацию

   <-- после каждого изменения быстрая проверка

Фаза 4 — Комплексная проверка:
   [read_file main.py] <-- проверяю интеграцию
   [read_file websocket_server.py] <-- проверяю модуль
   [read_file config.py] <-- проверяю конфигурацию

   Сверка:
   - WebSocket-сервер работает done
   - Основной бот не сломан done
   - Конфигурация добавлена done
   - Аутентификация работает done
   - Логирование добавлено done

Вывод: WebSocket интегрирован в бота. Основной функционал сохранён.

Scope

• Применять ко ВСЕМ задачам, когда активирован этот режим
• Фаза понимания проекта обязательна перед любыми изменениями
• Стратегическое планирование обязательно
• Комплексная проверка результата обязательна

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Major-Woolfi
• Source: Major-Woolfi/Skillsfor_AI-Agents
• License: MIT

Install and usage instructions live in the source repository linked above.