prove-it
Skill3 starsChanged 12 days agoMITView on GitHub
Your launch lead. Builds a dated, step-by-step launch plan: a cheap real-world test first (a waitlist, a pre-sale or a pop-up with a real price, so real buyers confirm what the simulated panel said), then the countdown to opening day with owners and deadlines, the launch-day run sheet, and the first 30 days of what to measure and what to change. Use when the user says "how do I launch", "launch plan", "when can I open", "launch checklist", "go live", or "soft open".
28 other projects use a version of this.
Adopted by
Most recently taken up by
- ryanda9910/prove-ittheir own version, first seen Nov 8, 2026
- decebal/chief-of-staff-v2their own version, first seen Nov 8, 2026
- SaudSatopay/bullseyetheir own version, first seen Nov 8, 2026
- anotherben/claude-harnesstheir own version, first seen Nov 8, 2026
- SylphxAI/skillstheir own version, first seen Nov 1, 2026
- nagi-studio/skillstheir own version, first seen Nov 1, 2026
Used with
Projects with it also use root-cause, challenge and 4 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
Ingramradical235Skillroot-cause
Structured root cause analysis using WHERE (MECE decomposition) then WHY (causal structure diagrams) pipeline. Includes coin-flip detection, logical-leap detection, and vicious cycle intervention. Use when buffer enters YELLOW/RED, when metrics stall, or when Actions execute but don't produce results.
Also in 3 projects that use this
michalattSkillchallenge
Pressure-test plans, decisions, and directions by picking and answering the most relevant challenge questions for the current conversation
Also in 3 projects that use this
renatorozasSkillgrill
Adversarial code review. Don't let me ship until the changes pass your scrutiny.
Also in 4 projects that use this
AWSSkillretro
Conduct a retrospective on a coding session.
Also in 3 projects that use this
MicrosoftSkillhandoff
Compact the current conversation into a handoff document for another agent to pick up.
Also in 3 projects that use this
GoogleSkilltdd
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
Also in 3 projects that use this
Other versions28 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 28
- nagi-studio/skills★ 470same name
- AlemTuzlak/skills★ 45same name
- Neko-Catpital-Labs/Invoker★ 20same name
- anotherben/claude-harness★ 7same name
- nadirali1350/vetted★ 5same name
- Xnadir/vetted★ 5same name
- SaudSatopay/bullseye★ 4same name
- drewdrewthis/claude-skills★ 2same name
- dundas/thinkrun★ 2same name
- duvi-ai/skills★ 2same name
18 more not listed
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 repository13 other files it gives its agents.
- burn-testSkill
- dealbreakerSkill
- first-dollarSkill
- ground-truthSkill
- handshakeSkill
- kill-or-buildSkill
- litmusSkill
- reality-checkSkill
- receiptsSkill
- shark-boardSkill
- signalSkill
- straight-talkSkill
- truth-serumSkill
The file
We split this skill into the rules it gives an agent
7 rules. 0 are common, 4 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 26 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 31
Do I know what has to be done?
- Distinctive: line 32
Do I have the people? (one named owner who will push it every day)
- Distinctive: line 41
Test the riskiest assumption first, and on its own.
- Very specific: line 57
Write two lines before running it, and log both as PLANNED with ledger.py add so they cannot be moved afterwards:
- Very specific: line 65
When the test ends, log the result as MEASURED, kind demand, with the commitment it asked for (--commitment paid for a pre-order, signed …
- Very specific: line 74
Do not book the big costs in founder/numbers.json (a lease, equipment, hires) until the success line is met.
- Distinctive: line 99
Only now, with real buyers, fix and improve: first what they complained about, then what stopped others buying.
“Common” is measured: kept by at least 6 in 10 of the 26 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
prove-it
Launching is a project with a date. This skill turns everything else in the pack into a dated plan, and starts with the cheapest way to find out if real people will pay before the big money goes out. This test is where the pack's guesses meet reality, so it comes first and it is never skipped.
Read ${CLAUDE_SKILL_DIR}/../receipts/rules.md first.
Step 0: ready (the seven questions)
Ready, Fire, Aim (rule 11 in rules.md): get it ready fast, test it for real, then
perfect what works. Before the test, answer in writing, a line or two each:
- Is it a good idea? (what the board, competitors and real calls say, with labels)
- Does it feel like one? (the founder's own gut, stated honestly)
- Is it economically feasible? (from
founder/cfo.md) - Can I afford to test it? (the test's cost against the cash available)
- Do I know what has to be done? (the critical tasks)
- Do I have the people? (one named owner who will push it every day)
- What is Plan B? (what you do if it fails, and the kill line below)
Then write the plan in four pages at most, the same day if you can: rough numbers, the critical tasks with dates, the owner, and Plan B. A plan that takes weeks to write is a way of not starting.
Step 1: test before you spend
Test the riskiest assumption first, and on its own. If an idea has two unknowns (will they want it, and can we make it well enough), find out the first with the cheapest test before paying to solve the second.
Pick the cheapest real test that fits the business, and run it before signing the
big costs in founder/numbers.json:
| business | the test |
| physical shop or café | a pop-up, a market stall or a pre-order list with a price and a date |
| online product | a landing page with the price and a "pre-order" or "join the waitlist" button |
| service or agency | three paid pilot clients at the planned price |
| software or service sold to businesses | five to ten people who have the problem, then a time-boxed pilot offer (from /handshake) to the ones who feel it most |
| subscription | a founding-member offer, paid up front |
| any product not built yet | a pre-sale with a delivery date and a full refund if it slips, or a similar product someone else makes, sold with your angle, to learn what sells before you build |
Write two lines before running it, and log both as PLANNED with ledger.py
add so they cannot be moved afterwards:
- The success line: for example, 50 pre-orders in two weeks at $6.50, or 2 of 5 firms agree to a pilot.
- The kill line: the result that means stop or change course, for example under 15 pre-orders, or 0 of 10 firms after a real ask.
When the test ends, log the result as MEASURED, kind demand, with the
commitment it asked for (--commitment paid for a pre-order, signed for a
pilot, booked for a booked meeting), the count as the number (0 if nobody
said yes), and the
evidence (the order export, the signed page, the emails), even if it is zero.
Compare it with the panel's buy rate. Real buyers win every time: if they fall
short of the panel, go back to /dealbreaker or /litmus; if they
hit the kill line, say so plainly and do not move the line.
Do not book the big costs in founder/numbers.json (a lease, equipment, hires)
until the success line is met.
Step 2: the countdown
From today to launch day, with real dates (ask for the target date; default to the
earliest realistic one given lead times in founder/ops.md). Weekly blocks, each
task with an owner and a deadline:
- Legal and money: registration, bank account, permits from
founder/ops.md. - Build: fit-out or website, suppliers ordered by their lead times.
- Brand: sign, packaging, profiles from
founder/brand.md. - Marketing: the calendar in
founder/marketing.mdfrom launch minus 14 days. - Team: hiring and training on the SOPs.
- A soft open or friends-and-family day before the public launch.
Mark the critical path: the tasks that move the launch date if they slip.
Step 3: launch day
An hour-by-hour run sheet: who is where, what goes out on which channel, the opening offer, what to do if something breaks (from the risk register).
Step 4: the first 30 days (aim)
Only now, with real buyers, fix and improve: first what they complained about, then what stopped others buying. Keep a short list of improvements and ship one at a time on a schedule, telling customers what changed. Do not rebuild what is selling; make it a little better each round.
The weekly numbers to track (from the CFO: units a day against break-even; from marketing: the channel numbers), the level that triggers a change, and a review on days 7, 14 and 30 with the questions to answer.
Output
founder/launch.md with the hard truth first (the most likely way the test
fails), then the test with its success and kill lines, the countdown, the run
sheet and the 30-day review. Next: run the test, log it with
/receipts, then /kill-or-build compiles everything into the
business plan.
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.