convoke-agents 2.0.0

package/_bmad/bme/_vortex/workflows/hypothesis-engineering/steps/step-02-context.md

@@ -0,0 +1,80 @@
+---
+step: 2
+workflow: hypothesis-engineering
+title: Problem Context & Opportunity Mapping
+---
+
+# Step 2: Problem Context & Opportunity Mapping
+
+Now that we have a validated problem definition, let's unpack it and map the opportunity space for hypothesis generation.
+
+## Why This Matters
+
+Structured brainwriting produces better ideas than unstructured brainstorming — but only if you start from a deep understanding of the problem space. Before we generate a single hypothesis, we need to see the full landscape: which pains are screaming for solutions, which gains represent the biggest behavioral shifts, and where the assumptions in the problem definition create openings for bold, testable bets.
+
+## Your Task
+
+### 1. Unpack the Problem Definition
+
+Let's extract the key elements from your HC2 artifact (or equivalent input):
+
+**Core Problem:**
+- What is the converged problem statement?
+- What is the confidence level (High/Medium/Low)?
+- What is explicitly in and out of scope?
+
+**Jobs-to-be-Done:**
+- What is the primary JTBD? (When [situation], I want to [motivation], so I can [outcome])
+- What functional, emotional, and social jobs are at play?
+
+**Pains & Gains:**
+- Which pains are highest priority? Which are most frequent or intense?
+- Which gains are most desired? Which have the highest expected impact?
+- Where do pains and gains cluster around the same JTBD?
+
+**Evidence & Assumptions:**
+- How strong is the evidence base? How many artifacts, how many evidence points?
+- What contradictions exist in the evidence?
+- What assumptions were flagged? Which are highest risk?
+- Where are the evidence gaps?
+
+### 2. Map the Hypothesis Landscape
+
+Based on the unpacked problem definition, let's identify the opportunity space:
+
+| Dimension | Your Assessment |
+|-----------|----------------|
+| **Strongest opportunities** | Which pain-gain combinations suggest the clearest hypothesis targets? |
+| **Riskiest areas** | Where are assumptions most dangerous (high lethality, high uncertainty)? |
+| **Evidence strength** | Where is evidence strongest? Where are we flying blind? |
+| **Behavioral shift potential** | Which pains, if solved, would create the most visible behavior change? |
+| **Bold vs. safe territory** | What's the safe, obvious hypothesis? What's the bold version? |
+
+What if we looked at this from a completely different angle? Consider:
+- What would happen if the **opposite** of the problem statement were true?
+- Which pain is everyone assuming is the biggest — and what if it's not?
+- Where is the evidence **suspiciously** unanimous? (Consensus can hide blind spots)
+
+### 3. Prioritize Hypothesis Targets
+
+Based on your landscape mapping, identify 1-3 hypothesis targets to pursue in Step 3:
+
+| # | Target Pain/Gain | Why This One | Evidence Strength | Bold Factor |
+|---|-----------------|--------------|-------------------|-------------|
+| 1 | *Most promising target* | *Why it deserves a hypothesis* | High/Medium/Low | Safe / Bold / Radical |
+| 2 | *(optional)* | | | |
+| 3 | *(optional)* | | | |
+
+**Guidance:** Start with the target that has the strongest evidence AND the highest bold factor. That's a safe bet — what's the bold version? Push yourself to include at least one hypothesis target that challenges the obvious answer.
+
+---
+
+## Your Turn
+
+Unpack your problem definition, map the hypothesis landscape, and identify 1-3 hypothesis targets. Share your analysis and I'll help you sharpen the targets before we move to hypothesis drafting.
+
+## Next Step
+
+When your hypothesis targets are identified and prioritized, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/hypothesis-engineering/steps/step-03-brainwriting.md

package/_bmad/bme/_vortex/workflows/hypothesis-engineering/steps/step-03-brainwriting.md

