/sc-hypothesize

name: sc-hypothesize
description: Use when multiple plausible approaches must be generated, tested, and compared against constraints before the user chooses.
argument-hint: Problem or decision to reason through

Structured Reasoning (ADI Cycle)

Reason through problems by generating competing hypotheses, verifying them against constraints, gathering evidence, and presenting a comparison for the user to decide.

Based on the ADI reasoning cycle: **Abduction** (generate options) -> **Deduction** (verify logic) -> **Induction** (gather evidence) -> **Decision** (user picks).

When to Use This

• Architectural decisions with long-term consequences
• Multiple viable approaches that need systematic comparison
• Decisions that benefit from an auditable reasoning trail
• Problems where anchoring on the first idea is a risk

When NOT to Use This

• Quick fixes with obvious solutions (just do the work)
• Easily reversible decisions (just try it)
• Open-ended uncertainty without clear options (use `/sc-socratic` instead)
• Pure implementation tasks (implement directly)

Core Principle: Transformer Mandate

**You generate options with evidence. The human decides.**

Do not select winners autonomously. Present the comparison, surface the trade-offs, and wait for the user to choose.

The ADI Cycle

Each phase is a conversational turn. The user drives transitions — you don't auto-advance through all phases in one response.

Phase 1: Abduction (Generate Hypotheses)

Generate 3-5 competing approaches. Resist anchoring on the first idea that seems reasonable.

**Requirements:**

• At least one **conservative** option (safe, proven, lower risk)
• At least one **radical** option (novel, higher potential, less proven)
• Each hypothesis states: what it is, key assumptions, and where it applies (scope)
• Classify each as **system** (code/architecture) or **process** (methodology/workflow)

**Anti-anchoring check:** Before generating, ask yourself — am I just listing variations of the same idea? If yes, force at least one genuinely different approach.

**Output format:**

## Hypotheses

### H1: [Name] (conservative)
**Approach**: [What and how]
**Assumptions**: [What must be true]
**Scope**: [Where this applies]

### H2: [Name]
...

### H3: [Name] (radical)
...

**After presenting hypotheses, ask the user:**

• Are any missing? Should we add one?
• Should we kill any before going deeper?
• Ready to verify?

Phase 2: Deduction (Verify Logic)

Check each surviving hypothesis against constraints. Kill the ones that don't hold up.

**For each hypothesis, check:** 1. **Logical consistency** — Does the approach actually solve the stated problem? 2. **Constraint compatibility** — Does it fit within known technical constraints (existing stack, team skills, timeline)? 3. **Type correctness** — Does the solution shape match the problem shape? (e.g., proposing a caching solution for a data modeling problem)

**Verdicts:**

• **PASS** — Logically sound, survives to evidence gathering
• **FAIL** — Contradicts constraints or logic. Document why and drop it
• **REFINE** — Has potential but needs adjustment. Modify and re-check

**Output format:**

## Verification Results

### H1: [Name] — PASS
**Logic**: [Why it holds up]
**Constraints**: [Compatible because...]

### H2: [Name] — FAIL
**Reason**: [Specific contradiction or logical flaw]

### H3: [Name] — REFINE
**Issue**: [What needs adjustment]
**Refined**: [Updated approach]

**After verification, confirm with user:** These hypotheses survived. Ready to gather evidence?

Phase 3: Induction (Gather Evidence)

Collect actual evidence for each surviving hypothesis. This is where you do real work — read code, run searches, check docs, analyze feasibility.

**Evidence quality tiers:**

| Tier | Source | Confidence | |------|--------|------------| | **Internal test** | Run code, benchmark, prototype in this project | High | | **Internal analysis** | Read this codebase, check compatibility | Medium-High | | **Similar context** | Evidence from similar project/stack | Medium | | **External docs** | Library docs, blog posts, general advice | Low-Medium |

**Weakest Link Principle (WLNK):** A hypothesis is only as strong as its weakest piece of evidence. Don't average — report the floor.

**For each hypothesis, gather:**

• Best available evidence (prefer internal over external)
• The weakest link — what's the least certain thing?
• Known unknowns — what couldn't you verify?

Use Agent tools to parallelize evidence gathering when hypotheses are independent.

**Output format:**

## Evidence

### H1: [Name]
**Evidence**: [What you found, with sources]
**Weakest link**: [Least certain element]
**Unknowns**: [What couldn't be verified]
**Confidence floor**: [high / medium / low]

### H3: [Name]
...

Phase 4: Decision (User Decides)

Present a comparison table and let the user choose.

**Output format:**

## Comparison

| | H1: [Name] | H3: [Name] |
|---|---|---|
| **Approach** | ... | ... |
| **Evidence** | ... | ... |
| **Weakest link** | ... | ... |
| **Confidence** | ... | ... |
| **Trade-offs** | ... | ... |
| **Reversibility** | ... | ... |

## Recommendation

[Your analysis of which is stronger and why — but the user decides]

## What would you like to go with?

After the user decides, document the rationale:

## Decision Record

**Problem**: [Original question]
**Chosen**: [H-name] — [one-line summary]
**Rationale**: [Why this won, citing evidence]
**Rejected**: [Other hypotheses and why they lost]
**Revisit when**: [Conditions that should trigger re-evaluation]

Persistence

Save reasoning artifacts to `.agent-history/reasoning/<slug>/`:

.agent-history/reasoning/<slug>/
  hypotheses.md    # Phase 1 output
  verification.md  # Phase 2 output
  evidence.md      # Phase 3 output
  decision.md      # Phase 4 output (if reached)

Create the directory at the start of Phase 1. Write each file as its pha