Hard Decision Helper — Evidence-Backed Verdict

Can't decide between two options? Get a verdict by option, with each claim rated verified, plausible-but-unverified or unfounded, instead of confident opinion.

How it works

Settles a real dilemma (career move, build-vs-buy, quit-vs-stay, which offer to take) in three phases. Phase 1: three reviewer lenses (Evidence Skeptic, Steelman Arbiter, Precedent Realist) build and stress-test the case for every option. Phase 2: each lens cross-examines the other two. Phase 3: a board verdict by option, tagging evidence CONFIRMED, CORROBORATED or DISPUTED, ending in one named winner or an honest 'too close to call'. Each claim is rated verified, plausible-but-unverified or unfounded; precedents recalled without a source check are labeled unverified. It does not just validate the option you prefer, and it is not professional legal, medical or financial advice.

Sample output

Sample input (an invented example):

Use the Dilemma Board on this (a sample I wrote).

I run a 4-person SaaS startup (invoice reminders for freelancers, about 1,800 paying accounts, ~$22k MRR). We're on a managed cloud platform and our monthly bill just hit $3,900, up from $1,700 eight months ago. I'm torn between two options:

Option A: stay on the managed cloud and spend two weeks optimizing (reserved instances, cheaper database tier, dropping unused services). My cofounder says this "should cut 40%".

Option B: move to two rented bare-metal servers at a flat ~$600/month and run Postgres, queues and deploys ourselves. I believe this "is way cheaper and every serious company eventually does it".

Constraints: nobody on the team has run production databases on bare metal. We have no on-call rotation, we promised customers 99.9% uptime in our terms, and we have 11 months of runway. Our traffic is steady, with a small spike at month-end. Please give me a verdict, not a list of pros and cons. Contact: [email protected]

Real, unedited output:

## Phase 1 — Lens findings
Mode: one lens at a time

Reference figures (arithmetic on your numbers):
- **Bill growth:** $3,900 − $1,700 = $2,200, which is +129% in 8 months.
- **Bill as share of revenue:** $3,900 ÷ $22,000 = 17.7% of MRR.
- **Option A at 40%:** $3,900 × 0.6 = $2,340/mo, a saving of $1,560/mo.
- **Option B:** $3,900 − $600 = $3,300/mo saved on the hosting line. That is $1,740/mo more than optimized A.
- **99.9% uptime:** 30.4 days × 1,440 min × 0.001 ≈ 43.8 minutes of allowed downtime per month.

### 🔍 Evidence Skeptic
- **ES1:** "Should cut 40%" is **plausible but unverified.** No line-item breakdown was given, so there is nothing to check it against.
- **ES2:** "~$600/month flat" is **given by user (taken as stated, not checked).** It covers rent only. Migration time, backups, monitoring, replication and the team's ops hours are not in the figure, and none of them are quantified.
- **ES3:** "Every serious company eventually does it" is **unfounded.** It is asserted with no source.
- **ES4:** The constraints are the only solid inputs, all **given by user (taken as stated, not checked)**:
  - nobody on the team has run production databases on bare metal
  - no on-call rotation
  - 99.9% uptime promised in your terms
  - 11 months of runway
  - steady traffic with a month-end spike
- **ES5:** The cause of the +129% bill growth is unknown. Neither option's case explains it.
- **Stripped of unfounded claims:** A's case rests on an unverified 40% figure plus the constraints. B's case rests on a rent figure plus nothing that addresses the constraints.

### ⚖️ Steelman Arbiter
- **SA1 (for A):**
  - The bill more than doubled with no stated cause. If usage didn't grow proportionally, that points to removable waste (assumption).
  - Steady traffic is the usage profile reserved capacity is priced for (inference).
  - Managed failover and backups are what a team with no on-call relies on to stay within 43.8 minutes a month.
- **SA2 (for A):** Two weeks is a bounded, mostly reversible cost. With 11 months of runway, that keeps the team on product (inference from your stated constraints).
- **SA3 (for B):** If A's 40% holds, B still saves $1,740/mo more. Over 11 months that is 11 × $1,740 = $19,140, before migration and ops costs (the size of those costs is unknown).
- **SA4 (for B):** Steady, predictable load is exactly where fixed-capacity servers don't get overwhelmed (inference).

### 🌍 Precedent Realist
- **PR1:** 37signals (Basecamp/HEY) left the public cloud in 2022–23 and reported multi-million-dollar savings over several years. **Unverified (recalled from memory).** They had an experienced, dedicated ops team and far larger spend.
- **PR2:** GitLab's 2017 incident, where self-operated Postgres plus failing backups led to production data loss and hours of downtime. **Unverified (recalled from memory).** It shows the failure mode of running your own database under pressure.
- **PR3:** Netflix is a counterexample to "everyone eventually leaves": it stayed all-in on AWS. **Unverified (recalled from memory).**
- **PR4:** I can't name a concrete case of a ~4-person team with no ops experience moving to bare metal under an uptime SLA. No precedent was found (web search not used).

## Phase 2 — Cross-examination
- **[ES1]**
  - Challenged by SA: "the 40% has no line items behind it."
  - Challenged by PR: "the bill's growth cause (ES5) is unknown, so the share that is waste is unknown."
- **[ES2]** Corroborated by SA3: the rent gap is real arithmetic. Challenged by PR2: "rent excludes the operational risk that actually bit GitLab."
- **[ES3]** Challenged by PR3 with a named counterexample. Not corroborated by any lens.
- **[ES4]**
  - Corroborated by SA1: managed failover is A's answer to the SLA.
  - Corroborated by PR2 and PR4: there is no precedent for this team profile succeeding, and one for self-run Postgres failing.
- **[SA1]** Corroborated by ES4 on reliability. The "removable waste" part is challenged by ES5: it is an assumption.
- **[SA2]** Not challenged or corroborated.
- **[SA3]** Challenged by ES2: "$19,140 is gross; migration and ops hours are unpriced and could eat it."
- **[SA4]** Corroborated by ES4, since steady traffic is given. It cuts both ways: it supports reserved instances (A) as much as fixed servers (B).
- **[PR1]** Challenged by ES4: "structural mismatch — they had the ops team you lack."
- **[PR2]** Corroborates ES4 and SA1. Challenge from SA: the GitLab incident happened on cloud VMs, so it is about self-operating Postgres, not bare metal itself. Upheld only as a partial weakening; it still applies to Option B, which is self-operating.

## Phase 3 — Board verdict
### Option A — optimize the managed cloud
1. **[CORROBORATED]** Your 99.9% promise, the lack of on-call and the lack of bare-metal DB experience (given by user) favour keeping managed failover and backups. On two self-run servers, a single unattended overnight failure could exhaust 43.8 minutes quickly (inference from your stated constraints). Supported by ES4, SA1, PR2 (unverified, recalled from memory) and PR4 (no counter-precedent found).
2. **[CORROBORATED]** Steady traffic (given by user) suits reserved or committed pricing (inference). Supported by ES4, SA1 and SA4.
3. **[CONFIRMED]** The two weeks is bounded and mostly reversible, which matters with 11 months of runway (inference). From SA2.
4. **[DISPUTED]** "Should cut 40%" is plausible but unverified. Challenge: there is no line-item breakdown, and the cause of the +129% growth is unknown (ES1, ES5, SA1's waste assumption).

### Option B — two bare-metal servers
1. **[CORROBORATED]** The ~$600 rent (given by user) is $3,300/mo below today's bill and $1,740/mo below optimized A. Over 11 months that gap is $19,140 gross. Supported by ES2, SA3 and SA4.
2. **[DISPUTED]** "Way cheaper." Challenge: migration, backup, replication and on-call hours are excluded and unquantified (ES2, SA3 challenge, PR2 unverified, recalled from memory).
3. **[DISPUTED]** 37signals as precedent (unverified, recalled from memory). Challenge: they had a dedicated ops team and far larger spend, so the case does not transfer (PR1).
4. **[DISPUTED]** "Every serious company eventually does it" is unfounded. Challenge: there is no source, and Netflix is a counterexample (unverified, recalled from memory) (ES3, PR3).

**Verdict:** Option A. Its 2 CORROBORATED items rest on constraints you stated yourself. Option B's only CORROBORATED item is the rent figure, and its other 3 items are all DISPUTED.

The headline saving of B is real arithmetic. But your team is unlikely to hold 99.9% on self-run Postgres with no on-call and no bare-metal experience (inference from your stated constraints). An outage breaching your terms costs more than $1,740/mo of savings, though how much more is an assumption.

Make A's 40% falsifiable:
- Pull the line-item bill first and find what drove the +$2,200.
- Revisit B only if optimization lands well short of 40% **and** you've first built on-call and database-restore capability.

Tally: 3 CORROBORATED, 1 CONFIRMED, 4 DISPUTED.

This is decision support, not professional advice. I left your contact address out of the analysis since it wasn't needed.

Report consistency rules

• The first line under the Phase 1 heading must be Mode: one lens at a time (or Mode: sub-agents if sub-agents were actually used). Never omit it.
• Tags follow Phase 2 exactly: a finding another lens corroborated is CORROBORATED (never CONFIRMED); a finding with a concrete challenge is DISPUTED; CONFIRMED means no lens challenged or corroborated it. One issue gets one tag: merge duplicates.
• Every Phase 1 finding must either appear in Phase 3 or be merged into a listed item; list tagged items in the order CORROBORATED, CONFIRMED, DISPUTED.
• Every count in the closing line must equal the number of tagged items above it; recount before writing it.
• Use only facts, figures and dates that are in the pasted input. Anything else (market rates, outside examples, assumptions about the sender, reader or timing) must be labelled "assumption" or "unverified", never stated as fact. When comparing dates or durations, state the reference date used and write out the arithmetic.
• Verdict reasoning may not add cost or probability figures that are not in the input; label any such figure "assumption". Conclusions drawn from the user's stated constraints are worded as inferences ("is unlikely to ... (inference from your stated constraints)"), not as flat facts.
• Cite clause, line or item numbers only from the input text, and check the number against the text before citing it.
• Precedents recalled from memory (named companies, years, figures) must be labelled "unverified (recalled from memory)" every time they are cited, in Phase 1, 2 and 3. A claim the user gave is "given by user (taken as stated, not checked)", not "verified". Do not add generalizations such as "many companies do X" without a named source.

Handling sensitive info in the dilemma

If the dilemma involves real names, employers, or financial details, treat that as context only —
do not echo it back beyond what's needed to explain a finding. This Skill sends whatever you paste
as-is to the model; redact anything you'd rather not share before pasting. This is a
decision-support exercise, not professional advice — for high-stakes legal, medical, or financial
dilemmas, get an actual advisor.

Works with

Built for Claude Code; other agents that read SKILL.md files (such as Codex CLI or OpenClaw) should also work. No network access or extra tools needed.

Product and company names mentioned here, including Anthropic, OpenAI and OpenClaw, are trademarks of their respective owners; this Skill is an independent product and is not affiliated with, endorsed by or sponsored by any of them.