@@ -0,0 +1,79 @@
+---
+step: 3
+workflow: hypothesis-engineering
+title: Structured Brainwriting & Hypothesis Drafting
+---
+
+# Step 3: Structured Brainwriting & Hypothesis Drafting
+
+Time to engineer hypotheses. Not brainstorm. Not wish. Engineer — with structure, precision, and the courage to make falsifiable bets.
+
+## Why This Matters
+
+4-field hypothesis contracts force clarity: belief, evidence needed, experiment, success criteria. Without this structure, teams produce vague aspirations disguised as hypotheses — "We think users will like it" is not a hypothesis. A real hypothesis specifies exactly what outcome you expect, what behavior will change, why you believe it, and the single assumption that could destroy the entire idea. That's the craft of hypothesis engineering.
+
+## Your Task
+
+### 1. Structured Brainwriting
+
+For each hypothesis target identified in Step 2, we'll use structured brainwriting to generate candidate hypotheses. This is NOT unstructured brainstorming — each round has a specific focus:
+
+**Round 1 — Obvious Hypotheses:**
+For each target, write the most obvious hypothesis. The one everyone would agree with. Get it out of the way.
+
+**Round 2 — Bold Alternatives:**
+Now challenge each obvious hypothesis. What's the bold version? What if the opposite were true? What if the pain is actually a symptom of something deeper?
+
+**Round 3 — Synthesis:**
+From rounds 1 and 2, select the 1-3 strongest hypotheses to engineer as formal contracts. Strongest = most evidence-grounded AND most falsifiable.
+
+### 2. Draft Hypothesis Contracts (4-Field Format)
+
+For each selected hypothesis, complete the 4-field contract:
+
+#### Hypothesis {N}: {Title}
+
+**The 4-Field Contract:**
+
+| Field | Your Answer |
+|-------|-------------|
+| **Expected Outcome** | What we expect to happen if the hypothesis is correct. Be specific and measurable — "users will engage more" is too vague. What exactly will happen? |
+| **Target Behavior Change** | What specific user behavior will change, and in what direction? This must be observable and measurable. |
+| **Rationale** | Why we believe this will work — grounded in evidence from the problem definition. Reference specific pains, gains, or JTBD elements. |
+| **Riskiest Assumption** | The single assumption that, if wrong, invalidates the entire hypothesis. This is what must be tested first. |
+
+**Hypothesis Statement:**
+
+> We believe that [target users] will [expected behavior] because [rationale].
+
+### 3. Quality Check Each Hypothesis
+
+Before finalizing, stress-test each hypothesis:
+
+- [ ] **Falsifiable?** Can you describe a result that would prove this hypothesis wrong? If not, sharpen it.
+- [ ] **Specific?** Would two different people interpret the expected outcome the same way?
+- [ ] **Evidence-grounded?** Does the rationale cite specific evidence from the problem definition, or is it gut feeling?
+- [ ] **Riskiest assumption identified?** Is it truly the most lethal assumption, or the most comfortable one to test?
+- [ ] **Bold enough?** Is this the safe bet, or does it push past the obvious? What's the bold version?
+
+Let's stress-test that assumption before we build anything. If your riskiest assumption feels comfortable, it's probably not the riskiest one.
+
+---
+
+## Your Turn
+
+Draft 1-3 hypothesis contracts using the 4-field format above. For each, include the hypothesis statement and complete the quality check. Share your drafts and I'll help sharpen them.
+
+---
+
+**[a]** Advanced Elicitation — Deep dive into hypothesis refinement with guided questioning
+**[p]** Party Mode — Bring in other Vortex agents for collaborative hypothesis critique
+**[c]** Continue — Proceed to assumption extraction and risk mapping
+
+---
+
+## Next Step
+
+When your hypothesis contracts are drafted and quality-checked, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/hypothesis-engineering/steps/step-04-assumption-mapping.md

package/_bmad/bme/_vortex/workflows/hypothesis-engineering/steps/step-04-assumption-mapping.md

