| 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
-
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.
-
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.
-
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.
-
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.
-
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:
- Create
utils/api_retry.py with configurable max retries, base delay, and retryable status codes.
- Add jitter using
random.uniform(0, base_delay) to prevent thundering herd.
- Wrap existing API calls in
api_client.py with the retry utility.
- Add unit tests mocking HTTP responses for each retry scenario.
- 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:
