Hermes agent

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

Структурированный фреймворк для принятия технических решений и анализа компромиссов. Когда перед пользователем стоит выбор между несколькими подходами — архитектурные решения, выбор инструментов, стратегии рефакторинга, пути миграции — навык строит ответ в формате 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

инфо

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

1-3-1 Communication Rule

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

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

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

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

Процедура

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

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

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

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

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

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

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

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

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

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

Проверка

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

Пример

User: “Give me a 1-3-1 for adding retry logic to our API client.”

Agent:

Problem: API calls to external services fail intermittently under load and need graceful retry handling.

Options:

  • Option A: Exponential backoff with jitter in a shared utility. Pros: Simple, well-understood pattern; single implementation shared across all callers. Cons: No circuit-breaking; callers still block during retries.

  • Option B: Retry library (tenacity) as a decorator on each endpoint call. Pros: Configurable per-endpoint; built-in support for circuit breakers and rate limits. Cons: Adds a dependency; decorator pattern can obscure control flow.

  • Option C: Queue-based async retry with dead letter handling. Pros: Non-blocking; failed calls are tracked and replayable; scales well. Cons: Significant complexity increase; requires a queue backend; overkill for low-volume services.

Recommendation: Option A. The call volume doesn’t justify queue infrastructure, and a shared utility with exponential backoff + jitter covers the failure mode cleanly without new dependencies.

Definition of Done:

  • api_retry() utility handles transient HTTP errors (429, 502, 503, 504).
  • Retries up to 3 times with exponential backoff and jitter.
  • All external API calls route through the retry utility.
  • Logs each retry attempt with endpoint and attempt number.
  • Tests cover retry exhaustion, immediate success, and transient-then-success scenarios.

Implementation Plan:

  1. Create utils/api_retry.py with configurable max retries, base delay, and retryable status codes.
  2. Add jitter using random.uniform(0, base_delay) to prevent thundering herd.
  3. Wrap existing API calls in api_client.py with the retry utility.
  4. Add unit tests mocking HTTP responses for each retry scenario.
  5. Verify under load with a simple stress test against a flaky endpoint mock.
⌕ ESC