Assumption Map

Assumption Map

Surface hidden assumptions behind a plan, feature, or decision. Rank them by risk (probability × impact if wrong), then propose the cheapest experiment that would credibly validate each.

Usage

/assumption-map ""   # map assumptions for a specific thing
/assumption-map                                       # map assumptions behind the current task context
/assumption-map --technical                           # focus on technical/architecture assumptions only
/assumption-map --product                             # focus on user/market/business assumptions only

Behavior

Step 1 — Establish the subject

If $ARGUMENTS is provided, use it as the subject. Otherwise, ask:

> What are we mapping assumptions for? (feature, technical decision, architecture choice, or product bet)

Step 2 — Extract assumptions by category

Generate assumptions across these four layers, using the subject as context:

Desirability assumptions (do users want this?)

• Users have the problem we think they have
• Users will change their current behavior to use this
• The UX we plan is how users expect to solve it
• The benefit is compelling enough to overcome switching cost

Feasibility assumptions (can we build it?)

• The technology stack can support this without major re-architecture
• The performance characteristics will meet requirements at scale
• The required third-party APIs / data sources are accessible and reliable
• The team has the skills to deliver this in the timeframe

Viability assumptions (is it sustainable?)

• The economics work (build + operate cost

VALIDATE NOW (highest risk) [1] Users will abandon their spreadsheet workflow for this tool Confidence: Low | Impact if wrong: Catastrophic Test: Interview 5 current spreadsheet users — ask about switching triggers Validated when: 3/5 name a specific pain point our tool eliminates

[2] The vector database can handle 10M embeddings at p95 10k recipients per call Confidence: Medium | Impact if wrong: Major Test: Read SendGrid docs / call with test batch Validated when: Confirmed in API docs or test succeeds

[4] The chosen data model handles multi-tenancy without schema changes Confidence: Medium | Impact if wrong: Major Test: Model two tenants with different configs against the schema Validated when: Both cases work without adding columns

MONITOR (low risk — check at next milestone) [5] The team can deliver this in 6 weeks Confidence: High | Impact if wrong: Major

ACCEPT (low risk — not worth testing) [6] Markdown rendering will work in the UI Confidence: High | Impact if wrong: Minor

## Edge Cases

- **Too many assumptions**: Focus the map on assumptions that affect the go/no-go decision in the next sprint or milestone. Defer long-horizon assumptions.
- **Technical decision only**: Use the Technical/Architecture layer only; skip Desirability and Viability.
- **Already in progress**: Flag assumptions that were never validated but have already been acted upon — these are the riskiest.

## Token Optimization

**Expected range**: 300–900 tokens

**Patterns used**: Progressive disclosure (map first, experiments on request), early exit (if subject is clear from context, skip asking)

**No caching needed**: Each assumption map is context-specific and not reusable across sessions.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [manastalukdar](https://github.com/manastalukdar)
- **Source:** [manastalukdar/ai-devstudio](https://github.com/manastalukdar/ai-devstudio)
- **License:** MIT

Install and usage instructions live in the source repository linked above.