Assumption Mapping

Surface hidden assumptions and prioritize which ones to validate before building.

When to Trigger

• User is starting something new
• User expresses uncertainty (“I think…”, “probably…”, “should work…”)
• User is about to invest significant effort
• User mentions building without mentioning validation
• User asks “what should I test first?”

Quick Start

Ask the user:

1. “What are you building and for whom?”
2. “What needs to be true for this to succeed?”

Then run the assumption extraction workflow below.

Core Workflow

Assumption Mapping Progress:
- [ ] Step 1: Extract assumptions from conversation
- [ ] Step 2: Categorize by type
- [ ] Step 3: Score risk and uncertainty
- [ ] Step 4: Prioritize for validation
- [ ] Step 5: Suggest validation methods

Step 1: Extract Assumptions

Listen for assumption signals in what the user says:

Extract 5-10 assumptions. Frame each as a testable statement:

Bad: “Users like simple things” Good: “Users will complete onboarding in under 2 minutes without help”

Step 2: Categorize Assumptions

Assign each assumption to one category:

Step 3: Score Each Assumption

Rate each assumption on two dimensions (1-5 scale):

Impact: If wrong, how badly does it hurt the project?

• 1 = Minor inconvenience
• 5 = Project fails completely

Uncertainty: How confident are we this is true?

• 1 = We have strong evidence
• 5 = Pure guess

Step 4: Prioritize

Create a 2×2 priority matrix:

                    HIGH IMPACT
                         │
     ┌───────────────────┼───────────────────┐
     │                   │                   │
     │   VALIDATE LATER  │  VALIDATE FIRST   │
     │   (Low risk)      │  (Critical)       │
     │                   │                   │
LOW  ├───────────────────┼───────────────────┤ HIGH
UNCERTAINTY              │              UNCERTAINTY
     │                   │                   │
     │   SKIP            │  MONITOR          │
     │   (Safe)          │  (Watch for       │
     │                   │   signals)        │
     │                   │                   │
     └───────────────────┼───────────────────┘
                         │
                    LOW IMPACT

Top-right quadrant = validate before building

Step 5: Suggest Validation Methods

For each critical assumption, suggest a lightweight validation:

See references/validation-methods.md for detailed methods.

Output Template

Automatically save the output to design/03-assumption-mapping.md using the Write tool while presenting findings in this format:

## Assumption Map for [Project Name]

### Critical Assumptions (Validate First)
| # | Assumption | Type | Impact | Uncertainty | Suggested Test |
|---|------------|------|--------|-------------|----------------|
| 1 | [statement] | [type] | [1-5] | [1-5] | [method] |

### Secondary Assumptions (Validate Later)
[Same table format]

### Safe Assumptions (Monitor)
[Bulleted list]

### Recommended Next Steps
1. [First validation to run]
2. [Second validation to run]

Adaptive Behavior

If user is new to assumption mapping:

• Explain briefly why we do this (1 sentence)
• Guide them through extraction with examples
• Keep the output simple

If user is familiar:

• Skip explanations
• Jump to extraction
• Offer the full matrix output

Gauge familiarity by asking: “Have you mapped assumptions before, or should I walk you through it?”

Handoff

Suggest next steps:

“Use this map to prioritize validation tests before full development. Want to proceed with /solution-scoping or test critical assumptions first?”

Note: File is automatically saved to design/03-assumption-mapping.md for context preservation.

Integration Points

This skill works well before:

• problem-framing — if problem isn’t clear yet
• validation — to test the critical assumptions identified here
• ideation — to generate solutions once assumptions are validated

References

• references/validation-methods.md — Detailed validation techniques
• references/examples.md — Complete worked examples