{/ Эта страница автоматически генерируется из файла SKILL.md навыка с помощью website/scripts/generate-skill-docs.py. Редактируйте исходный SKILL.md, а не эту страницу. /}

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

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

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


Источник	Опционально — установка: `hermes 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
ℹ️ Info

Ниже приведено полное определение навыка, которое Hermes загружает при его активации. Именно эти инструкции видит агент, когда навык активен.

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

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

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

Пользователь явно просит ответ в формате «1-3-1».

Пользователь говорит «дайте варианты» или «какие у меня есть выборы» для технического решения.

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

Пользователю нужно предложение, которое можно отправить команде или заинтересованным сторонам.

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

Процедура

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

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

Сосредоточьтесь на что, а не как — никаких деталей реализации, названий инструментов или конкретных технологий.

Держитесь кратко. Если нужно «и», значит, вы описываете две проблемы.

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

Представьте три различных жизнеспособных подхода, обозначенных A, B, C.

Каждый вариант получает краткое описание, плюсы и минусы.

Варианты должны представлять действительно разные стратегии, а не незначительные вариации одного и того же подхода.

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

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

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

Критерии готовности

Перечислите конкретные критерии успеха для рекомендуемого варианта.

Это конкретные, проверяемые результаты, а не расплывчатые пожелания.

Если пользователь выберет другой вариант, пересмотрите этот раздел.

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

Конкретные шаги для выполнения рекомендуемого варианта.

Включайте конкретные команды, инструменты или действия, где это применимо.

Если пользователь выберет другой вариант, пересмотрите этот раздел.

Проверка

Ответ содержит ровно одно предложение Проблемы.

Ответ содержит ровно три Варианта (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. Проверить под нагрузкой с помощью простого стресс-теста на фиктивной нестабильной конечной точке.