---
name: adityapeshave-sophos/split-decision
source: https://app.decimal.ai/s/adityapeshave-sophos-split-decision@1/SKILL.md
source_sha256: f95e4fabaa63
---

# Split Decision

## Purpose

There's a tendency to present "the best approach" as if there's only one right
answer. In reality, most significant decisions involve trade-offs. This skill
forces multi-option analysis before committing to any architectural, technology,
or strategic choice. No more single-option recommendations dressed up as
obvious conclusions.

## When To Activate

Trigger when you see:

- User asks "should we X or Y"
- User asks "what's the best approach for..."
- User asks "which is better..."
- About to recommend an architectural choice
- About to recommend a technology/library/tool
- Any decision with meaningful trade-offs (not trivial choices)
- Refactoring approaches with multiple valid paths
- Database, framework, or infrastructure decisions

Do NOT trigger for:

- Trivial decisions ("should I use let or const here")
- Bug fixes with clear solutions
- Syntax questions
- When user has already made the decision and just needs implementation

## Instructions

### Step 1: Identify Viable Options

Generate 2-4 genuinely viable options. These must be:

- Actually reasonable choices (not strawmen to make one look better)
- Different enough to have meaningful trade-offs
- Options you'd actually consider recommending

If there's truly only one viable option, state why alternatives don't apply.

### Step 2: Assess Each Option

For each option, evaluate:

| Dimension | What to assess |
|-----------|----------------|
| Pros | Concrete benefits specific to THIS context (not generic marketing points) |
| Cons | Concrete drawbacks specific to THIS context (not theoretical risks) |
| Effort | Relative: Low / Medium / High |
| Risk | What could go wrong, and how bad would it be |
| Reversibility | Easy to change later, or locked in? |

### Step 3: Present Comparison Table

Format as:

```
## Options Analysis: [Decision Topic]

| Option | Pros | Cons | Effort | Risk | Reversible? |
|--------|------|------|--------|------|-------------|
| A: [Name] | [Specific pros] | [Specific cons] | Low/Med/High | Low/Med/High | Yes/No/Partial |
| B: [Name] | [Specific pros] | [Specific cons] | Low/Med/High | Low/Med/High | Yes/No/Partial |
| C: [Name] | [Specific pros] | [Specific cons] | Low/Med/High | Low/Med/High | Yes/No/Partial |
```

### Step 4: State Your Lean

Do NOT be falsely neutral. State which option you'd recommend and WHY:

```
**My lean:** Option B because [specific reason tied to this context, not generic]
```

The reason must be specific to their situation, not generic best practices.

### Step 5: Request Explicit Confirmation

Before implementing, ask user to confirm which trade-offs they accept:

```
**Before I proceed:** Which trade-offs are acceptable?

- [ ] Accept [specific con from leaned option]?
- [ ] Comfortable with [specific risk from leaned option]?
- [ ] Or prefer a different option?
```

Wait for explicit choice before implementing.

## Trade-off Categories

Common trade-off dimensions to consider:

**Speed vs Quality**
- Ship fast with tech debt vs take longer for clean solution
- MVP vs full implementation

**Simplicity vs Flexibility**
- Hardcoded solution vs configurable
- Specific vs generic abstraction

**Build vs Buy**
- Custom implementation vs third-party library/service
- Control vs maintenance burden

**Now vs Later**
- Fix it properly now vs quick patch
- Refactor first vs work around

**Safety vs Convenience**
- Strict validation vs trust inputs
- Explicit vs implicit behaviour

## NEVER

- Present a single option as "the best way" for significant decisions
- Include strawman options just to make your preference look good
- Use generic pros/cons not specific to this context
- Be falsely neutral - have a recommendation
- Proceed without explicit confirmation on significant decisions
- Ignore the user's stated constraints (time, skill level, existing tech)

## ALWAYS

- Present 2-4 genuinely viable options
- Make pros/cons specific to THIS context
- State your lean with specific reasoning
- Include effort and reversibility assessment
- Wait for user to confirm trade-offs before implementing
- Respect the user's final choice even if different from your lean

## Examples

### Example 1: Database Choice

User: "Should we use Postgres or MongoDB for user data?"

```
## Options Analysis: Database for User Data

| Option | Pros | Cons | Effort | Risk | Reversible? |
|--------|------|------|--------|------|-------------|
| A: PostgreSQL | ACID compliance, your team knows SQL, mature tooling, strong for relational data | Rigid schema requires migrations, more upfront design | Medium | Low | No (migration painful) |
| B: MongoDB | Flexible schema, fast iteration, good for evolving data shapes | Eventual consistency trade-offs, less familiar to team, can become messy | Medium | Medium | No (migration painful) |
| C: Start with SQLite | Zero setup, fast for prototyping, easy to migrate later | Not for production scale, single-writer limitation | Low | Low | Yes (designed for migration) |

**My lean:** Option A (PostgreSQL) because user data is inherently relational
(users have roles, permissions, relationships) and your team already knows SQL.
The "rigid schema" con is actually a feature for user data - you want that
consistency.

**Before I proceed:**
- [ ] Accept that schema changes need migrations?
- [ ] Comfortable with more upfront data modelling?
- [ ] Or prefer a different option?
```

### Example 2: Quick Decision (Skill Not Needed)

User: "Should I use single or double quotes for this string?"

```
Use whatever your codebase already uses for consistency. If no convention,
either is fine - this isn't a meaningful trade-off.

[Proceeds without options table]
```

## Why This Skill Exists

"What's the best way to..." questions deserve nuanced answers. Every significant
technical decision involves trade-offs - pretending otherwise does users a
disservice. The goal isn't to avoid having opinions. It's to show your work and
let users make the final call with full information.