@@ -0,0 +1,102 @@
+---
+step: 4
+workflow: hypothesis-engineering
+title: Assumption Extraction & Risk Mapping
+---
+
+# Step 4: Assumption Extraction & Risk Mapping
+
+You've drafted hypothesis contracts. Now let's surface every assumption hiding inside them and figure out which ones could kill us.
+
+## Why This Matters
+
+Assumption mapping separates what we know from what we think we know. Every hypothesis embeds assumptions — about users, about behavior, about the market, about technology. Most teams test the easy assumptions first and ignore the lethal ones. The riskiest assumption gets tested first, not the easiest one. This step ensures you know exactly which assumptions matter most and in what order to validate them.
+
+## Your Task
+
+### 1. Extract All Assumptions
+
+For each hypothesis contract from Step 3, extract every assumption — stated and unstated:
+
+**Hypothesis 1: {Title}**
+- Assumption from Expected Outcome: *What are we assuming about the measurable result?*
+- Assumption from Target Behavior Change: *What are we assuming about how users will respond?*
+- Assumption from Rationale: *What evidence-based claims could be wrong?*
+- Assumption from Riskiest Assumption: *Is this truly the riskiest, or are there hidden ones?*
+- Unstated assumptions: *What are we taking for granted that we haven't examined?*
+
+Repeat for each hypothesis. Be thorough — the assumptions you don't surface are the ones that blindside you.
+
+### 2. Classify Each Assumption
+
+For every extracted assumption, assess two dimensions:
+
+**Lethality** — If this assumption is wrong, what happens?
+- **High:** Kills the hypothesis entirely. The whole idea collapses.
+- **Medium:** Requires a significant pivot. The direction changes.
+- **Low:** Minor adjustment needed. The core idea survives.
+
+**Uncertainty** — How much evidence do we have?
+- **High:** No evidence. We're guessing.
+- **Medium:** Some evidence, but indirect or incomplete.
+- **Low:** Strong evidence from multiple sources.
+
+### 3. Build the Assumption Risk Map
+
+| Assumption | Hypothesis | Lethality | Uncertainty | Priority | Validation Status |
+|------------|-----------|-----------|-------------|----------|-------------------|
+| *What we're assuming* | 1, 2, or 3 | High/Med/Low | High/Med/Low | *Derived* | `Unvalidated` |
+
+**Priority derivation (lethality × uncertainty):**
+
+|  | High Uncertainty | Medium Uncertainty | Low Uncertainty |
+|--|-----------------|-------------------|-----------------|
+| **High Lethality** | **Test First** | **Test First** | Monitor |
+| **Medium Lethality** | **Test Soon** | Test Soon | Monitor |
+| **Low Lethality** | Test Soon | Monitor | Monitor |
+
+- **Test First:** High lethality + High/Medium uncertainty = validate before any experiment
+- **Test Soon:** Medium risk = validate early in the experiment cycle
+- **Monitor:** Low risk = track but don't delay for validation
+
+### 4. Recommended Testing Order
+
+Based on the risk map, sequence your assumptions for validation:
+
+| Priority | Assumption | Hypothesis | Suggested Method | Minimum Evidence |
+|----------|-----------|-----------|-----------------|-----------------|
+| 1 | *Riskiest assumption — test this first* | *Which hypothesis* | *How to test it* | *What would validate or invalidate* |
+| 2 | *Next riskiest* | | | |
+| 3 | *And so on* | | | |
+
+**Guidance:** The testing order should follow the risk map priorities. If two assumptions have equal priority, test the one that affects the most hypotheses first. What if we're wrong about assumption #1? Does it invalidate just one hypothesis, or all of them?
+
+### 5. Flag Concerns (Optional)
+
+If any assumptions feel too risky to test without additional discovery, flag them for potential routing to Isla:
+
+| Concern | Impact | Recommended Action |
+|---------|--------|-------------------|
+| *Unvalidated assumption or knowledge gap* | *How it affects hypothesis quality* | *e.g., "Route to Isla for targeted user research"* |
+
+These flags may trigger HC9 routing in the Compass step — sending specific assumptions back to Isla for validation before proceeding to Wade's experiments.
+
+---
+
+## Your Turn
+
+Extract assumptions from each hypothesis, classify them by lethality × uncertainty, build the risk map, and produce the recommended testing order. Share your analysis and I'll help you challenge any assumptions that feel too comfortable.
+
+---
+
+**[a]** Advanced Elicitation — Deep dive into assumption analysis with guided questioning
+**[p]** Party Mode — Bring in other Vortex agents to challenge your assumptions
+**[c]** Continue — Proceed to synthesis and HC3 artifact generation
+
+---
+
+## Next Step
+
+When your assumption risk map and testing order are complete, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/hypothesis-engineering/steps/step-05-synthesize.md

