Founder validation loop

Skill tanveerriaz/Skillz/skills/founder-validation-loop

Use when turning experiments and one-off builds into validated, reusable assets. Runs a tight loop — hypothesis, cheapest test, signal, decide, capture — so a builder learns fast and converts scattered prototypes into repeatable building blocks instead of throwaway work.From its SKILL.md

Install

npx -y skills add tanveerriaz/Skillz --skill founder-validation-loop

Assembled 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.

SKILL.md

3.3 KB, as published. Nobody here has run it

Purpose

Help solo builders and founders learn fast and compound their work. Builders generate many experiments; most insight and reusable value gets lost. This skill makes each experiment a deliberate test with a decision and a captured asset, so building becomes a compounding system rather than a pile of abandoned prototypes.

When to Use

Use when starting a new experiment or side build, when deciding whether to continue/kill an idea, or when a prototype "worked" and you want to extract the reusable part before moving on.

Inputs

The idea or experiment and what you're trying to learn.
The signal that would count as success or failure.
Time/resource budget for the test.

Outputs

A one-line hypothesis and the cheapest test of it.
The observed signal and a clear keep / kill / pivot decision.
A captured reusable asset (skill, template, snippet, or note) regardless of outcome.

Procedure

State the hypothesis. "I believe [X]. If true, I'd see [signal]." Make it falsifiable.
Pick the cheapest valid test. What's the least work that produces a real signal? Prefer a landing page, manual concierge version, or a tiny prototype over a full build.
Set the bar in advance. Decide what result means keep vs. kill vs. pivot before running — so you don't rationalize afterward.
Run the test and observe the actual signal (usage, replies, conversions, whether it works).
Decide honestly: keep (double down), kill (stop, no sunk-cost), or pivot (adjust the hypothesis).
Capture the asset. Extract whatever is reusable — a code pattern, a template, a checklist, a skill — and store it so the next build starts ahead. Even a kill yields a lesson worth capturing.
Feed it forward. Reusable wins become skills/templates in your library; insights inform the next hypothesis.

Quality Checklist

Hypothesis is one line and falsifiable
Test is the cheapest valid way to get signal
Success/failure bar set before running
Decision made honestly (keep/kill/pivot)
No sunk-cost reasoning
A reusable asset or lesson captured
Result feeds the next experiment

Edge Cases

Weak/ambiguous signal: treat as inconclusive; design a sharper test rather than forcing a decision.
Emotionally attached to the idea: lean harder on the pre-set bar to stay honest.
"Successful" test, messy build: still extract the reusable part before moving on.
No time for a full test: shrink the test, not the rigor.

Safety Rules

Don't move the success bar after seeing results.
Don't keep an idea alive on sunk cost alone.
Keep captured assets public-safe — generalize anything tied to private data or clients.

Examples

Good: "Hypothesis: builders want a skills marketplace. Test: a one-page repo + post; bar: 25 stars in a week. Result: 60 stars → keep. Captured: the repo structure as a reusable template."

Bad: Spending a month building a full product, getting no usage, and starting the next thing from scratch with nothing reused and no recorded lesson.