Перейти к содержанию

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

Skill metadata​
Источник Опционально — установите с помощью hermes skills install official/communication/one-three-one-rule
Путь optional-skills/communication/one-three-one-rule
Версия 1.0.0
Автор Willard Moore
Лицензия MIT
Теги communication, decision-making, proposals, trade-offs
## Reference: full SKILL.md​
> info
> Ниже приведено полное описание навыка, которое Hermes загружает при его активации. Вот что агент видит в качестве инструкций, когда навык активен.

1-3-1 Communication Rule

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

When to Use​

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

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

Procedure​

  1. Проблема (одно предложение)
    • Сформулируйте ключевое решение или желаемый результат одним кратким предложением.
    • Сосредоточьтесь на что, а не как — никаких деталей реализации, названий инструментов или конкретных технологий.
    • Будьте лаконичны. Если вам нужно «и», значит, вы описываете две проблемы.
  2. Варианты (ровно три)
    • Представьте три различных возможных подхода, обозначенных A, B, C.
    • Каждый вариант получает краткое описание, плюсы и минусы.
    • Варианты должны представлять принципиально разные стратегии, а не незначительные вариации одного подхода.
  3. Рекомендация (один вариант)
    • Укажите, какой вариант вы рекомендуете и почему, исходя из контекста и приоритетов пользователя.
    • Будьте прямы — это ваше профессиональное суждение, а не уклончивый ответ.
  4. Критерии завершения (Definition of Done)
    • Перечислите конкретные критерии успеха для рекомендованного варианта.
    • Это конкретные, проверяемые результаты — не расплывчатые пожелания.
    • Если пользователь выбирает другой вариант, пересмотрите этот раздел соответствующим образом.
  5. План реализации
    • Конкретные шаги для выполнения рекомендованного варианта.
    • Включайте конкретные команды, инструменты или действия, где это применимо.
    • Если пользователь выбирает другой вариант, пересмотрите этот раздел соответствующим образом.

Verification​

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

Example​

Пользователь: «Сделай 1-3-1 для добавления логики повторных попыток в наш API-клиент.» Агент: Проблема: API-вызовы к внешним сервисам нестабильно завершаются с ошибками при нагрузке, и требуется корректная обработка повторных попыток. Варианты: * Вариант A: Экспоненциальная задержка с джиттером в общей утилите. Плюсы: Простой, хорошо понятный паттерн; одна реализация, общая для всех вызывающих сторон. Минусы: Нет размыкателя цепи (circuit breaker); вызывающие стороны всё ещё блокируются во время повторных попыток. * Вариант B: Библиотека повторных попыток (tenacity) в качестве декоратора для каждого вызова конечной точки. Плюсы: Настраивается для каждой конечной точки; встроенная поддержка размыкателей цепи и ограничений скорости. Минусы: Добавляет зависимость; паттерн декоратора может затемнять поток управления. * Вариант C: Асинхронные повторные попытки на основе очереди с обработкой недоставленных сообщений (dead letter). Плюсы: Неблокирующий; неудачные вызовы отслеживаются и могут быть повторены; хорошо масштабируется. Минусы: Значительное усложнение; требует бэкенда очереди; избыточно для сервисов с низким объёмом запросов.

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

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