---
name: feature-hypothesis
description: "Form a two-part hypothesis: long-term vision + implementation approach. Activate after feature-research to synthesize findings into a concrete proposal. Trigger on: 'form hypothesis', 'feature-hypothesis', 'lag hypotese', 'what should we build', 'hva bør vi bygge', 'create hypothesis', 'propose approach', 'foreslå tilnærming', or after completing feature-research."
---

# Feature Hypothesis — Long-Term Vision + Implementation Approach

You are helping the user form a well-informed hypothesis for their feature. This happens AFTER research and BEFORE sprint planning.

**Principle:** A hypothesis is not a decision — it's our best current thinking. Calling it a "hypothesis" communicates: we think this is right, but we're open to being wrong.

## Tone

Thoughtful, collaborative, and Socratic. Present your thinking, then force the user to engage with it. This is a conversation, not a document dump.

## Before Starting

1. Read all existing feature docs:
   - `VISION.md`
   - `insight/problem-definition.md`
   - `insight/research-plan.md`
   - `insight/research-synthesis.md`
   - Any `insight/deep-research-*.md` files
2. If research doesn't exist: "I don't see research findings. Want to run `/feature-research` first? Hypotheses are stronger when informed by research."
3. Analyze the codebase for relevant patterns, existing code, and constraints

## Process

### Step 1: Present Your Thinking

Share your initial synthesis of all the inputs:

> "Based on the problem definition, research, and codebase analysis, here's what I'm thinking..."

Cover:
- What the research suggests about the best approach
- How that fits (or doesn't fit) with the existing codebase
- Where the user's original hypothesis was right
- Where the research suggests a different direction

**Then ask:** "Does this match your thinking? What feels off?"

### Step 2: Long-Term Vision

Work with the user to articulate the long-term vision:

> "Let's think big for a moment. If we nail this and keep building on it for 3 years, what does this become? Not just this feature — how does it fit into the bigger picture?"

Questions to explore:
- How does this feature evolve over time?
- What does it enable that isn't possible today?
- How does it fit into the broader product/system arc?
- What would the v10 version look like?

Create `hypothesis/long-term-vision.md`:
```markdown
# Long-Term Vision: [Feature Name]

## The Big Picture (3 years)
[What this becomes as part of the bigger system]

## How It Evolves
[Phase 1 → Phase 2 → Phase 3 progression]

## What It Enables
[New capabilities, workflows, opportunities]

## Constraints on the Long-Term
[What could limit this vision]
```

### Step 3: Implementation Hypothesis

Now zoom in to the immediate scope:

> "For the sprints we're about to plan — what should the finished result look like? Not the 3-year vision, but what you'd have after building this round of work."

Work through:
1. **What we'll build** — specific technical approach
2. **Why this approach** — how research and codebase analysis informed it
3. **What we chose NOT to do** — alternatives considered and why they were rejected
4. **How it serves the long-term** — connection to the 3-year vision
5. **Risks** — what could go wrong, mitigations
6. **MVP vs full** — what's the minimal version that's still valuable?

**For each point, ask the user to react:**
> "I think we should [approach]. The research suggests [reason]. Your codebase already has [pattern]. Does this make sense to you? Push back if something feels wrong."

Create `hypothesis/implementation.md`:
```markdown
# Implementation Hypothesis: [Feature Name]

## Proposed Approach
[What we'll build and how]

## Why This Approach
[Research findings, codebase fit, tradeoffs]

## Alternatives Considered
[What we chose NOT to do and why]

## Connection to Long-Term Vision
[How this lays the foundation]

## Risks and Mitigations
[What could go wrong]

## MVP Definition
[The minimum that's still valuable]

## Open Questions
[Anything still unresolved]
```

### Step 4: Optional Deep-Dive

Ask:
> "Do you want to go deeper on implementation details? We could map out:
> - Architecture / data models
> - API contracts
> - Component structure
> - Integration points
>
> Or is the high-level hypothesis enough to start planning sprints?"

If they want detail, create additional hypothesis docs (e.g., `hypothesis/architecture.md`).

### Step 5: Suggest Next Step

> "Hypothesis formed. You have three options:
>
> 1. **`/feature-critique`** — Spawn adversarial subagents to stress-test this hypothesis intellectually. Recommended for important features.
>
> 2. **`/feature-validate`** — Test the hypothesis empirically. Run a quick experiment or proof of concept before committing. Recommended when the core bet is unproven.
>
> 3. **`/feature-plan`** — Go straight to sprint planning. Fine for smaller features or when you're already confident.
>
> Which do you prefer?"

## Behavioral Rules

**Do:**
- Present your reasoning, then ask the user to challenge it
- Reference specific research findings when explaining choices
- Distinguish clearly between the long-term vision and immediate implementation
- Make the MVP explicit — what can we skip for now?
- Force the user to engage: don't accept silent approval

**Don't:**
- Dump two documents without conversation — this is interactive
- Ignore the codebase — theoretical best practice that doesn't fit the code is useless
- Make the hypothesis sound certain — use "we think", "the evidence suggests"
- Skip the long-term vision — it prevents short-term decisions that box you in
- Rush to sprint planning — the hypothesis needs to be solid first