package/_bmad/bme/_vortex/workflows/hypothesis-engineering/steps/step-05-synthesize.md

@@ -0,0 +1,130 @@
+---
+step: 5
+workflow: hypothesis-engineering
+title: Synthesize & Route
+---
+
+# Step 5: Synthesize & Route
+
+Time to bring everything together. We've validated the problem definition, mapped the opportunity space, engineered hypothesis contracts, and mapped assumptions by risk. Now we produce the HC3 Hypothesis Contract artifact and route to the next step in the Vortex.
+
+## Why This Matters
+
+Every hypothesis we've engineered is a testable bet — but bets are worthless if they're not packaged for action. The HC3 artifact gives Wade everything needed to design experiments: what to test, what to measure, what the riskiest assumptions are, and in what order to validate them. If you can't prove it wrong, it's not a hypothesis — and now we're about to hand these hypotheses to someone who will try to prove them wrong.
+
+## Your Task
+
+### 1. Review Your Hypothesis Contracts
+
+Before we package everything, let's do a final quality pass on each hypothesis:
+
+**For each hypothesis (1-3):**
+
+| Field | Check |
+|-------|-------|
+| **Expected Outcome** | Is it specific and measurable? Would two people agree on what "success" looks like? |
+| **Target Behavior Change** | Is the behavior observable? Can it be measured without subjective interpretation? |
+| **Rationale** | Does it cite specific evidence from the problem definition? Or is it intuition? |
+| **Riskiest Assumption** | Is it truly the most lethal assumption? Or the most comfortable one? |
+| **Hypothesis Statement** | Does "We believe that [users] will [behavior] because [rationale]" feel falsifiable? |
+
+### 2. Review Your Assumption Risk Map
+
+Verify the risk classifications and testing order from Step 4:
+
+- [ ] Every assumption has a lethality and uncertainty score
+- [ ] Priorities are correctly derived (Test First / Test Soon / Monitor)
+- [ ] Testing order prioritizes by lethality × uncertainty, not by convenience
+- [ ] Flagged concerns (if any) identify specific routing to Isla
+
+### 3. Generate the HC3 Artifact
+
+I'll produce the HC3 Hypothesis Contract artifact with this structure:
+
+```yaml
+---
+contract: HC3
+type: artifact
+source_agent: liam
+source_workflow: hypothesis-engineering
+target_agents: [wade]
+input_artifacts:
+  - path: "_bmad-output/vortex-artifacts/{your-hc2-artifact}"
+    contract: HC2
+created: YYYY-MM-DD
+---
+```
+
+**HC3 Required Body Sections:**
+1. **Problem Context** — Problem Statement (from HC2), JTBD Reference, Key Pains Targeted
+2. **Hypothesis Contracts** (1-3) — 4-field format for each: Expected Outcome, Target Behavior Change, Rationale, Riskiest Assumption + Hypothesis Statement
+3. **Assumption Risk Map** — Full table: Assumption, Hypothesis, Lethality, Uncertainty, Priority, Validation Status
+4. **Recommended Testing Order** — Prioritized sequence: Priority, Assumption, Suggested Method, Minimum Evidence
+5. **Flagged Concerns** (optional) — Concern, Impact, Recommended Action
+
+**Save to:** `{output_folder}/vortex-artifacts/hc3-hypothesis-contract-{date}.md`
+
+I'll create this file with all the sections above once you confirm the content is ready.
+
+### 4. Validation Questions
+
+Before we finalize, let's validate:
+
+**Evidence Check:**
+- [ ] Is every hypothesis grounded in specific evidence from the problem definition?
+- [ ] Can we trace each riskiest assumption back to an evidence gap or contradiction?
+- [ ] Did we document the rationale honestly rather than post-hoc rationalizing?
+
+**Falsifiability Check:**
+- [ ] Can each hypothesis be proven wrong? What result would invalidate it?
+- [ ] Are the expected outcomes specific enough to measure unambiguously?
+- [ ] Would Wade know exactly what experiment to design from these contracts?
+
+**Assumption Check:**
+- [ ] Did we surface unstated assumptions, not just the obvious ones?
+- [ ] Is the riskiest assumption truly the most lethal, not just the most visible?
+- [ ] Does the testing order make strategic sense (riskiest first, not easiest first)?
+
+---
+
+## Your Turn
+
+Review the hypothesis contracts and assumption risk map. Confirm when you're ready for me to generate the final HC3 artifact.
+
+---
+
+**[a]** Advanced Elicitation — Deep dive into hypothesis refinement with guided questioning
+**[p]** Party Mode — Bring in other Vortex agents for collaborative hypothesis critique
+**[c]** Continue — Generate the HC3 artifact and proceed to routing
+
+---
+
+## Vortex Compass
+
+Based on what you just completed, here are your evidence-driven options:
+
+| If you learned... | Consider next... | Agent | Why |
+|---|---|---|---|
+| Hypotheses are solid with testable assumptions | lean-experiment | Wade 🧪 | Hypothesis contracts ready for testing (HC3) |
+| ⚡ Critical assumption is unvalidated and too risky to test blind | user-interview | Isla 🔍 | Unvalidated assumption needs discovery before experimentation (HC9) |
+
+> **Note:** These are evidence-based recommendations. You can navigate to any Vortex agent
+> at any time based on your judgment.
+
+**Or run Max's [VN] Vortex Navigation** for a full gap analysis across all streams.
+
+### ⚠️ Insufficient Evidence for Routing
+
+If the evidence gathered so far doesn't clearly point to a single next step:
+
+| To route to... | You need... |
+|----------------|-------------|
+| Wade 🧪 | 1-3 hypothesis contracts with explicit riskiest assumptions and testing order |
+| Isla 🔍 | Specific unvalidated assumption identified with clear research question |
+
+**Workflow-specific signals:**
+- Cannot identify a riskiest assumption → consider revisiting **step-04** for deeper mapping
+- Hypotheses feel vague or unfalsifiable → consider revisiting **step-03** for sharper brainwriting
+- Problem definition itself seems shaky → consider routing back to **Mila** for re-synthesis
+
+**Recommended:** Revisit earlier steps to strengthen your hypotheses, or run **Max's [VN] Vortex Navigation** for a full gap analysis.

