The 1-3-1

The 1-3-1

Force a decision into a useful shape: 1 problem, 3 real options, 1 recommendation. Not a menu. Not a wishlist. A call, with the reasoning exposed so others can disagree.

Structure

1 — Problem

One sentence. The decision to make, stated without implementation detail. Not "should we use Postgres or MySQL?" — "we need a primary datastore for the next 12-24 months of product growth, and we need to pick one by $DATE."

If the problem can't be stated in one sentence, the decision isn't ready — say so and help sharpen the framing first.

3 — Options

Exactly three. Not two (false binary), not five (can't-decide). If you only genuinely have two real options, name a third that's deliberately sub-optimal — often "do nothing" or "buy it instead of build it" — to expose the shape of the trade space.

Each option must be:

• Named — a short handle the user can refer to ("Option A: Hosted Postgres on Neon")
• Concrete — specific enough that the work is estimable
• Genuinely different — A and B that differ only in color aren't two options, they're one

For each:

Dimension	What to include
What	1-2 sentences on the approach
Pros	2-3 bullets. Specific, not "scalable" — "handles 10k req/s with our current schema."
Cons	2-3 bullets. Specific, not "less flexible."
Effort	S / M / L / XL with a rough week estimate
Reversibility	Two-way door (cheap to change) or one-way door (hard to unwind)?

If a pro or con is symmetric ("faster" for A is "slower" for B), state it once as a dimension of the trade, not twice.

1 — Recommendation

Pick one. Say why in one sentence. Don't hedge. If the user asks, defend the call.

Also include:

• Definition of done — how we'll know we made the right call, with a date or trigger: "by $DATE we have $METRIC." Not "it works well."
• Implementation plan — 3-5 concrete next steps, first one doable this week
• Trigger to revisit — what new information would make us reconsider? ("If we hit $USERS before $DATE, revisit.")

Output format

# 1-3-1: <one-line problem statement>

## Problem
<one sentence — no implementation detail>

**Context** (optional, only if needed)
<2-3 sentences on why this decision, why now>

## Options

### A. <name>
**What:** <1-2 sentences>
**Pros:**
- <specific>
**Cons:**
- <specific>
**Effort:** <S/M/L/XL, ~N weeks>
**Reversibility:** <two-way | one-way>

### B. <name>
<same structure>

### C. <name>
<same structure>

## Recommendation: <A | B | C>

<one-sentence reason>

**Definition of done:** <how we'll know this was the right call — specific + dated>
**Implementation plan:**
1. <first step, doable this week>
2. <second step>
3. <third step>
**Trigger to revisit:** <what would change our mind>

When to use this

• Someone's drifting between approaches and needs to land
• You need to propose a choice to someone else (CEO, tech lead, customer) and want them to weigh in cleanly
• A decision keeps getting raised but never made — forcing it into this shape surfaces what's actually blocking

When not to use this

• The decision is already made and just needs execution — skip this, use /team-core:task-breakdown instead
• The problem isn't a binary/trinary choice but a fuzzy strategic question — use /role-ceo:strategy-check or /role-ceo:office-hours
• It's a one-way-door decision with massive blast radius and you don't yet have the context to pick — gather more evidence before running this

Don't

• Don't pad to three options if only two are real. State the third as "do nothing" or "buy, don't build" with its honest cons.
• Don't write symmetric cons/pros across options. If it's a dimension of the trade, name it once in the Context.
• Don't skip the Definition of Done. A recommendation without a success criterion is a vibe.
• Don't recommend the option that happens to be most politically safe. Recommend the one you'd pick if you had to defend it.

---

Methodology inspired by the Nous Research "1-3-1 rule of communication" skill.