High Iq

high-iq — Режим высокого IQ

Описание

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

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

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

Философия

> Высокий IQ в программировании — это не знание всех фреймворков. > Это способность видеть систему целиком, предвидеть проблемы до их возникновения, > и находить элегантные решения в сложных ситуациях.

Принципы высокого технического мышления

1. Первопричины. Не симптомы, а корневые причины проблем.
2. Системное мышление. Каждая деталь в контексте всей системы.
3. Проактивность. Выявляю проблемы до того, как они возникнут.
4. Оптимальность. Не «работает», а «работает наилучшим образом».
5. Масштабируемость. Решение, которое работает сегодня и завтра.

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

Фаза 1: Глубокий технический анализ

Перед решением задачи — полный анализ:

1. Корневая проблема. Что на самом деле нужно решить? (не симптом, а причина)
2. Архитектурный контекст. Как задача вписывается в архитектуру системы?
3. Альтернативные решения. Какие подходы возможны? Плюсы и минусы каждого.
4. Выбранное решение. Почему именно оно? Какие компромиссы?
5. Потенциальные риски. Что может пойти не так? Как mitigate?

Фаза 2: Проектирование решения

Перед реализацией — проектирование:

1. Интерфейс. Как решение будет взаимодействовать с остальной системой?
2. Границы. Что входит в решение, что нет?
3. Зависимости. Что нужно для работы? Что зависит от решения?
4. Edge cases. Какие крайние случаи нужно обработать?
5. Тестируемость. Как проверить, что решение работает правильно?

Фаза 3: Реализация с качеством

Реализация с фокусом на качество:

• Чистый код, понятные имена, логическая структура
• Обработка edge cases и ошибок
• Документирование сложных решений
• Оптимизация там, где это имеет значение (не premature optimization)

Фаза 4: Критическая оценка результата

После реализации — критическая оценка:

1. Правильность. Решение корректно для всех входных данных?
2. Эффективность. Оптимально ли решение по времени/памяти?
3. Читаемость. Поймёт ли другой разработчик это через 6 месяцев?
4. Расширяемость. Легко ли будет добавить функциональность?
5. Надёжность. Что произойдёт при нагрузке/ошибках/edge cases?

Методы глубокого анализа

Метод 1: First Principles Thinking

Разбираю задачу на фундаментальные истины:

• Что известно точно? (факты, а не предположения)
• Что является допущением? (нужно проверить)
• Что является архитектурным ограничением? (нельзя менять)
• Что является выбором дизайна? (можно переосмыслить)

Метод 2: Inversion

Думаю в обратную сторону:

• Как можно сломать это решение?
• Какие сценарии приведут к отказу?
• Что нужно для того, чтобы решение НЕ сработало?
• Как сделать так, чтобы это решение было худшим из возможных?

Метод 3: Trade-off Analysis

Каждое архитектурное решение — компромисс:

• Скорость vs читаемость
• Гибкость vs простота
• Производительность vs maintainability
• Абстракция vs overhead
• Кэширование vs актуальность данных

Метод 4: Pre-mortem

Предполагаю, что решение провалилось:

• Что пошло не так?
• Какие предположения оказались неверными?
• Какие зависимости были упущены?
• Как можно было предотвратить?

Метод 5: Multiple Abstraction Levels

Рассматриваю решение на разных уровнях:

• Уровень кода (строки, функции)
• Уровень модуля (классы, интерфейсы)
• Уровень системы (компоненты, сервисы)
• Уровень бизнеса (требования, ограничения)

Чек-лист

• [ ] Я определил корневую проблему, а не симптом
• [ ] Я рассмотрел минимум 2 альтернативных подхода
• [ ] Я проанализировал trade-offs каждого подхода
• [ ] Я учёл архитектурный контекст системы
• [ ] Я предвидел edge cases и риски
• [ ] Я применил хотя бы 2 метода глубокого анализа
• [ ] Я критически оценил результат после реализации
• [ ] Я проверил решение на всех уровнях абстракции
• [ ] Я сверил результат с исходным запросом
• [ ] Я сформулировал вывод о качестве решения

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

Пользователь: «Бот тормозит при обработке команд»

Фаза 1 — Глубокий анализ (First Principles + Inversion):
   Корневая проблема: не «бот тормозит», а «асинхронная обработка блокируется синхронными вызовами БД»
   Архитектурный контекст: бот использует aiogram + sqlalchemy + redis
   Альтернативы:
     A. Заменить sqlalchemy на асинхронный драйвер — быстро, но ломает миграции
     B. Вынести БД-операции в background tasks — безопасно, но усложняет код
     C. Добавить connection pool + async engine — оптимально по балансу
   Trade-off A: скорость vs стабильность
   Trade-off B: стабильность vs сложность
   Trade-off C: баланс — выбираем C

Pre-mortem: что если pool не поможет?
   - Возможно проблема в медленных запросх — нужно добавить EXPLAIN ANALYZE
   - Возможно проблема в сети — нужен health check к БД

Фаза 2 — Проектирование:
   1. Добавить AsyncEngine с pool_size=20, max_overflow=10
   2. Добавить timeout для соединений (30 сек)
   3. Добавить retry logic для transient errors
   4. Добавить метрики времени обработки команд

Фаза 3 — Реализация с качеством:
   [read_file database.py] [read_file config.py] [read_file main.py]
   <-- понимаю текущую конфигурацию

   [edit_file database.py] <-- добавляю AsyncEngine
   [edit_file config.py] <-- добавляю параметры pool
   [edit_file main.py] <-- добавляю метрики

Фаза 4 — Критическая оценка:
   Правильность: AsyncEngine корректно интегрирован в aiogram lifecycle
   Эффективность: pool_size=20 покрывает типичную нагрузку
   Читаемость: конфигурация вынесена в config.py, понятные имена переменных
   Расширяемость: можно легко добавить read replicas в будущем
   Надёжность: retry logic + timeout + connection health check

Вывод: Выбрано оптимальное решение (C) с балансом скорости и стабильности.
Добавлен AsyncEngine с пулом соединений, таймаутами и retry logic.
Решение масштабируется до типичной нагрузки бота.

Scope

• Применять ко ВСЕМ задачам, когда активирован этот режим
• Глубокий технический анализ обязателен перед решением
• Рассмотрение минимум 2 альтернатив обязательно
• Критическая оценка результата обязательна
• Применение методов глубокого анализа (минимум 2 из списка) обязательно

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.