package/_bmad/bme/_vortex/workflows/hypothesis-engineering/workflow.md

@@ -0,0 +1,52 @@
+---
+workflow: hypothesis-engineering
+type: step-file
+description: Engineer testable hypotheses from validated problem definitions using structured brainwriting and 4-field contracts
+author: Liam (hypothesis-engineer)
+version: 1.6.0
+---
+
+# Hypothesis Engineering Workflow
+
+This workflow guides you through turning a validated problem definition into 1-3 rigorous, testable hypothesis contracts — each with explicit assumptions, expected outcomes, and a clear riskiest assumption to test first.
+
+## What is Hypothesis Engineering?
+
+Hypothesis engineering is the craft of turning a validated problem into testable bets. Not vague ideas. Not wishful thinking. Structured, falsifiable hypotheses with explicit assumptions you can prove wrong.
+
+That's a safe bet — what's the bold version? Most teams skip this step and jump straight to building. They treat hypotheses as afterthoughts, not engineering artifacts. The result? They build experiments that test nothing, measure the wrong things, and learn nothing useful.
+
+This workflow forces clarity: for each hypothesis, you'll define what you expect to happen, what behavior will change, why you believe it, and — most importantly — the single assumption that could kill the whole idea. If you can't prove it wrong, it's not a hypothesis.
+
+## Workflow Structure
+
+**Step-file architecture:**
+- Just-in-time loading (each step loads only when needed)
+- Sequential enforcement (must complete step N before step N+1)
+- State tracking in frontmatter (progress preserved)
+
+## Steps Overview
+
+1. **Setup & Input Validation** - Validate your problem definition (HC2 artifact or equivalent input)
+2. **Problem Context & Opportunity Mapping** - Unpack JTBD, pains, gains, and identify the hypothesis landscape
+3. **Structured Brainwriting & Hypothesis Drafting** - Engineer 1-3 hypothesis contracts using the 4-field format
+4. **Assumption Extraction & Risk Mapping** - Map all assumptions by lethality × uncertainty and prioritize testing order
+5. **Synthesize & Route** - Produce HC3 hypothesis contract artifact and route via Compass
+
+## Output
+
+**Artifact:** HC3 Hypothesis Contract markdown file in `{output_folder}/vortex-artifacts/hc3-hypothesis-contract-{date}.md`
+
+**Template:** None (HC3 artifact is generated inline during Step 5)
+
+**Schema:** Conforms to HC3 contract (`_bmad/bme/_vortex/contracts/hc3-hypothesis-contract.md`)
+
+**Consumer:** Wade (lean-experiment) uses this to design experiments targeting the riskiest assumptions first.
+
+---
+
+## INITIALIZATION
+
+Load config from {project-root}/_bmad/bme/_vortex/config.yaml
+
+Load step: {project-root}/_bmad/bme/_vortex/workflows/hypothesis-engineering/steps/step-01-setup.md

