mvp-cut
Skill0 starsChanged 4 months agoMITView on GitHub
Cut a feature list down to a shippable MVP by scoring features against the riskiest assumption and defining a two-week slice with a success metric. Use when the user wants to scope an MVP, prioritize features, decide what to build first, or is stuck planning version one.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- Asno-dev/apextheir own version, first seen Oct 15, 2026
- thefacelessdon/faceworktheir own version, first seen Aug 21, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- Asno-dev/apex★ 1same name
- thefacelessdon/facework★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository10 other files it gives its agents.
- cold-outreachSkill
- competitor-scanSkill
- customer-discoverySkill
- hiring-kitSkill
- investor-updateSkill
- landing-copySkill
- launch-planSkill
- metrics-reviewSkill
- pitch-deck-reviewSkill
- pricing-strategySkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Ask the user: "If one belief being wrong would kill this product, which is it?" Usually one of:
- Distinctive: line 34
Cut: does not test the assumption.
- Distinctive: line 49
If a feature survives scoring but nobody can say which assumption it tests, cut it.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
MVP Cut
An MVP is not a small product. It is the cheapest experiment that tests the riskiest assumption. This skill forces that discipline.
Process
1. Name the riskiest assumption
Ask the user: "If one belief being wrong would kill this product, which is it?" Usually one of:
- People have this problem badly enough to switch (demand risk)
- People will pay this much (pricing risk)
- We can build it well enough (feasibility risk)
- We can reach these people affordably (distribution risk)
Everything in the MVP must serve testing that one assumption. If the user cannot pick one, demand risk is the default for a new product.
2. Score the feature list
Take their full feature list and score each item:
| Feature | Tests the assumption? (0/1) | Effort (S/M/L) | Verdict |
Verdicts:
- Build: tests the assumption, effort S or M
- Fake it: tests the assumption but effort L. Propose the concierge or Wizard-of-Oz version (manual backend, no-code front, waitlist with payment intent)
- Cut: does not test the assumption. Settings pages, admin panels, multi-tenancy, native apps, and integrations almost always land here for v1.
Login/auth gets special scrutiny: if the test works with a magic link or no accounts at all, cut real auth.
3. Define the slice
Output a plan:
- Scope: the Build list plus Fake-it workarounds, sized to roughly two weeks of the user's actual capacity (ask what that is)
- Success metric: one number with a threshold and a deadline, e.g. "5 of 20 trial users return in week 2." Decided before launch, not after.
- Kill criteria: what result means the assumption is wrong. Writing this down now prevents moving the goalposts later.
Rules
- One assumption per MVP. Testing two means learning neither.
- If a feature survives scoring but nobody can say which assumption it tests, cut it.
- Push back when the "two-week slice" is secretly two months. Halve scope, not quality of the test.
- Cut features go to a visible "v2 parking lot" list so the user does not feel they lost them.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.