---
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 (use `/sc-work`)

## 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 phase completes.

**Slug generation:** Lowercase the problem statement, take first 4-5 words, join with hyphens. Example: "how should we handle caching" -> `how-should-we-handle-caching`

## Execution

1. **Parse the problem** — Read `$ARGUMENTS`. If empty, ask what decision needs reasoning.

2. **Gather context** — Use Read, Grep, Glob to understand the relevant codebase before generating hypotheses. Don't hypothesize in a vacuum.

3. **Run Phase 1** — Generate hypotheses, present to user, wait for confirmation.

4. **Run Phase 2-4 on user request** — Each phase is a separate turn. Don't auto-advance. The user says "verify" or "gather evidence" or "decide" to move forward.

5. **Early exit is fine** — If the answer becomes obvious during Phase 1 or 2, say so. The framework serves the decision, not the other way around.

## Shortcuts

- `/sc-hypothesize [problem]` — Start from Phase 1
- "verify" / "check logic" — Run Phase 2 on existing hypotheses
- "evidence" / "test these" — Run Phase 3
- "decide" / "compare" — Run Phase 4
- "add hypothesis: [idea]" — Add a user-supplied hypothesis at any point
- "kill H2" — Remove a hypothesis from consideration

## Related Commands

| Situation | Command |
|-----------|---------|
| Open-ended uncertainty, no clear options | `/sc-socratic` |
| Quick implementation after deciding | `/sc-work` |
| Challenge a conclusion adversarially | `/sc-challenge-assumptions` |
| Full feature workflow with architecture | `/sc-workflow` |