One Three One Rule - структурированный фреймворк принятия технических решений

Структурированный фреймворк для принятия решений и анализа trade-off в технических предложениях. Когда пользователь выбирает между несколькими подходами, этот навык формирует ответ в формате 1-3-1: одна четкая формулировка проблемы, три разных варианта с плюсами и минусами и одна конкретная рекомендация с definition of done и планом внедрения.

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

Источник	Optional - устанавливается через 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

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

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

1-3-1 Communication Rule

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

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

• Пользователь явно просит ответ в формате 1-3-1
• Пользователь говорит give me options или спрашивает, какие у него варианты
• У задачи есть несколько жизнеспособных подходов с заметными trade-off
• Пользователю нужен proposal, который можно переслать команде или стейкхолдеру

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

Процедура

1. Problem (одно предложение)

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

2. Options (ровно три)

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

3. Recommendation (один вариант)

   • Прямо скажите, какой вариант вы рекомендуете и почему.
   • Это должно быть профессиональное суждение, а не уклончивый ответ.

4. Definition of Done

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

5. Implementation Plan

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

Проверка

• В ответе ровно одно предложение Problem.
• Есть ровно три Options, A, B и C, с pros и cons.
• Есть одна Recommendation с выбором одного варианта и обоснованием.
• Definition of Done и Implementation Plan согласованы с выбранной рекомендацией.
• Если пользователь выбрал другой вариант, Recommendation, DoD и план должны быть пересобраны.

Пример

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.