--- name: ship-v1 description: Ship the smallest live version of a side project in one weekend, post it, then let real signal decide what to build next. An anti-roadmap protocol for the volume game → shrink scope until the path to live fits a weekend, ship to production, post where your audience is, set a signal checkpoint, then continue, pivot, or drop. Use whenever the user wants to start or launch a side project, says "I have an idea", "what should I build", "help me ship this", "turn this into an MVP", "weekend project", or "I keep starting projects and never finish", or has an early product with no users yet. Trigger even when the words "ship" or "v1" are absent → any time someone has an unvalidated product idea and needs it live fast. Do NOT use for goals with a known outcome and a long path, or products that already have users or a hard deadline → those go to goal-breakdown. --- # Ship v1 Get the smallest live version of a side project shipped and posted in a weekend. Then let signal decide what is next. This is not a roadmap. It is the opposite of one. ## When to use this vs goal-breakdown - **ship-v1**: new product, no users yet, idea unvalidated. The volume game. You do not know if anyone wants this, so the fastest way to find out is to ship it. - **goal-breakdown**: outcome is known and worth doing, path is long, product already has users, or there is a hard deadline. The route needs planning. Use that skill instead. If you are unsure which one applies, ask one question: does this product have users yet? No → ship-v1. Yes → goal-breakdown. ## Why one pass, not a plan Early side projects do not fail from bad planning. They fail because nobody wanted the thing, or because you over-built one guess instead of taking more shots. A 7-step roadmap on a zero-user product is over-engineering with a shipping label. So this skill refuses to pre-plan features. It gets you live, gets you signal, and only then decides what comes next. Planning is where shipping goes to hide. ## The protocol Run these in order. One pass. No milestone list. ### 1. Shrink to a weekend State the idea in one line. Then cut scope until the path to a live, usable version fits one weekend of work. If it does not fit, cut more. The cut is the skill. Strip every feature that is not the one thing the product does. Test: can a stranger get the core value in the first 30 seconds with what is left? If yes, that is v1. ### 2. Define the one done-state v1 is done when it is **live AND posted**. Live alone is not done. A product nobody has seen has generated zero signal, which was the whole point. Write the done-state as one sentence so it is unambiguous. ### 3. Validation check (lightweight) - **Your own problem** → you are the validation. Ship it. You understand the problem and you are user number one. - **Not your problem** → get one real signal before building. One person who has the problem and would use the fix. Not a poll, not a like. One concrete yes. - For any pricing or UX call, run the Mom Test: would you sell this exact thing to your mother without tricking her? If not, change it. ### 4. Ship it live Dumb-simple stack. Ship to production. The thing that makes shipping fast sane is not nerve, it is backups → one live copy, one local, one off-site, before you touch prod. Failsafes let you move fast. MVP shortcuts and hacks are fine to get live. Just know they are temporary and replace them before they bite. ### 5. Post it Put it where your audience is. Tell the story of why you built it, not a feature list. Building in public is free user acquisition. You pay with your time and your name, and it beats SEO and ads when you have no budget. No story → no distribution → no signal. ### 6. Signal checkpoint Set a date now. A week is usually enough. - **Signal** (people used it, replied, signed up, paid) → the next thing you build is whatever those users asked for. Not what you imagined. Pull the next move from real demand. - **No signal** → pivot or drop. Do not add features to a product nobody reacted to. Move to the next shot. Do not write milestones 2 through N at any point. The product earns its roadmap only after it has users, and at that point you switch to goal-breakdown. ## Output style Clean markdown. No preamble, no motivational filler. Lead with the cut-down v1 and the done-state. Keep each step to one or two lines. End with the single next action the user can start today → almost always "build the rough version this weekend and post it." ## Principles it encodes For tracing the logic: Force luck by volume, Solve your own problem first, Ship straight to production with failsafes, Enemy of good is perfect, Distribution is the only moat, Telling your story is free user acquisition, The Mom Test, Keep the stack dumb-simple.