package/_bmad/bme/_vortex/workflows/lean-experiment/lean-experiment.template.md

@@ -0,0 +1,29 @@
+---
+title: "Lean Experiment: {experiment-name}"
+date: {date}
+type: lean-experiment
+status: {status}
+---
+
+# Lean Experiment: {experiment-name}
+
+## Hypothesis
+
+{hypothesis}
+
+## Experiment Design
+
+{experiment-design}
+
+## Results
+
+{results}
+
+## Decision
+
+{pivot-or-persevere}
+
+---
+
+**Created with:** Convoke v2.0.0
+**Workflow:** lean-experiment

package/_bmad/bme/_vortex/workflows/lean-experiment/steps/step-01-hypothesis.md

@@ -0,0 +1,58 @@
+---
+step: 1
+workflow: lean-experiment
+title: State Hypothesis & Input Validation
+---
+
+# Step 1: State Hypothesis & Input Validation
+
+Before we run any experiment, we need a clear hypothesis to test. Not a hunch. Not a wish. A falsifiable bet with explicit assumptions you can prove wrong.
+
+## Why This Matters
+
+Experiments without hypotheses produce data without direction. You'll measure things, but you won't know what the results mean. A clear hypothesis tells you exactly what result would change your mind — and that's what makes it an experiment instead of a demo.
+
+## Your Task
+
+### 1. What Hypothesis Are You Testing?
+
+Wade expects a hypothesis — ideally from Liam's hypothesis-engineering workflow as an HC3-compliant artifact:
+- **HC3 Hypothesis Contract** (from Liam's `hypothesis-engineering` workflow)
+- **HC3 with Assumption Risk Map** showing which assumptions to test first
+
+You can also bring **any well-formed hypothesis** — Wade accepts input from outside the Vortex pattern. It doesn't have to be HC3-compliant, but having a structured hypothesis with an explicit riskiest assumption makes experiment design dramatically stronger.
+
+### 2. Provide Your Input
+
+Please provide the file path or describe the hypothesis you want to test. For example:
+- `_bmad-output/vortex-artifacts/hc3-hypothesis-contract-2026-03-01.md`
+- Or: "I believe that [users] will [behavior] because [rationale], and the riskiest assumption is [assumption]"
+
+### 3. Input Validation
+
+I'll check your hypothesis for experiment-readiness:
+
+**Hypothesis Statement Check:**
+- [ ] States what you believe will happen (expected outcome)
+- [ ] Identifies a specific behavior change you expect to observe
+- [ ] Provides rationale grounded in evidence (not intuition)
+- [ ] Names the riskiest assumption — the one thing that could kill this
+
+**Falsifiability Check:**
+- [ ] Can you describe a result that would prove this hypothesis wrong?
+- [ ] Are the expected outcomes specific enough that two people would agree on success vs. failure?
+- [ ] Is the riskiest assumption something you can actually observe or measure?
+
+**If your input is incomplete:** That's okay — we'll work through the gaps. But let's be honest about what we know vs. what we're assuming. The experiment will only be as strong as the hypothesis driving it.
+
+---
+
+## Your Turn
+
+Please provide your hypothesis — file path, description, or both. I'll validate it and we'll proceed to designing the experiment.
+
+## Next Step
+
+When your hypothesis is validated and experiment-ready, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/lean-experiment/steps/step-02-design.md

package/_bmad/bme/_vortex/workflows/lean-experiment/steps/step-02-design.md

@@ -0,0 +1,68 @@
+---
+step: 2
+workflow: lean-experiment
+title: Design Experiment
+---
+
+# Step 2: Design Experiment
+
+Now that we have a validated hypothesis, we need to design the leanest possible experiment to test it. Not the best experiment. Not the most thorough. The fastest, cheapest experiment that produces a clear signal.
+
+## Why This Matters
+
+The goal of a lean experiment is learning, not building. Every dollar and day spent on experiment infrastructure is a dollar and day not spent on the next experiment. The leanest experiment that produces a clear pass/fail signal wins — always. Overengineering an experiment is the same mistake as overengineering a product: you invested in confidence you didn't need yet.
+
+## Your Task
+
+### 1. Choose Your Experiment Type
+
+Based on the hypothesis and its riskiest assumption, select the experiment type that produces a clear signal with the least investment:
+
+| Type | When to Use | Example | Investment |
+|------|-------------|---------|------------|
+| **Concierge** | Manually deliver the product experience to a small group | Text dinner suggestions to 15 parents by hand | Days, minimal cost |
+| **Wizard of Oz** | Simulate automation with manual behind-the-scenes work | Users see an "AI" recommendation; a human picks it | Days-weeks |
+| **Smoke Test** | Test demand before building anything | Landing page with signup button, measure conversion | Hours-days |
+| **A/B Test** | Compare two approaches with existing traffic | Show Feature A to 50%, Feature B to 50% | Requires existing traffic |
+| **Prototype Test** | Test usability and comprehension | Clickable mockup with think-aloud observation | Days |
+
+**Selection criteria:** Which type tests the **riskiest assumption** with the **least effort** and produces an **unambiguous signal**?
+
+### 2. Define Your Experiment Design
+
+| Field | Your Answer |
+|-------|-------------|
+| **Experiment Name** | A descriptive name for this experiment |
+| **Type** | Selected from the table above |
+| **Duration** | How long will the experiment run? |
+| **Sample Size** | How many participants/users? (minimum viable for signal clarity) |
+| **Target Population** | Who participates? How will you recruit them? |
+| **What You'll Build** | The minimum artifact needed (landing page, script, prototype, etc.) |
+| **What You Won't Build** | Explicitly list what's out of scope — this prevents scope creep |
+
+### 3. Validate the Design
+
+Before proceeding, stress-test your experiment design:
+
+- [ ] **Does it test the riskiest assumption?** Not a secondary assumption. Not the easy one. The lethal one.
+- [ ] **Is it truly minimal?** Could you make it cheaper, faster, or simpler and still get a clear signal?
+- [ ] **Can it fail?** If every possible outcome looks like success, the experiment isn't testing anything.
+- [ ] **Is the sample meaningful?** Too small = noise. Too large = wasted effort. What's the minimum for a clear signal?
+
+---
+
+## Your Turn
+
+Define your experiment design using the fields above. Share your design and I'll help you trim it to the minimum viable experiment.
+
+---
+
+**[a]** Advanced Elicitation — Deep dive into experiment design trade-offs
+**[p]** Party Mode — Bring in other Vortex agents for experiment critique
+**[c]** Continue — Proceed to defining success metrics
+
+## Next Step
+
+When your experiment design is validated, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/lean-experiment/steps/step-03-metrics.md