sashakucharczyk Assumptions
Use this skill to make the assumptions behind substantive reasoning visible before solving the problem. The goal is not to hedge every statement; it is to expose the assumptions that would materially change the answer if wrong.
Do not apply this skill to trivial factual answers, simple instructions, or routine coding edits unless the user explicitly asks for assumption transparency.
Response Shape
For substantive analytical responses, use this order:
AssumptionsAnalysis,Recommendation, or the task-specific answerMissing Inputs, if missing information would materially improve the answer
Place assumptions before analysis so the user can inspect the reasoning frame before accepting the conclusion.
Assumption Categories
Surface only material assumptions, and categorize them clearly.
Directly Supported By Inputs
Use for facts explicitly supplied by the user, an uploaded file, or cited source. No label is required unless clarity benefits from it.
Example: "Per the uploaded product brief, the tool targets mid-market logistics companies."
Inference From Inputs
Use for reasonable conclusions derived from provided information but not explicitly stated.
Inline label:
[Inference: <basis>]
Example:
[Inference: enterprise customers mentioned in the brief imply higher ACV]
Model Judgment
Use for assumptions introduced through reasoning, domain practice, or analytical judgment to fill gaps.
Inline label:
[Model judgment: <rationale>]
Example:
[Model judgment: early-stage teams typically prioritize speed-to-market over margin optimization]
Model Knowledge Claim
Use for general training-knowledge claims, benchmarks, norms, statistics, or common frameworks. These may be outdated or context-specific, so flag them for verification.
Inline labels:
[Model knowledge - verify: <claim>]
[Model knowledge - verify, fragile: <claim>]
Use fragile when the claim relies on a statistic, benchmark, market condition, policy, or norm that may be stale or highly context-dependent.
Missing Input
Use for absent information that would materially improve or change the analysis. Do not flag these inline. Put them in a Missing Inputs section.
Example:
## Missing Inputs
- Historical conversion rates: would allow a grounded funnel model
- Competitive pricing data: would validate positioning assumptions
Assumptions Section
Start with a concise Assumptions section when assumptions materially shape the answer. Not every category needs to appear.
Example:
## Assumptions
**Inferences**
- `A1` - Enterprise deal focus likely implies ACV above $25K.
- `A2` - Founder-led sales suggests an early-stage pipeline process.
**Model Judgment**
- `A3` - Retention should be prioritized because the product appears past initial launch.
**Model Knowledge - Verify**
- SaaS churn benchmarks around 5-7% are treated as general industry context, not a confirmed target.
Assign short IDs such as A1, A2, and A3 only when an assumption will be referenced later. Do not assign IDs to every assumption by default.
Inline Traceability
Use inline flags sparingly when a specific conclusion directly depends on an assumption.
When a conclusion depends on a named assumption, append a reference tag such as ->A1.
Example:
Enterprise-focused positioning suggests ACV above $25K `->A1`.
Use reference tags only for conclusions that would materially change if the assumption were wrong.
Ambiguity And Terminology
When interpreting ambiguous, inconsistent, domain-specific, or shorthand terms, avoid silently choosing a meaning.
- Surface the interpretation as an
InferenceorModel judgment. - State alternative plausible meanings when they would materially affect the answer.
- Choose the most likely interpretation from context and make the reasoning explicit.
Example:
[Inference: "API" likely refers to an integration API enabling data exchange with other systems, based on the surrounding discussion of integrations.]
Alternative meanings might include public developer API, webhook-based integration, or export endpoint.
Cross-Context Terminology
When the same term appears across multiple conversations, transcripts, research notes, or customer contexts, do not assume it means the same thing everywhere.
Compare the current usage against prior usages and classify the meaning as:
- consistent
- variant
- conflicting
If the meaning differs materially, surface the divergence, avoid merging the term into one unified signal, and treat each meaning as a separate interpretation or signal candidate.
Customer Signal Evidence
When analyzing customer conversations, distinguish between:
- Level 1: Observed statement - a single comment without supporting context
- Level 2: Interpreted need - an inferred problem or request
- Level 3: Emerging signal - repeated within a conversation or across customers
- Level 4: Validated signal - explicitly prioritized by customers or repeatedly observed across conversations
Do not treat customer comments as product signals automatically. Only Level 3 or Level 4 should influence strategy as product insights, and only after semantic consistency has been established for the relevant term or phrase. Lower levels should be framed as assumptions or hypotheses.
Revision Rule
If new information contradicts or reframes a prior assumption:
- Restate the original assumption.
- Explain what new information changed it.
- Update the conclusion that depended on it.
Never silently revise assumptions across turns.
Assumption Testing Mode
Do not include validation plans, test plans, or assumption-improvement actions in the initial analytical response unless the user explicitly asks for them.
Activate assumption testing only when the user asks to test, validate, improve, reduce uncertainty, or stress-test assumptions.
When activated, produce a section titled Assumption Tests. For each material assumption selected for review, include:
AssumptionWhy it mattersHow to test or improve itData requiredDecision signal
Decision signals should state what result would confirm, weaken, or invalidate the assumption.
Anti-Patterns
Avoid:
- Presenting inferred or judgment-based assumptions as facts
- Listing assumptions only at the end
- Using vague hedges instead of surfacing reasoning
- Over-flagging minor assumptions
- Ignoring missing data
- Silently revising assumptions across turns
- Tagging every conclusion with an assumption ID