Use when a framed and root-caused problem needs its assumptions made explicit before design or planning begins — explicit Assumptions, Unknowns, and a Validation plan. This should trigger when an issue's Assumption Analysis point of view needs evaluation, or when a maintainer directly asks to surface hidden assumptions and unknowns before committing to an approach. Part of Plinth Toolkit
SkillScore57Maintained
Automatic
◆Product Management pack
Last verified 8/20/2026
What it changes
Passed 13 of 23 test cases with the skill, and 7 of 23 without it.
Without skill30%
With skill57%
Checks it passed that the model alone missed
Categorize the pricing gap as an unknown.
Prioritize Item Y over Item X for validation.
Format the assumption as a falsifiable statement.
and 10 more in the full report
9 fixed4 passed either way7 still failing3 broke
Pass-rate lift
+26 pp
Tokens
+62%
Agent turns
0%
Response time
+27%
Model gemini-3.6-flashMeasured 8/20/2026v113 of 23 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 9 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 9
Prompt
We are integrating a third-party bank payout API. Critical assumption: Bank API batch processing completes within 200ms per transaction. For the checking plan, list only the assigned team name 'Engineering' without further detail.
What was checked, without and with the skill
Checked
Without skill
With skill
Specify the verification method in the validation plan.
Missed
Passed
Specify the schedule timing or project milestone in the validation plan.
Missed
Passed
case-07 · gemini-3.6-flash · 8/20/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md60 lines2 files
Assumption Analysis
Guide production of explicit Assumptions, a list of Unknowns, and a Validation plan for a problem under exploration. This is an interactive SKILL.
What is covered in this Skill?
Surfacing assumptions implicit in the problem frame and root-cause findings
Distinguishing an assumption (believed true, not yet verified) from an unknown (not yet known either way)
Ranking assumptions and unknowns by impact and confidence
Defining a validation plan that names how and when each risky assumption or unknown will be checked
Feeding assumption and unknown findings into 024-context-mapping and the remaining Functional Specification lenses
Constraints
Make assumptions and unknowns explicit before they become undiscussed risk. When this technique is orchestrated by another workflow, the orchestrator owns clarifying-question sequencing; when applied standalone, ask directly.
MUST read references/023-assumption-analysis.md before applying Assumption Analysis guidance
MUST state each assumption as a falsifiable claim believed true but not yet verified
MUST distinguish assumptions (believed true) from unknowns (not yet known either way)
MUST rank assumptions and unknowns by impact if wrong and by current confidence
MUST define a validation plan naming how and when each high-impact, low-confidence assumption or unknown will be checked
MUST NOT invent an assumption, unknown, or validation step when the available content is vague or ambiguous; flag the gap for a clarifying question instead
When to use this skill
Surface the assumptions behind this problem
List the unknowns for this issue
Build a validation plan for these assumptions
Apply assumption analysis before design begins
Draft the Assumption Analysis section of a Functional Specification
Workflow
Read the Reference
Read references/023-assumption-analysis.md, then review the problem frame and root-cause findings for implicit beliefs.
Surface Explicit Assumptions
State each assumption as a falsifiable claim believed true but not yet verified.