Правило «Один-три-один»

Структурированная система принятия решений для технических предложений и анализа компромиссов. Когда пользователь стоит перед выбором между несколькими подходами (архитектурные решения, выбор инструментов, стратегии рефакторинга, пути миграции), этот навык выдаёт формат «1-3-1»: одну чёткую формулировку проблемы, три различных варианта с плюсами и минусами и одну конкретную рекомендацию с определением готовности и планом реализации. Используйте, когда пользователь просит «1-3-1», говорит «дайте варианты» или нуждается в помощи с выбором между конкурирующими подходами.

Метаданные навыка

Источник	Опционально — установка: vibeos skills install official/communication/one-three-one-rule
Путь	optional-skills/communication/one-three-one-rule
Версия	1.0.0
Автор	Willard Moore
Лицензия	MIT
Платформы	linux, macos, windows
Теги	communication, decision-making, proposals, trade-offs

Справочник: полный SKILL.md

к сведению

Ниже приведено полное определение навыка, которое VibeOS загружает при его активации. Это те инструкции, которые видит агент, когда навык активен.

Правило общения «1-3-1»

Структурированный формат принятия решений для задач, у которых есть несколько жизнеспособных подходов и пользователю нужна чёткая рекомендация. Выдаёт сжатую формулировку проблемы, три варианта с компромиссами и действенный план по рекомендованному пути.

Когда использовать

• Пользователь явно просит ответ в формате «1-3-1».
• Пользователь говорит «дайте варианты» или «какие у меня есть варианты» для технического решения.
• Задача имеет несколько жизнеспособных подходов со значимыми компромиссами (архитектура, инструментарий, стратегия миграции).
• Пользователю нужно предложение, которое он может направить команде или заинтересованным сторонам.

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

Процедура

1. Проблема (одно предложение)

   • Сформулируйте ключевое решение или желаемый результат в одном сжатом предложении.
   • Сосредоточьтесь на что, а не на как — никаких деталей реализации, названий инструментов или конкретных технологий.
   • Будьте кратки. Если вам нужно «и», значит, вы описываете две проблемы.

2. Варианты (ровно три)

   • Представьте три различных жизнеспособных подхода, обозначенных A, B, C.
   • Каждый вариант получает краткое описание, плюсы и минусы.
   • Варианты должны представлять собой действительно разные стратегии, а не незначительные вариации одного и того же подхода.

3. Рекомендация (один вариант)

   • Укажите, какой вариант вы рекомендуете и почему, исходя из контекста и приоритетов пользователя.
   • Будьте прямы — это ваше профессиональное суждение, а не уклончивость.

4. Определение готовности

   • Перечислите конкретные критерии успеха для рекомендованного варианта.
   • Это конкретные, проверяемые результаты, а не расплывчатые пожелания.
   • Если пользователь выбирает другой вариант, пересмотрите этот раздел соответствующим образом.

5. План реализации

   • Конкретные шаги для выполнения рекомендованного варианта.
   • Включайте конкретные команды, инструменты или действия, где это применимо.
   • Если пользователь выбирает другой вариант, пересмотрите этот раздел соответствующим образом.

Верификация

• В ответе ровно одно предложение с Проблемой.
• В ответе ровно три Варианта (A, B, C) с плюсами и минусами для каждого.
• В ответе одна Рекомендация, выбирающая один вариант с обоснованием.
• Определение готовности и План реализации соответствуют рекомендованному варианту.
• Если пользователь выбирает другой вариант, Рекомендация, Определение готовности и План реализации обновляются соответствующим образом.

Пример

Пользователь: «Сделай 1-3-1 для добавления логики повторных попыток в наш API-клиент.»

Агент:

Проблема: Вызовы API к внешним сервисам нестабильно завершаются сбоями под нагрузкой, и требуется корректная обработка повторных попыток.

Варианты:

• Вариант A: Экспоненциальная выдержка с джиттером в общей утилите. Плюсы: Простой, хорошо понятный шаблон; единая реализация, используемая всеми вызывающими сторонами. Минусы: Нет размыкания цепи; вызывающие стороны всё ещё блокируются во время повторных попыток.

• Вариант B: Библиотека повторных попыток (tenacity) в качестве декоратора для каждого вызова конечной точки. Плюсы: Настраивается для каждой конечной точки; встроенная поддержка размыкателей цепи и ограничения скорости. Минусы: Добавляет зависимость; шаблон декоратора может скрывать поток управления.

• Вариант C: Асинхронные повторные попытки на основе очереди с обработкой «мёртвых писем». Плюсы: Неблокирующий; неудачные вызовы отслеживаются и могут быть воспроизведены; хорошо масштабируется. Минусы: Значительное усложнение; требуется бэкенд очереди; избыточно для сервисов с низким объёмом.

Рекомендация: Вариант A. Объём вызовов не оправдывает инфраструктуру очередей, а общая утилита с экспоненциальной выдержкой + джиттером чисто покрывает сценарий сбоя без новых зависимостей.

Определение готовности:

• Утилита api_retry() обрабатывает временные HTTP-ошибки (429, 502, 503, 504).
• До 3 повторных попыток с экспоненциальной выдержкой и джиттером.
• Все внешние вызовы API проходят через утилиту повторных попыток.
• Журналируется каждая попытка с указанием конечной точки и номера попытки.
• Тесты покрывают сценарии исчерпания попыток, немедленного успеха и временного сбоя с последующим успехом.

План реализации:

1. Создать utils/api_retry.py с настраиваемым максимальным числом попыток, базовой задержкой и повторяемыми кодами состояния.
2. Добавить джиттер с помощью random.uniform(0, base_delay) для предотвращения эффекта «толпы».
3. Обернуть существующие вызовы API в api_client.py утилитой повторных попыток.
4. Добавить модульные тесты с имитацией HTTP-ответов для каждого сценария повторных попыток.
5. Проверить под нагрузкой с помощью простого стресс-теста против имитации нестабильной конечной точки.