Self-Improve — Рекурсивное Самосовершенствование

Суть

Один Claude — две роли в цикле:

1. Критик — находит слабые места в текущей версии
2. Автор — устраняет замечания и создаёт следующую версию

Цикл: Критиковать → Улучшить → Критиковать → ... → 0 замечаний ИЛИ лимит достигнут.

Это не косметические правки. Критик работает жёстко: ищет логические дыры, неточности, edge cases, плохие паттерны. Автор должен их устранить или объяснить почему нет.

Входные данные

/self-improve [тип] [артефакт]

Типы:

• code — файл кода или вставленный код
• idea — концепция, план, гипотеза, предложение
• skill — SKILL.md файл (для улучшения скилов)
• prompt — системный промпт или инструкция для Claude

Аргументы:

• --iterations N или N итераций — число итераций (по умолчанию: 3, максимум: 5)
• --focus [aspect] — фокус критики (подробнее в разделе Режим Focus)

Примеры:

/self-improve code myfile.py
/self-improve idea "Local LLM router for solo developers, $9/month subscription"
/self-improve skill path/to/your-skill/SKILL.md
/self-improve prompt "Ты — эксперт по анализу рынка..."
/self-improve code --iterations 5 --focus security

Алгоритм выполнения

Шаг 0 — Считай артефакт (v0)

Если передан путь к файлу → прочитай его содержимое. Если передан текст → используй его напрямую. Если ничего не передано → попроси пользователя предоставить артефакт.

Определи тип автоматически если не указан (по расширению файла или содержимому).

Это v0 — исходник. Его не улучшаем, только критикуем.

Шаги 1..N — Итерационный цикл

Каждая итерация = Критика текущей версии → Создание следующей версии.

Фаза А: Критик (критикуем текущую версию)

Переключись в режим безжалостного критика. Найди:

Для code:

• Нарушения принципов (SOLID, DRY, YAGNI)
• Отсутствующая обработка ошибок
• Edge cases без покрытия
• Неэффективные паттерны
• Неочевидный код без комментариев WHY
• Нарушения type hints

Для idea:

• Нереалистичные допущения
• Кому это нужно? Есть ли боль?
• Что может пойти не так?
• Что упущено? Какие риски?
• Альтернативные подходы которые лучше
• Нет unit economics / GTM / ICP

Для skill:

• Нечёткие триггеры (когда вызывать?)
• Отсутствующий BSV блок
• Шаги без примеров
• Двусмысленные инструкции
• Нет NOT-для (чего НЕ нужно делать)

Для prompt:

• Расплывчатые инструкции
• Нет примера желаемого вывода
• Конфликтующие требования
• Слишком много обязательных условий (когнитивная перегрузка)
• Нет escape hatch для крайних случаев

Перечисли замечания нумерованным списком. Каждое замечание — конкретное и actionable.

Если замечаний 0 → СТОП. Итерации завершены раньше лимита.

Фаза Б: Автор (создаём следующую версию)

Устрани все замечания критика. Каждое замечание должно быть:

• Исправлено (с объяснением что изменилось), ИЛИ
• Обосновано почему оставлено (если замечание ошибочно)

Создай улучшенную версию. Не показывай промежуточные версии — только финальную.

Прогресс-трекер (формат)

📊 ПРОГРЕСС:
  v0 (исходник):   X замечаний нашёл критик
  v1 (итерация 1): исправлено X, осталось Y замечаний
  v2 (итерация 2): исправлено Y, осталось Z замечаний
  v3 (итерация 3): ✅ 0 замечаний  [ИЛИ: осталось N — лимит достигнут]

Логика счётчиков:

• v0: X замечаний — критик нашёл X проблем в исходнике
• v1: исправлено X, осталось Y — автор устранил X, критик нашёл Y новых/оставшихся в v1
• И так далее до 0 или лимита

Финальный вывод

