Skip to content
Back to skills

1 3 1 Rule

ASecurity

Professional communication for high-agency engineers. Enforces the 1-3-1 rule to turn problems into decisions and minimizes synchronous friction.

  • 3 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added June 3, 2026
ai-agentsgodebuggingapibackendsecurity

Works with

  • cli
  • api

Security analysis

A100/100

Scanned June 3, 2026

npx -y skills add kinqsradiollc/BrainRouter --skill 1-3-1-rule --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of 1 3 1 Rule?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for 1 3 1 Rule
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/kinqsradiollc-1-3-1-rule/badge)](https://www.skillsdirectory.com/skills/kinqsradiollc-1-3-1-rule)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: 1-3-1-rule
description: Professional communication for high-agency engineers. Enforces the 1-3-1 rule to turn problems into decisions and minimizes synchronous friction.
hints:
  - Frame the core issue in exactly one concise sentence (the '1' in 1-3-1).
  - Provide exactly three distinct, viable options with structured pros and cons (the '3' in 1-3-1).
  - Explicitly recommend exactly one option with a clear professional rationale (the '1' in 1-3-1).
  - Detail a concrete, testable Definition of Done and step-by-step implementation plan for the recommendation.
  - Revise the recommendation, DoD, and implementation plan dynamically if the user chooses a different option.
---

# 1-3-1 Communication Rule

## Overview

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

- 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.

## Workflow

1. **Problem** (one sentence)
   - State the core decision or desired outcome in a single concise sentence.
   - Focus on the *what*, not the *how* — no implementation details, tool names, or specific technologies.
   - Keep it tight. If you need "and", you're describing two problems.

2. **Options** (exactly three)
   - Present three distinct, viable approaches labeled A, B, C.
   - Each option gets a brief description, pros, and cons.
   - Options should represent genuinely different strategies, not minor variations of the same approach.

3. **Recommendation** (one option)
   - State which option you recommend and why, based on the user's context and priorities.
   - Be direct — this is your professional judgment, not a hedge.

4. **Definition of Done**
   - List the specific success criteria for the recommended option.
   - These are concrete, verifiable outcomes — not vague aspirations.
   - If the user picks a different option, revise this section to match.

5. **Implementation Plan**
   - Concrete steps to execute the recommended option.
   - Include specific commands, tools, or actions where applicable.
   - If the user picks a different option, revise this section to match.

## Required Checks

- 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

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.

## Common Rationalizations

| Rationalization | Reality |
|---|---|
| "The options are too similar to list three distinct paths." | There are always different dimensions: speed of implementation, operational complexity, security/reliability, or third-party dependencies. Find the genuine trade-offs. |
| "I'll just ask the user what they want instead of giving a recommendation." | High-agency professionals do not offload decision-making. Presenting raw options without a recommendation wastes user time. |
| "This decision is too simple to need a 1-3-1 response." | A simplified 1-3-1 can be extremely short (e.g. 1 sentence problem, 3 bullet options, 1 sentence recommendation). It forces clarity and consensus. |

## Red Flags

- Listing more or fewer than three options.
- The "Problem" statement is multiple sentences or describes implementation details instead of the core goal.
- Giving a vague recommendation (e.g. "it depends on what you prefer" or "either option works").
- Implementation plan and DoD do not align with the recommended option.

## Verification

After completing this skill, confirm:
- [ ] The response contains exactly one single-sentence problem framing.
- [ ] Exactly three distinct options (A, B, C) are presented with explicit pros/cons.
- [ ] A definitive, professional recommendation is stated.
- [ ] The Definition of Done and Implementation Plan are fully tailored to the chosen option.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.