| name | reflection-qa |
| description | Reflection + Self-Correction + Quality Assurance протокол. Stop-Reflect-Correct-Verify-Deliver перед ответом на сложные задачи. Основан на Reflection Agent Pattern (Anthropic) + Self-Correction Protocol (Self-Refine). |
| tags | ["reflection","qa","self-correction","reliability"] |
Reflection & QA Protocol
Активировать когда: задача сложная (>3 шагов), результат сомнительный, код затрагивает внешние системы, или произошла ошибка, которую пришлось чинить.
НЕ активировать: простые вопросы, однофайловые правки, творческие задачи, ответы "по памяти".
5-Шаговый Reflection Loop
[OUTPUT] -> STOP -> REFLECT -> CORRECT -> VERIFY -> DELIVER
^ |
|____ NO _________|
YES
Шаг 1: STOP
Моментальная пауза. Прерви исполнение и задай себе вопрос: "Уверен ли я на 100%, что этот результат корректен?"
- Если ответ ДА (и задача простая) → пропусти reflection
- Если НЕТ или сомневаешься → продолжай
Признаки, что нужен reflection:
- "Кажется работает, но.."
- "Наверное так"
- "Должно быть правильно"
- "Я не проверял граничные случаи"
Шаг 2: REFLECT (самопроверка)
Ответь себе на 5 вопросов в уме (не вслух пользователю):
- Логика: Есть ли ошибки в логике? Не пропустил ли шаг?
- Границы: Проверены ли пустые/нулевые/крайние значения?
- Инструменты: Правильный ли инструмент выбран? Может, нужен
delegate_task вместо последовательных вызовов?
- Токены: Не тащу ли лишний контекст? Можно ли ответить короче?
- Пользователь: Это то, о чём он просил? Или я сделал "как понял"?
Шаг 3: CORRECT (самокоррекция)
Если нашёл проблему:
- Ошибка в коде → используй
patch или execute_code для фикса
- Ошибка в логике → перепланируй подход, перепиши affected части
- Неполный результат → дополни недостающие куски
- Неверный инструмент → переделай с правильным
Шаг 4: VERIFY AGAIN
Перепроверь:
- Запусти тесты, если есть
- Выполни
curl/stat/ls для проверки побочных эффектов
- Прочитай изменённые файлы, чтобы убедиться
- Если использовал
delegate_task — проверь результат сам
🚨 Subagent Reflection (критическая вставка)
Subagent может наврать. Всегда. Даже если отчёт выглядит безупречно.
Типы subagent-лжи:
- Правдоподобные цифры — назвал конкретную цену/дату/версию, которой нет
- Успешный статус при провале — "задача выполнена", но файл не создан
- Плагиат контекста — перефразировал твой же промпт как "результат поиска"
- Вымышленные источники — процитировал статью/сайт, которых не существует
Когда subagent под подозрением:
- Вернул конкретные цифры, которые ты не можешь проверить → не передавай пользователю без оговорки
- Утверждает что-то противоречащее здравому смыслу или твоим знаниям → проверь
- Слишком быстро "нагуглил" идеальный ответ → вероятно сгененрировал
Золотое правило: subagent даёт направление и ссылки. Факты дёргаешь сам.
Шаг 5: DELIVER
Только когда все 5 вопросов REFLECT прошли зелёными.
Self-Refine (многошаговая итерация)
Для задач, где качество критично (production-код, финансы, безопасность):
- Сделай черновик решения
- Проведи reflection
- Улучши (refine)
- Снова reflection
- Отдай
Максимум 3 итерации. Если за 3 не получилось — смени подход или спроси пользователя.
QA Checklist по типу задачи
| Тип | Что проверить |
|---|
| Код | Компилируется/запускается? Тесты проходят? Краевые случаи? |
| Данные | Структура корректна? Все поля есть? Типы совпадают? |
| Команды | Не пейджится (git → cat)? Не зависнет без pty? |
| Файлы | Записан? Прочитай и проверь |
| Веб | Статус ответа? JSON валидный? |
| subagent | Я проверил статус? (не верь subagent-у на слово) |
Провальные паттерны (check yourself)
- ❌ "Звучит правильно" → проверь
- ❌ "Subagent сказал что всё ок" → проверь сам (файл существует? ответ 200?)
- ❌ "Я уверен, тесты пройдут" → запусти их
- ❌ "Должно работать, это же очевидно" → проверь граничный случай
