HermesBELARABI
العربيةSearch/CheckingSign in
AcademyDirectorySolutionsStudioProjectsCompareSearch Releases Pricing Account Sign in
Directory → SKILL
SKILLoptionalHermes Optional Skills

One Three One Rule

1-3-1 decision briefs: problem, three options, one pick

communicationdecision-makingproposalstrade-offsOptionalHermes skill
Last registry verification2026-08-18v1.0.0Willard Moore
Open original source ↗اقرأ بالعربية
Plain meaning

What does it add to Hermes?

1-3-1 decision briefs: problem, three options, one pick

One Three One Rule is a skill related to communication and scheduling. It connects the agent to a communication channel or calendar. The important distinction is whether it only reads or can also send and modify.

This plain-language explanation is based on the publisher description. The original text remains visible for verification.

Use it when

Use it when your goal in communication and scheduling is clear and you can limit it to the data and actions it actually needs.

Skip it when

Do not add it merely to experiment when Hermes already has a simpler path, or when you cannot review its source and permissions.

Who is it for?

Best for users who want a repeatable way of working inside Hermes.

Safe first test

Use a test account or draft-only workflow and confirm actual sending requires explicit approval.

Original publisher description

1-3-1 decision briefs: problem, three options, one pick

✓
Data source

This entry was indexed from Hermes Optional Skills. Our explanation interprets the type and domain without inventing a capability not present upstream.

!
Security review

The source is official or editorially reviewed, but you still need to review permissions and version compatibility.

Safe setup path

Inspect, install, then test.

  1. 01
    Open the source

    Match the publisher, license, and description to your need. Check the real update history.

  2. 02
    Review permissions and secrets

    Never paste a secret value into this site. Use environment-variable names and grant the smallest scope.

  3. 03
    Copy setup only after review

    The controls below copy text. They do not execute commands on your device.

  4. 04
    Test with a non-sensitive task

    Inspect the visible tools, then exclude write or delete tools you do not need.

Install command

Review the command, then copy it.

hermes skills install one-three-one-rule

Hermes Belarabi does not execute this command. Installation happens on your device and remains subject to Hermes scanning and your review.

The full skill definition

Exactly what Hermes loads when this skill runs.

Reproduced from the official documentation. Read it before enabling the skill: this text becomes the agent's instructions.

1-3-1 decision briefs: problem, three options, one pick.

Skill metadata

A lookup table. Do not read it all; find the row that applies to you.

SourceOptional — install with hermes skills install official/communication/one-three-one-rule
Pathoptional-skills/communication/one-three-one-rule
Version1.0.0
AuthorWillard Moore
LicenseMIT
Platformslinux, macos, windows
Tagscommunication, decision-making, proposals, trade-offs

Reference: full SKILL.md

Explains the idea itself. Read it slowly; the later sections build on it.

Structured decision-making format for when a task has multiple viable approaches and the user needs a clear recommendation. Produces a concise problem framing, three options with trade-offs, and an actionable plan for the recommended path.

When to Use

Explains the idea itself. Read it slowly; the later sections build on it.

  • The user explicitly asks for a "1-3-1" response.
  • The user says "give me options" or "what are my choices" for a technical decision.
  • A task has multiple viable approaches with meaningful trade-offs (architecture, tooling, migration strategy).
  • The user needs a proposal they can forward to a team or stakeholder.

Do NOT use for simple questions with one obvious answer, debugging sessions, or tasks where the user has already decided on an approach.

Procedure

Explains the idea itself. Read it slowly; the later sections build on it.

  1. Problem (one sentence)
  2. State the core decision or desired outcome in a single concise sentence.
  3. Focus on the what, not the how — no implementation details, tool names, or specific technologies.
  4. Keep it tight. If you need "and", you're describing two problems.
  1. Options (exactly three)
  2. Present three distinct, viable approaches labeled A, B, C.
  3. Each option gets a brief description, pros, and cons.
  4. Options should represent genuinely different strategies, not minor variations of the same approach.
  1. Recommendation (one option)
  2. State which option you recommend and why, based on the user's context and priorities.
  3. Be direct — this is your professional judgment, not a hedge.
  1. Definition of Done
  2. List the specific success criteria for the recommended option.
  3. These are concrete, verifiable outcomes — not vague aspirations.
  4. If the user picks a different option, revise this section to match.
  1. Implementation Plan
  2. Concrete steps to execute the recommended option.
  3. Include specific commands, tools, or actions where applicable.
  4. If the user picks a different option, revise this section to match.

Verification

Explains the idea itself. Read it slowly; the later sections build on it.

  • Response has exactly one Problem sentence.
  • Response has exactly three Options (A, B, C) with pros and cons for each.
  • Response has a single Recommendation that picks one option with reasoning.
  • Definition of Done and Implementation Plan align with the recommended option.
  • If the user selects a different option, Recommendation, DoD, and Implementation Plan update accordingly.

Example

Explains the idea itself. Read it slowly; the later sections build on it.

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.