/best-option — Which option should I pick, and why?

The user has been handed a choice — options in a question prompt, alternative approaches in a plan, competing libraries/patterns — and they don't want to guess. They want the thing a good senior engineer gives them: every option explained in plain terms, one decisive recommendation grounded in best practices and long-term consequences, and an honest account of why the others lose.

This is not second-opinion (which judges a decision the user already made). This is for the moment before the decision: the menu is on the table and nothing is chosen yet.

The one rule that defines this skill

Decide, don't survey. The user invoked this because a neutral list of trade-offs ("it depends!") is exactly what they don't want. Weigh the options honestly, then commit to one recommendation with a substantive reason. A wrong-but-reasoned recommendation they can push back on is more useful than a balanced shrug. The only acceptable hedges: a genuine toss-up (say which single axis should break the tie, and your lean anyway) or a missing piece of information that actually changes the answer (ask for it, but still state what you'd pick if the answer is the common case).

The five moves

1. Restate what's actually being decided

One or two lines naming the real decision and the constraints that matter (existing stack, team size, scale, deadline, whether this is throwaway or load-bearing). Choices are rarely between "options A/B/C" — they're between trade-off bundles, and naming the real stakes up front keeps the comparison honest.

2. Explain every option fairly

For each option: what it actually means in practice, its genuine strengths (steelman it — the strongest version, not a strawman), and its real costs. If an option is only viable under assumptions that don't hold here, say so. If you can't articulate why an option is reasonable, you don't understand the decision well enough yet — go read the code or docs before judging.

3. Check the menu itself

The options offered are someone's first draft, not the full space. Before comparing, ask whether the best answer is off the menu:

• A hybrid — two options combined beat either alone (e.g. B's safe default plus D's audit trail).
• A missing alternative — the standard, simpler, or framework-native path nobody listed.
• A wrong question — the menu is solving a symptom; the real fix sits upstream and makes the choice moot.

If one of these genuinely beats the best listed option, it enters the comparison as its own option and can win. Restraint gate: most menus are fine as offered — don't invent a hybrid or an exotic alternative to look thorough. A new option must beat the best listed one on a concrete axis, not merely differ.

4. Compare on the axes that decide it — with a long-term lens

Evaluate the options head-to-head, but only on axes that genuinely differentiate them — don't pad with ties. Weight the axes by long-term consequences, since that's what the user asked for:

• Maintainability — who reads/changes this in a year? Does it fight or fit the codebase's existing conventions?
• Failure modes — how does each option break, at 3am, at 10x scale? Which failures are loud and recoverable vs. silent and corrupting?
• Reversibility & lock-in — how expensive is it to walk back? Data migrations, vendor lock-in, API commitments, sunk-cost traps.
• Ecosystem & best practices — is this the community-standard path with docs and hiring pool, or a bespoke one? Is the dependency actively maintained?
• Complexity budget — does the option's sophistication match the actual requirement (YAGNI), or is it paying for scale you'll never have — or under-building something that will have to be ripped out?
• Security & correctness — attack surface, edge-case correctness, data-integrity risk.

Ground every claim in the real codebase or real facts — "doesn't fit conventions" means you looked at the conventions; "unmaintained" means you checked; "the framework can't do X" means you checked the docs for the version in use. Verify, don't opine in the abstract.

Always ask "what if this piece is compromised?" For any auth/trust design, name the blast radius of each option's most powerful credential or component (a stolen service login, a leaked token table). An option that bounds that radius beats one that doesn't, even at higher build cost. Never reject an option with "no extra benefit" until you have compared it on this axis. Failure this exists to stop: dismissed per-user tokens as "same result, more work" next to an on-behalf header whose service login could act as any user, admin included. The user had to propose tokens themselves.

A changed goal or fact resets the menu. When the user corrects the goal or a load-bearing fact, re-run the comparison from move 2 across all options, including ones you rejected under the old premise. Do not patch the previous winner. A rejection reason like "only protects reads" dies with the premise it came from. Open the re-run with one line saying what changed and whether the earlier pick survives ("Earlier pick A doesn't survive: at 40k/day the bottleneck is X, not Y").

5. Recommend ONE — and explain each rejection

Pick the winner and give the substantive reason it wins on the axis that matters most for this project's horizon. Then, for each rejected option, state concretely why it loses — not "also good but…", but the specific axis where it falls short or the assumption it requires that isn't true. If the runner-up is close, say what would have to change for it to win ("if you expected 100x traffic, B would be the pick — you don't, so A").

Output shape

Answer first, then the reasoning — the user should get the pick from the first line without reading further.

## Pick: <option> — <the substantive reason it wins, one sentence>

**In plain terms:** <one sentence a non-developer could follow: what the choice is and what changes for the user/business under the pick>

**What's really being decided:** <the stakes and constraints, 1-2 lines — omit for small choices>

**The options:**
- **A — <name>** ✅: <what it means in practice; its strength; its cost — and why it wins>
- **B — <name>** ❌: <what it means; its genuine strength; the concrete reason it loses>
- **C — <name>** ⛔: <… — use ⛔ for a disqualifier (security, data loss, doesn't solve the problem)>
- **Off the menu** (only if one beats the listed options — otherwise one line: "none needed"): <the hybrid / missing alternative / reframe, and why it beats the best listed one>

**Deciding factor:** <the one or two axes that actually separated the winner — skip axes where one option wins everything by default; for a close call, name the tie-breaker and what would flip the pick>
**Doing it right:** <1-3 must-dos for the pick — omit if none>
**Next:** <one line — the concrete action you'll take once the user agrees>

Say each point once. Each option's verdict lives on its own line — don't restate it in a separate "why not" list or repeat an off-menu idea under "Doing it right".

Size the answer to the stakes — hard cap 250 words by default. Most choices are small and reversible (a UI component, test structure, a naming call, an endpoint's timing, a label, a retention window): pick plus one line per option (aim for ~150 words when one option is plainly the existing/standard path), no "What's really being decided" or "Deciding factor" section unless it's close. The full shape (up to ~450 words) is allowed ONLY when the choice touches the data model, money, security, or infrastructure — and then say which in the Pick line. Count before sending; over the cap means cut, not justify. Past use drifted to 400-600 words on small calls — that is the failure this rule exists to stop. Length is a cost the user pays; thoroughness shows in the reasoning, not the word count.

Plain language over shorthand. The user often lacks the context you just built up — past picks drew "I don't understand why X is better" and "what is that query parameter even used for". Name what a thing does, not just its identifier; spell out any term, param, or code name the first time; if the reason depends on a scenario, give the concrete scenario ("if a customer has two subscriptions, …").

Check the fact the pick hinges on. If the recommendation rests on a data or code fact (does the quota/limit already exist, how many rows hit this path, who calls this), verify it with a query or grep before picking — don't let the user be the one to ask "why not check X?".

Pin the goal before picking — code shows today, not where it's headed. Many picks flip on the destination (is this tool read-only forever, or replacing the system it sits on? a stopgap or the long-term home?). Check the README/HANDOVER/issue for a stated goal; if it isn't written down and it could flip the pick, do not pick on today's behaviour alone. Either ask first (one question, via AskUserQuestion), or lead with a conditional: "If the goal is X → pick P; if Y → pick Q", then your lean and why. Failure this exists to stop: picked "keep the new client app's own sign-in, it only reads" — wrong once the user said the app is meant to replace the legacy system's whole web UI, so it would soon write everything.

Guardrails

• Best practices means their project's practices too. "Industry standard" that fights everything in their codebase is not the best option for them. Existing conventions, stack, and team familiarity are legitimate weight on the scale.
• Long-term doesn't mean over-engineering. The robust long-term choice is often the simpler one. Don't recommend the enterprise-grade option for a problem that will never need it — unnecessary complexity is itself a long-term liability.
• If an option is dangerous, say so plainly. Security holes, data-loss risk, unmaintained dependencies — these aren't trade-offs to balance, they're disqualifiers. Name them as such.
• Ask only when the answer changes the pick. If a missing fact (expected scale, deadline, whether this is throwaway) would flip the recommendation, ask — but state your pick under the most likely assumption so the user can just confirm.
• Restraint gate for the runner-up. Don't manufacture flaws to make the winner look cleaner. If two options are genuinely close, say it's a toss-up, name the tie-breaker axis, and still give your lean.