Hypothesis lab
Skill ChewbaccaRoars/pathfinder-skills/skills/hypothesis-lab
Everything Pathfinder — 18 Claude Code skills, teaching materials, workshop guides, and resources that turn non-technical people into AI-native builders. /learn, /build, /reflect, /share.
npx -y skills add ChewbaccaRoars/pathfinder-skills --skill hypothesis-labAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Structures every project as an experiment with a hypothesis, test, evidence, and iteration loop. Use when starting a new build, automation, or project, or when the user wants to validate an idea before going all-in.
SKILL.md
3.4 KB, as published. Nobody here has run it
Hypothesis Lab
Overview
Every build starts with a question, not a conclusion. This skill turns projects into structured experiments so you learn whether your idea actually works — not just whether it runs.
Keywords: hypothesis, experiment, test, validate, measure, iterate, learn, evidence, assumption
How It Works
Starting a New Build
When the user starts a new project or automation, guide them through this framework BEFORE writing any code:
Step 1 — State the Hypothesis Ask: "What do you believe will happen if we build this?"
Help them write it in this format:
If [we build/automate/change this thing], then [this measurable outcome will happen], because [this is why we think so].
Example:
If we automate the weekly status report, then it will save the team ~3 hours every Monday, because right now someone manually copies data from 4 spreadsheets into an email.
Step 2 — Surface Assumptions Ask: "What are we assuming is true?" List every assumption explicitly.
Examples:
- "We're assuming the data is always in the same columns"
- "We're assuming everyone wants the report in the same format"
- "We're assuming 3 hours is accurate — we haven't actually timed it"
Label each assumption:
[VERIFIED]— we have evidence this is true[UNTESTED]— we believe this but haven't confirmed[RISKY]— if this is wrong, the whole thing falls apart
Step 3 — Define Success Ask: "How will we know this worked?" Help them pick measurable criteria:
- Time saved (before vs. after)
- Errors reduced
- Steps eliminated
- People impacted
- Frequency of use
Step 4 — Build the Minimum Test Build the smallest possible version that tests the hypothesis. Not the full solution — just enough to learn.
Step 5 — Gather Evidence After building, return to the hypothesis:
- Did the outcome match what we predicted?
- Were our assumptions correct?
- What surprised us?
- What did we learn that we didn't expect?
Step 6 — Iterate or Pivot Based on evidence:
- Confirmed: Great — what's the next hypothesis? How do we expand?
- Partially confirmed: What part worked? What needs adjustment?
- Disproven: That's not failure — that's learning. What does the evidence tell us to try instead?
Experiment Tracker
Maintain a running log of experiments. Format:
## Experiment Log
### Experiment 1: [Name]
- Hypothesis: If [X], then [Y], because [Z]
- Assumptions: [list with labels]
- Result: [confirmed / partially confirmed / disproven]
- Key learning: [what we now know]
- Next step: [what to do with this knowledge]
Save to memory so progress persists across sessions.
Trigger Phrases
Activate when the user says:
- "I have an idea"
- "I want to build something"
- "Let's try something"
- "What if we..."
- "I think we should automate..."
Tone
- Curiosity over certainty: "Let's find out" not "This will work"
- Celebrate learning, not just success: "Now we know something we didn't before"
- Make it safe to be wrong: "A disproven hypothesis is still a win — you just saved yourself from building the wrong thing"
- No jargon — explain "hypothesis" as "your best educated guess about what will happen"