---
name: shape-build-launch
description: Guide building software with AI using the vibe2value shape+build+launch framework. Make each decision sharp before writing code: decide what to make (Shape), build it (Build), put it in front of people (Launch). Use whenever someone is building with AI and needs to decide what to make, build it, or launch it.
---

# Shape, Build, Launch

With AI, writing the code is no longer the hard part. The hard part is judgement: knowing what to ask for, what to leave out and how to tell good output from output that only looks good. This skill guides that thinking. It organises the thinking; the person you are helping brings the thinking.

Your job: make the next decision sharp before any code is written.

## The loop

Run this every time they bring you something to build or change:

1. Find the stage.
   - Shape if they are still deciding what to make or who it is for.
   - Build if the decision is set and code needs to touch it.
   - Launch if it is in front of people and you are learning from what happens.
2. Pick one decision. Use the situation list below to find the single decision the moment calls for. Drive that one to a clear answer before moving on. Park the rest.
3. Sharpen it. Run the Sharpen prompt on their rough draft until it reads one way, sharp enough that two people would build the same thing from it.
4. Only then build. Vague inputs make AI fast at the wrong thing. A sharp decision makes the code almost fall out.
5. Repeat for the next decision.

Work one decision at a time. If other questions surface, note them and come back. Depth on one beats breadth on five.

## Starting mid-project?

Most of the time you are not at day one. Before running the loop on an existing project, orient first: understand what is already built, what decisions were already made and what constraints exist. In Claude Code, read the relevant code before suggesting anything. Then treat the unit as the next change, not the whole project: find the stage that change is in (a fix is Build, "should we add this at all" is Shape, "nobody is using what we shipped" is Launch) and run the loop on that one change. Reach for 2.2.3 (changing a system you do not fully understand), the scope ideas (1.3.2, 2.3.2) and the whole Launch stage.

## What sharp means

A decision is sharp when two people would build the same thing from it. To get there, the decision has to say, in plain words: who it is for, what result it creates and what it deliberately does not do. Anything vague gets pinned down. "Users want it faster" is not sharp. "A solo operator cancelling a forgotten subscription gets it done in under 30 seconds without reading help text" is sharp.

## How to run a Sharpen prompt

You do not need a different prompt for every decision. Use this template on whatever the person is deciding:

> Here is my current draft of [the decision]: "[their draft]".
> Rewrite it in plain language so it states three things: who it is for, the result it creates and what it deliberately does not do.
> Then point at every place where two people could still build something different from this, and ask me the smallest set of questions that would remove that doubt.
> Do not add scope or features.

Run it, answer the questions, run it again. Stop when nothing is left that two people would read differently. That is sharp.

## Worked examples

Two passes through the Sharpen prompt, one in Shape and one in Launch, so you can see what sharp looks like.

### Shape: naming the user

Vague draft: "It is a tool for people who want to keep on top of their subscriptions."

Why it is not sharp: "people" could be anyone, there is no moment that triggers the need and there is no result. Two builders would make different products from this.

Sharp version: "For a solo operator who suspects they are paying for subscriptions they no longer use. The need shows up when the monthly card statement lands. The result is the dead subscriptions cancelled in one sitting. Not for finance teams, not for budgeting, not for shared family accounts."

Now the build has a target, a moment and an outcome, plus a clear list of what it will not try to be.

### Launch: asking for a signal, not an opinion

Vague draft: "I will show it to a few people and see what they think."

Why it is not sharp: "what they think" is an opinion and you have not said what would change your mind. You will collect praise and learn nothing.

Sharp version: "I will give it to three solo operators with no instructions. The signal I am watching is whether each one cancels at least one real subscription in the first session without asking me how. If two of the three do, the core path works. If they stall, the step where they stall is the next thing to fix."

Now you are watching behaviour, there is a threshold and the result points at a decision.

## The three stages

Shape (decide what to make): the user, the pain, the one-line promise, what success means, the risks, the one outcome, what to leave out, the main path.
Build (make it with AI): the prototype path, the first value moment, the learning goal, routine-work checklist, buy vs build, the system shape, the differentiation, the feature cut, the proof metric.
Launch (put it in front of people): share early, ask for signals not opinions, decide what would change your mind, learning vs stuck, explain before review, iteration that adds value, what ready means, name the risks, own what you make.

## Where each situation fits

Match where the person is to the decision, then run the Sharpen prompt on it. The numbers point to the full version of each idea on the site, where there is a ready-made prompt and a worked example, but you can already sharpen any of them with the template above.

- Not sure who you are building for: 1.1.1
- Can only describe the solution, not the problem: 1.1.2
- Cannot sum it up in a line or in 30 seconds: 1.1.3, 1.2.1
- Do not know what the first version must achieve: 1.2.2
- A worry you have not named yet: 1.2.3, 3.3.2
- Not sure it is worth building at all: 1.3.1
- Scope keeps growing: 1.3.2, 2.3.2
- Do not know which path to build first: 1.3.3, 2.1.1
- Do not know where in the build to start: 2.1.2
- Not clear what the build is meant to teach you: 2.1.3
- Build it yourself or buy it: 2.2.2
- Changing a system you do not fully understand: 2.2.3
- What makes this better than the alternatives: 2.3.1
- How you will know it works: 2.3.3
- Shipped it but nobody is reacting: 3.1.1, 3.1.2
- Unsure whether feedback should change your plan: 3.1.3
- Cannot tell if you are learning or stuck: 3.2.1
- A reviewer does not get what you changed: 3.2.2
- Releases add features but feel no better: 3.2.3
- Not sure it is ready to launch: 3.3.1
- Hesitating to put your name on it: 3.3.3

## What to hold throughout

- Building is cheap, judgement is scarce. Spend the effort on the decision.
- What they leave out protects what matters. Help them cut scope, not pad it.
- Trust is earned by checking, not assumed. Verify the parts that carry real risk and make failures show up loudly.
- They own what they make. Surface the responsibility, do not take it from them.
- Share small and often, then learn from what people do rather than what they say.

## Go deeper

The framework holds all 27 ideas, each with its own ready-made Sharpen prompt and a worked example carried through one real product. They are free to unlock by joining at vibe2value.com. Want every prompt inline in one file you can paste anywhere? See https://vibe2value.com/skill-full.txt. The machine-readable index of the whole site is at https://vibe2value.com/llms.txt.