launch

Based on founder-launch by Jake Schincariol (MIT). Changed by Aya Taleb: starts from the validate skill's tests and pass/fail lines, adds a go/no-go gate, a countdown tool with a critical path, and local and online paths.

Launching is a project with a date. This skill turns everything in founder/ into a dated plan, and it starts with proof: the cheapest test that shows real people will pay, run before the big money goes out.

What the user typed after /launch: $ARGUMENTS

Reads and writes

• Reads first: the business context (founder/context.md, else the active file under ~/.founder/businesses/). Then the validate skill's files: founder/validate.md (the tests, the call), founder/validate-plan.json (the locked pass and fail lines) and founder/validate-results.json (the counts), then founder/idea.md, founder/ops.md (lead times, permits), founder/numbers.json and founder/cfo.md (break-even), founder/marketing.md, founder/brand.md, founder/board.md (conditions). Say which ones exist and which are missing.
• Writes: founder/launch-tasks.json, founder/countdown.md (from the tool) and founder/launch.md.
• Tool: scripts/countdown.py turns tasks with lead times into dates and a critical path.

Step 1: the test comes first

Open founder/validate.md. It holds the riskiest assumption, one to three demand tests, and a pass/fail line written before each test ran. Copy those into the top of the plan as they are. Do not loosen a pass line after the fact; that line exists so the founder cannot talk themselves into a launch.

If founder/validate-plan.json and founder/validate-results.json exist and the validate skill is installed, let its tool read the result rather than reading it yourself: python3 <validate skill dir>/scripts/testplan.py read founder/validate-plan.json founder/validate-results.json. It also flags any line that moved after it was locked. If it says a line moved, treat the result as soft and say so. "Unclear" or "too early" counts as not passed yet.

Then read where each test stands:

The cheapest real test by business type:

Setting the pass line

A pass line is a real number and a deadline, written before the test starts. Never leave it as {{N}}: a blank line can't fail, so the test can't stop a bad launch.

If founder/cfo.md has a break-even, base the line on it: enough paid orders in the test window to show the break-even pace is reachable. Show the sum in one line.

If there is no break-even, set the line from what the founder can tell you now, and show the reasoning so they can change it before the test starts:

1. Ask for two things they know: the planned price, and how many customers a month would make them keep going (or how many they can serve). Ask once, in one message.
2. Pass line = paid commitments (pre-orders, deposits or paid pilots) at the planned price, from people who aren't friends or family, within 14 days. Count: about a quarter of the monthly number they gave, rounded, so it shows the first month is within reach.
3. If they can't give a monthly number, don't pick one for them. Offer a range for their kind of business and ask them to choose a number inside it before the test starts:
   • local, food, subscription or product: 10 to 30 paid pre-orders in 14 days
   • service or agency: 2 to 5 paid pilots in 30 days
   • online product or app: 10 to 50 paid pre-orders or deposits from the landing page in 14 days Say why a range: the right bar depends on price, reach and what they can serve, and they know those better. The low end is the least that rules out friends-only demand. If they are not there to answer, write the plan with the pass line marked "to set before the test: pick N between 10 and 30" and make choosing it task 1.
4. Add a fail line under it ("under 8 by day 14: stop and rethink the offer or price") and what "unclear" means (between the two: run one more week, then decide).

Write it like this in the plan:

Pass: 20 paid pre-orders at $12 a lunch by Nov 20 (14 days). Fail: under 8. Why 20: no break-even yet; you said 80 regular customers a month would keep you going, and a quarter of that in two weeks shows the first month is reachable.

Without a monthly number, the founder picks from the range and the plan says so:

Pass: 15 paid pre-orders at $12 a lunch by Nov 20 (14 days), your pick from 10 to 30. Fail: under 6.

Keep {{...}} only for a number only the founder can give, such as a price they haven't set: "20 paid pre-orders at {{your planned price}} by Nov 20". The count and the deadline are always filled in. Suggest /founder-cfo to get a real break-even before the money spend after the gate.

If the simulated buyer panel from /founder-consumer ran, compare the real result with its buy rate. Trust real buyers over simulated ones when they disagree.

Step 2: the countdown

Ask for the target date once. If there is none, plan to the earliest realistic date.

Write founder/launch-tasks.json: each task with an id, owner, days (including lead times from founder/ops.md and supplier quotes), what it waits for, and "gate": true on the demand test. The shape is in the tool's header. Cover:

• Legal and money: registration, bank account, insurance, 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.md, starting launch minus 14 days.
• Team: hiring and training on the routines in founder/ops.md.
• A soft open (local) or a private beta (online) before the public launch.

Then run:

python3 -I "${CLAUDE_SKILL_DIR}/scripts/countdown.py" founder/launch-tasks.json --launch YYYY-MM-DD --out founder/countdown.md

It gives the start-by and finish-by date of every task, the critical path, and whether the date fits. If it says the date does not fit, tell the founder the earliest date it gives, and which task to shorten to keep their date. Never move dates by hand to make it fit.

Lead times you do not know (a permit, a supplier) go in as the founder's best estimate, marked est. in the task name, with a task to confirm them in week 1.

Step 3: launch day

An hour-by-hour run sheet: who is where, what goes out on which channel, the opening offer (from founder/offer.md if present), and what to do if something breaks (from the risk register in founder/ops.md). The founder posts and sends everything themselves; the plan says what and when.

If the founder wants a short promo video for launch day, the launch-video skill makes a script and scene plan from the product or brief.

Step 4: the first 30 days

The weekly numbers to track: units a day against break-even (from founder/cfo.md), and the channel numbers from founder/marketing.md. For each, the level that triggers a change and what the change is. Reviews on days 7, 14 and 30, each with three questions to answer. If there is no break-even yet, track against the pass-line pace from Step 1 (20 orders in 14 days is about 10 a week), mark it "interim until /founder-cfo", and list /founder-cfo under what is missing. Never make up a break-even. Trigger levels are the founder's call: base them on a test result where one exists ("the concierge test kept 80%, so act under 60%") and say so, or leave {{your trigger}}.

Output

founder/launch.md, in this order:

1. The test: assumption, test, pass line, status, result.
2. Go or no-go: one line.
3. The countdown (paste founder/countdown.md) and the critical path.
4. Launch-day run sheet.
5. First 30 days: numbers, triggers, review dates.
6. What is missing, and which skill fills it.

In chat: the go or no-go line, the launch date and whether it fits, the critical path in a line, and the next step. Next: /founder-plan compiles everything into the business plan.

Rules

• No countdown on a failed test. No big spend scheduled before a gate passes.
• Every date comes from the tool and the task file, not from memory.
• No invented lead times, numbers or results. Unknown is {{...}} or est. with a task to confirm it.
• The founder posts, sends and signs. The plan never says a post "goes out automatically".
• Not legal advice. Permits and registrations depend on the city and state; the plan says what to check and with whom.