🔄 SELF-IMPROVE — [тип] за [N] итераций
════════════════════════════════════════

📊 ПРОГРЕСС:
  v0 (исходник):   [N] замечаний
  v1 (итерация 1): исправлено [N], осталось [M]
  v2 (итерация 2): исправлено [M], осталось [K]
  v3 (итерация 3): ✅ 0 замечаний

━━━ ФИНАЛЬНАЯ ВЕРСИЯ ━━━━━━━━━━━━━━━━━━━

[артефакт целиком]

━━━ ЧТО ИЗМЕНИЛОСЬ ━━━━━━━━━━━━━━━━━━━━

• [ключевое улучшение 1]
• [ключевое улучшение 2]
• [ключевое улучшение 3]
(минимум 3, максимум 7 пунктов — только самые значимые)

━━━ НЕРЕШЁННЫЕ ЗАМЕЧАНИЯ ━━━━━━━━━━━━━━
(только если лимит достигнут и остались замечания)

• [замечание] — Почему не исправлено: [причина/трейдофф]

Режим Focus (--focus)

--focus добавляет дополнительные критерии к стандартному набору критика:

Без --focus — стандартный набор критериев для типа артефакта.

Правила качества

Критик не поддакивает. Если артефакт хорош — он скажет "0 замечаний". Если находит проблемы — не смягчает: "Это нарушает X потому что Y".

Автор не игнорирует. Каждое замечание получает ответ: либо исправление, либо обоснованное отклонение.

Секция ЧТО ИЗМЕНИЛОСЬ — обязательна всегда. Минимум 3 пункта. Не пропускать.

Не разрастайся. Цель — улучшить существующее, не переписать с нуля. Сохраняй дух оригинала. Убирай плохое, не добавляй лишнее.

Честный счётчик. Не считай замечание "исправленным" если только переформулировал. Исправлено = проблема устранена, можно проверить.

Выход при 0 замечаниях — останавливайся немедленно, не делай пустые итерации.

Пример: /self-improve idea "Local LLM router for solo developers, $9/month"

🔄 SELF-IMPROVE — idea за 2 итерации (стоп: 0 замечаний)

📊 ПРОГРЕСС:
  v0 (исходник):   5 замечаний
  v1 (итерация 1): исправлено 3, осталось 2 замечания
  v2 (итерация 2): ✅ 0 замечаний

━━━ ФИНАЛЬНАЯ ВЕРСИЯ ━━━━━━━━━━━━━━━━━━━

**Local LLM router для solo devs, $9/мес**

Боль: local LLMs (Ollama, LM Studio) дёшевы но выбор модели ручной —
разработчик тратит 10+ мин/день на переключение между Mistral / Llama / CodeLlama.

Решение: роутер автоматически выбирает модель по типу задачи (код → CodeLlama,
текст → Mistral, reasoning → Llama 3). Plug-in к уже запущенному Ollama.

ICP: solo dev, Ollama уже стоит, $50-200/мес на API хочет сэкономить.
GTM: HackerNews Show HN + Ollama GitHub Discussions.

━━━ ЧТО ИЗМЕНИЛОСЬ ━━━━━━━━━━━━━━━━━━━━

• Добавлен конкретный ICP (solo devs с Ollama, не enterprise)
• Добавлена измеримая боль (10+ мин/день ручное переключение)
• Уточнена цена ($9 = ниже GPT-4 API порога экономии solo dev)
• Убрана претензия на "лучший роутер" — узкий use case: local LLMs only
• Добавлен GTM канал (HN + Ollama community)

━━━ НЕРЕШЁННЫЕ ЗАМЕЧАНИЯ ━━━━━━━━━━━━━━
(нет — 0 замечаний достигнуто на итерации 2)

Связанные скилы

• (опционально) брифинг проекта перед улучшением кода
• (опционально) одноразовая red-team критика решения (не цикл)
• (опционально) TDD-навык: для кода сначала тесты, потом улучшение