---
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.

## The 27 ideas with their exact prompts

Below is every idea grouped by stage, each with its ready-made Sharpen prompt. Match the decision to an idea, paste its prompt, and run it until the decision is sharp. Generated from vibe2value.com.

### Shape (decide what to make)

#### 1.1.1 If You Can't Name the User, You're Guessing What They Want

Name the user definition: say who the user is, what starts the need and what result they are trying to reach.

**Sharpen prompt** (paste into AI chat, replace the bracketed lines):

```
You are checking whether this user definition is clear enough before you move forward.

Constraint:
The user definition must be specific enough that two people would make the same product decision from it.

Example of the standard:
Vague: "This is for people who want to search the web with AI."
Sharp: "This is for a content creator who manages a website and needs to find gaps in what they have published so they can decide what to write next."
The sharp version is specific enough that two people would make the same product decision. The vague one is not.

Working draft:
User: [name one real user]
Trigger: [what starts the need]
Outcome: [what they are trying to reach]

Task:
Decide whether this user definition is specific enough that two people would make the same product decision. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Can you state who the user is, what starts the need and what result they are trying to reach?

Return:
- Verdict: clear, or needs work
- The corrected three lines, or the original three if already clear
- What was vague, and the one change that fixed it
```

**Worked examples:** subCancel (https://github.com/vibe2value/subcancel/blob/main/knowledge-base/shape-build-launch/shape/user.md) · ghostMarketingFlow (https://github.com/vibe2value/ghost-marketing-flow/blob/main/knowledge-base/shape-build-launch/shape/user.md) · flowRun (https://github.com/vibe2value/flow-run/blob/main/knowledge-base/shape-build-launch/shape/user.md)

#### 1.1.2 Describe the Pain Without Mentioning the Solution

Describe the pain statement: say who is affected, what happens right before the pain appears and what it costs the user or the team.

**Sharpen prompt** (paste into AI chat, replace the bracketed lines):

```
You are checking whether this pain statement is clear enough before you move forward.

Constraint:
The pain statement must be specific enough that two people would frame the same problem from it.

Example of the standard:
Vague: "Users struggle to get useful results from AI search."
Sharp: "A content creator searches for what to write next but gets generic suggestions because the tool does not know what they have already published. They waste time filtering irrelevant results instead of writing."
The sharp version is specific enough that two people would frame the same problem. The vague one is not.

Working draft:
Affected user: [who is affected]
Trigger: [what happens right before the pain appears]
Visible cost: [what it costs the user]

Task:
Decide whether this pain statement is specific enough that two people would frame the same problem. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Can you state who is affected, what happens right before the pain appears and what it costs the user?

Return:
- Verdict: clear, or needs work
- The corrected three lines, or the original three if already clear
- What was vague, and the one change that fixed it
```

#### 1.1.3 The One-Line Promise That Keeps Your Build Honest Throughout

Write the one-line promise: say who it is for, what result it creates and what it is deliberately not trying to do.

**Sharpen prompt** (paste into AI chat, replace the bracketed lines):

```
You are checking whether the one-line promise is clear enough before you decide what to build.
Constraint:
The one-line promise must be specific enough that two people would position the product the same way from it.
Example of the standard:
Vague: "This helps people get better results from AI search."
Sharp: "This helps an organic paid content creator find gaps in what they have already published so they can decide what to write next, without giving generic content advice."
The sharp version is specific enough that two people would position the product the same way. The vague one is not.
Context:
User: [name one real user]
Promised outcome: [name one promised outcome]
Boundary: [name one thing this does not promise]
Task:
Decide whether this one-line promise is clear enough to guide the product. If it already is, say so. If it is vague, rewrite it so you can name one user, one promised outcome and one clear boundary on what is not promised.
Check:
- Does it name one real user instead of a broad audience?
- Is the promised outcome specific enough that two people would describe the same value from it?
- Is the boundary clear enough to stop the promise from expanding?
Return:
- Verdict: clear, or needs work
- The corrected one-line promise, the three lines, or the original if already clear
- What was vague, and the one change that fixed it
```

#### 1.2.1 Can You Explain This in 30 Seconds Without Mentioning the Tech?

Explain the 30-second explanation: explain who it is for, what problem it fixes and what useful result appears without adding a second paragraph.

**Sharpen prompt** (paste into AI chat, replace the bracketed lines):

```
You are checking whether this 30-second explanation is clear enough before you move forward.

Constraint:
The 30-second explanation must be specific enough that two people would describe the same product from it.

Example of the standard:
Vague: "This is an AI search tool that helps people find better answers."
Sharp: "This helps a content creator find gaps in what they have already published so they can decide what to write next, using AI search shaped by their saved context."
The sharp version is specific enough that two people would describe the same product. The vague one is not.

Working draft:
User: [who it is for]
Problem: [what problem it fixes]
Useful result: [what useful result appears]

Task:
Decide whether this 30-second explanation is specific enough that two people would describe the same product. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Does it meet this bar: You can explain who it is for, what problem it fixes and what useful result appears without adding a second paragraph

Return:
- Verdict: clear, or needs work
- The corrected three lines, or the original three if already clear
- What was vague, and the one change that fixed it
```

#### 1.2.2 What Does "Success" Actually Mean for the First Version You Ship?

Define the version one success definition: say what has to happen, how it will be measured and what number or threshold counts as enough.

**Sharpen prompt** (paste into AI chat, replace the bracketed lines):

```
You are checking whether this version one success definition is clear enough before you move forward.

Constraint:
The version one success definition must be specific enough that two people would make the same go or no-go call from it.

Example of the standard:
Vague: "Users find the AI search results useful and keep coming back."
Sharp: "A content creator completes three searches using their saved context, and at least two of those searches return results they act on within the same session."
The sharp version is specific enough that two people would make the same go or no-go call. The vague one is not.

Working draft:
Outcome: [what has to happen]
Metric: [how it will be measured]
Threshold: [what number counts as enough]

Task:
Decide whether this version one success definition is specific enough that two people would make the same go or no-go call. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Can you state what has to happen, how it will be measured and what number or threshold counts as enough?

Return:
- Verdict: clear, or needs work
- The corrected three lines, or the original three if already clear
- What was vague, and the one change that fixed it
```

#### 1.2.3 The Risks You're Avoiding Naming Are the Ones That Bite You

Name the named risk: say what might fail, who or what it would affect and what action will reduce the damage.

**Sharpen prompt** (paste into AI chat, replace the bracketed lines):

```
You are checking whether this named risk is clear enough before you move forward.

Constraint:
The named risk must be specific enough that two people would prepare for the same failure from it.

Example of the standard:
Vague: "There are some risks around whether the AI search results will be useful."
Sharp: "If a content creator’s saved context is too narrow, AI search returns the same results every time and the tool feels broken. The user stops trusting the results before they have tested enough to see the value."
The sharp version is specific enough that two people would prepare for the same failure. The vague one is not.

Working draft:
Likely failure: [what might fail]
Affected user or workflow: [who or what it would affect]
Mitigation: [what action reduces the damage]

Task:
Decide whether this named risk is specific enough that two people would prepare for the same failure. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Can you state what might fail, who or what it would affect and what action will reduce the damage?

Return:
- Verdict: clear, or needs work
- The corrected three lines, or the original three if already clear
- What was vague, and the one change that fixed it
```

#### 1.3.1 The One Outcome That Makes This Build Worth Doing in the First Place

Choose the main outcome: say what changes for the user, why that change matters and what signal will show it is real.

**Sharpen prompt** (paste into AI chat, replace the bracketed lines):

```
You are checking whether this main outcome is clear enough before you move forward.

Constraint:
The main outcome must be specific enough that two people would prioritize the same work from it.

Example of the standard:
Vague: "This creates more value for users of the AI search tool."
Sharp: "A content creator completes a search using their saved context and acts on at least one result in the same session, instead of leaving to search elsewhere."
The sharp version is specific enough that two people would prioritize the same work. The vague one is not.

Working draft:
User outcome: [what changes for the user]
Why it matters: [why that change matters]
Proof signal: [what signal will show it is real]

Task:
Decide whether this main outcome is specific enough that two people would prioritize the same work. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Can you state what changes for the user, why that change matters and what signal will show it is real?

Return:
- Verdict: clear, or needs work
- The corrected three lines, or the original three if already clear
- What was vague, and the one change that fixed it
```

#### 1.3.2 What This Will Not Do (On Purpose) Is Half the Decision

Set the scope boundary: say what stays in, what stays out and why the cut protects the core path.

**Sharpen prompt** (paste into AI chat, replace the bracketed lines):

```
You are checking whether this scope boundary is clear enough before you move forward.

Constraint:
The scope boundary must be specific enough that two people would cut the same feature from it.

Example of the standard:
Vague: "Version one will stay focused and not do too much."
Sharp: "Version one will help a content creator search using their saved context. It will not support multiple saved contexts per user yet because that would complicate the core search flow before it is proven."
The sharp version is specific enough that two people would cut the same feature. The vague one is not.

Working draft:
Keep in: [what stays in scope]
Leave out: [what stays out]
Why the cut helps: [why the cut protects the core path]

Task:
Decide whether this scope boundary is specific enough that two people would cut the same feature. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Can you state what stays in, what stays out and why the cut protects the core path?

Return:
- Verdict: clear, or needs work
- The corrected three lines, or the original three if already clear
- What was vague, and the one change that fixed it
```

#### 1.3.3 Describe One Main Path First, Then Ignore Everything Else

Describe the main path: describe the user, what starts the flow and the exact steps that lead to the outcome.

**Sharpen prompt** (paste into AI chat, replace the bracketed lines):

```
You are checking whether this main path is clear enough before you move forward.

Constraint:
The main path must be specific enough that two people would design the same flow from it.

Example of the standard:
Vague: "Users can explore the search tool in a few different ways."
Sharp: "A content creator opens the app, enters a question about what to write next, sees results shaped by their saved context and acts on one result in the same session."
The sharp version is specific enough that two people would design the same flow. The vague one is not.

Working draft:
User: [who the path is for]
Trigger: [what starts the flow]
Path to outcome: [the exact steps that lead to the outcome]

Task:
Decide whether this main path is specific enough that two people would design the same flow. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Does it meet this bar: You can describe the user, what starts the flow and the exact steps that lead to the outcome

Return:
- Verdict: clear, or needs work
- The corrected three lines, or the original three if already clear
- What was vague, and the one change that fixed it
```

### Build (make it with AI)

#### 2.1.1 The Only Path Your Prototype Actually Needs to Walk

Define the prototype path: say what the prototype is meant to teach, which path will test it and what signal counts as proof.

**Sharpen prompt** (paste into AI chat, replace the bracketed lines):

```
You are checking whether this prototype path is clear enough before you move forward.

Constraint:
The prototype path must be specific enough that two people would build the same thin test from it.

Example of the standard:
Vague: "Test whether people like the check-in email."
Sharp: "Learning goal: whether a solo operator acts on a check-in email instead of ignoring it. Test path: they add three real subscriptions, get one email listing them and click through to mark one for cancel. Proof signal: at least one is marked within 24 hours."
The sharp version is specific enough that two people would build the same test. The vague one is not.

Working draft:
Learning goal: [what the prototype is meant to teach]
Test path: [which path will test it]
Proof signal: [what signal counts as proof]

Task:
Decide whether this prototype path is specific enough that two people would build the same thin test. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Can you state what the prototype teaches, which path tests it and what signal counts as proof?

Return:
- Verdict: clear, or needs work
- The corrected three lines, or the original three if already clear
- What was vague, and the one change that fixed it
```

#### 2.1.2 Where the User First Feels Value Is Where to Start Building

Find the first value moment: point to the moment the user first feels relief or progress and the step immediately before it.

**Sharpen prompt** (paste into AI chat, replace the bracketed lines):

```
You are checking whether this first value moment is clear enough before you move forward.

Constraint:
The first value moment must be specific enough that two people would optimize the same step from it.

Example of the standard:
Vague: "Users feel value once they start using the search tool."
Sharp: "A content creator feels value when the first search result reflects what they have already published, right after they enter their first question with saved context."
The sharp version is specific enough that two people would optimize the same step. The vague one is not.

Working draft:
User: [who first feels value]
First value moment: [the first moment they feel relief or progress]
Step right before it: [the step immediately before that moment]

Task:
Decide whether this first value moment is specific enough that two people would optimize the same step. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Does it meet this bar: You can point to the moment the user first feels relief or progress and the step immediately before it

Return:
- Verdict: clear, or needs work
- The corrected three lines, or the original three if already clear
- What was vague, and the one change that fixed it
```

#### 2.1.3 What This Build Is Meant to Teach You, Not Just to Ship

Name the learning goal: say what you believe, what the build needs to answer and what signal will prove or weaken that belief.

**Sharpen prompt** (paste into AI chat, replace the bracketed lines):

```
You are checking whether this learning goal is clear enough before you move forward.

Constraint:
The learning goal must be specific enough that two people would collect the same evidence from it.

Example of the standard:
Vague: "This build should help us learn what users want from AI search."
Sharp: "This build should tell us whether a content creator gets more relevant results when their saved context shapes the search than when it does not."
The sharp version is specific enough that two people would collect the same evidence. The vague one is not.

Working draft:
Hypothesis: [what you believe]
Question: [what the build needs to answer]
Signal: [what signal will prove or weaken that belief]

Task:
Decide whether this learning goal is specific enough that two people would collect the same evidence. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Can you state what you believe, what the build needs to answer and what signal will prove or weaken that belief?

Return:
- Verdict: clear, or needs work
- The corrected three lines, or the original three if already clear
- What was vague, and the one change that fixed it
```

#### 2.2.1 The Routine Work Checklist Nobody Talks About

Define the routine work checklist: say what repeats, who owns it and what done looks like each time.

**Sharpen prompt** (paste into AI chat, replace the bracketed lines):

```
You are checking whether this routine work checklist is clear enough before you move forward.

Constraint:
The routine work checklist must be specific enough that two people would do the same checks from it.

Example of the standard:
Vague: "We will sort out the routine operational work later."
Sharp: "Every time the tooltip data changes, one person verifies the JSON is valid, checks that each slug matches a published post and confirms the tooltips render correctly before deploying the theme."
The sharp version is specific enough that two people would do the same checks. The vague one is not.

Working draft:
Recurring task: [what repeats]
Owner: [who owns it]
Done condition: [what done looks like each time]

Task:
Decide whether this routine work checklist is specific enough that two people would do the same checks. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Can you state what repeats, who owns it and what done looks like each time?

Return:
- Verdict: clear, or needs work
- The corrected three lines, or the original three if already clear
- What was vague, and the one change that fixed it
```

#### 2.2.2 Buy vs Build Is a Strategy Choice, Not an Engineering One

Make the buy versus build decision: say what the decision is about, why one side wins and which constraint makes the call.

**Sharpen prompt** (paste into AI chat, replace the bracketed lines):

```
You are checking whether this buy versus build decision is clear enough before you move forward.

Constraint:
The buy versus build decision must be specific enough that two people would choose the same leverage point from it.

Example of the standard:
Vague: "We should decide whether to use an existing service or build it ourselves."
Sharp: "Buy authentication because it is not where value lives. Build the context-shaped search because that is where the product makes a unique decision for the user."
The sharp version is specific enough that two people would choose the same leverage point. The vague one is not.

Working draft:
Decision area: [what the decision is about]
Why buy or build: [why one side wins]
Deciding constraint: [which constraint makes the call]

Task:
Decide whether this buy versus build decision is specific enough that two people would choose the same leverage point. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Can you state what the decision is about, why one side wins and which constraint makes the call?

Return:
- Verdict: clear, or needs work
- The corrected three lines, or the original three if already clear
- What was vague, and the one change that fixed it
```

#### 2.2.3 Understanding the Shape of the System Before You Change It

Map the system shape: say which part owns what, what each part depends on and where the important handoff happens.

**Sharpen prompt** (paste into AI chat, replace the bracketed lines):

```
You are checking whether this system shape is clear enough before you move forward.

Constraint:
The system shape must be specific enough that two people would draw the same core boundaries from it.

Example of the standard:
Vague: "The system has a few services that connect together."
Sharp: "The frontend handles the search interface and user context. The Worker orchestrates auth checks, database reads and AI search calls. The database stores preferences and history. Auth is handled externally. Each part has one job and one clear handoff to the next."
The sharp version is specific enough that two people would draw the same core boundaries. The vague one is not.

Working draft:
Part or boundary: [which part owns what]
Dependency or handoff: [where the important dependency or handoff happens]
Ownership boundary: [what each part should not own]

Task:
Decide whether this system shape is specific enough that two people would draw the same core boundaries. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Can you state which part owns what, what each part depends on and where the important handoff happens?

Return:
- Verdict: clear, or needs work
- The corrected three lines, or the original three if already clear
- What was vague, and the one change that fixed it
```

#### 2.3.1 Where the Real Differentiation Actually Lives in Your Build

Name the real differentiation: point to the advantage, show where the user feels it and say what should remain standard.

**Sharpen prompt** (paste into AI chat, replace the bracketed lines):

```
You are checking whether this real differentiation is clear enough before you move forward.

Constraint:
The real differentiation must be specific enough that two people would invest in the same custom work from it.

Example of the standard:
Vague: "Our differentiation is that we use AI to make search better."
Sharp: "Our differentiation is that a content creator gets search results shaped by what they have already published. The context layer is the custom work. Everything else, auth, database, hosting, stays standard."
The sharp version is specific enough that two people would invest in the same custom work. The vague one is not.

Working draft:
Real advantage: [what the real advantage is]
Where the user feels it: [where the user feels that advantage]
What stays standard: [what should remain commodity or standard]

Task:
Decide whether this real differentiation is specific enough that two people would invest in the same custom work. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Does it meet this bar: You can point to the advantage, show where the user feels it and say what should remain standard

Return:
- Verdict: clear, or needs work
- The corrected three lines, or the original three if already clear
- What was vague, and the one change that fixed it
```

#### 2.3.2 Why Cutting Features Is a Design Skill Most Builders Skip

Choose the feature cut: say what stays central, what gets removed and why the product becomes stronger because of that cut.

**Sharpen prompt** (paste into AI chat, replace the bracketed lines):

```
You are checking whether this feature cut is clear enough before you move forward.

Constraint:
The feature cut must be specific enough that two people would remove the same complexity from it.

Example of the standard:
Vague: "We should probably keep the search tool simple."
Sharp: "We are cutting query history from version one because the core test is whether a content creator can search with their saved context and act on a result in one session. History adds UI complexity without proving the context layer works."
The sharp version is specific enough that two people would remove the same complexity. The vague one is not.

Working draft:
Core path to protect: [what must stay central]
Feature to cut: [what gets removed]
Why the cut strengthens it: [why the product gets stronger because of that cut]

Task:
Decide whether this feature cut is specific enough that two people would remove the same complexity. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Can you state what stays central, what gets removed and why the product becomes stronger because of that cut?

Return:
- Verdict: clear, or needs work
- The corrected three lines, or the original three if already clear
- What was vague, and the one change that fixed it
```

#### 2.3.3 The One Metric That Proves This Works for Real Users

Define the proof metric: say what the metric is, what user behavior creates it and what threshold counts as enough.

**Sharpen prompt** (paste into AI chat, replace the bracketed lines):

```
You are checking whether this proof metric is clear enough before you move forward.

Constraint:
The proof metric must be specific enough that two people would make the same keep or cut decision from it.

Example of the standard:
Vague: "We will track engagement and adoption of the search tool."
Sharp: "We will track how many content creators act on at least one context-shaped search result in the same session. We will treat two out of three searches producing an actionable result as proof that the context layer is working."
The sharp version is specific enough that two people would make the same keep or cut decision. The vague one is not.

Working draft:
Metric: [what the metric is]
User behavior behind it: [what user behavior creates it]
Threshold: [what threshold counts as enough]

Task:
Decide whether this proof metric is specific enough that two people would make the same keep or cut decision. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Can you state what the metric is, what user behavior creates it and what threshold counts as enough?

Return:
- Verdict: clear, or needs work
- The corrected three lines, or the original three if already clear
- What was vague, and the one change that fixed it
```

### Launch (put it in front of people)

#### 3.1.1 Why Sharing Early Creates the Learning Your Build Needs

Plan the early sharing plan: say who will see it, what they will see and what question their reaction needs to answer.

**Sharpen prompt** (paste into AI chat, replace the bracketed lines):

```
You are checking whether this early sharing plan is clear enough before you move forward.

Constraint:
The early sharing plan must be specific enough that two people would run the same learning loop from it.

Example of the standard:
Vague: "We should share the search tool early and get feedback."
Sharp: "Show the context-shaped search to five content creators who publish weekly and ask whether the results feel more relevant than what they get from a generic search tool."
The sharp version is specific enough that two people would run the same learning loop. The vague one is not.

Working draft:
Audience: [who will see it]
What they will see: [what they will see]
Question to answer: [what question their reaction needs to answer]

Task:
Decide whether this early sharing plan is specific enough that two people would run the same learning loop. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Can you state who will see it, what they will see and what question their reaction needs to answer?

Return:
- Verdict: clear, or needs work
- The corrected three lines, or the original three if already clear
- What was vague, and the one change that fixed it
```

#### 3.1.2 Ask for Signals, Not Opinions, From the People You Trust

Choose the decision signal: point to the behavior or result you need to see and explain what decision it will change.

**Sharpen prompt** (paste into AI chat, replace the bracketed lines):

```
You are checking whether this decision signal is clear enough before you move forward.

Constraint:
The decision signal must be specific enough that two people would interpret the same evidence from it.

Example of the standard:
Vague: "We want feedback on whether people like the search results."
Sharp: "We want to see whether a content creator acts on a context-shaped search result in the same session, because that behaviour will tell us whether the context layer is adding real value or just adding steps."
The sharp version is specific enough that two people would interpret the same evidence. The vague one is not.

Working draft:
Signal to watch: [what behavior or result you need to see]
Behavior behind it: [what action creates that signal]
Decision it changes: [what decision it will change]

Task:
Decide whether this decision signal is specific enough that two people would interpret the same evidence. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Does it meet this bar: You can point to the behavior or result you need to see and explain what decision it will change

Return:
- Verdict: clear, or needs work
- The corrected three lines, or the original three if already clear
- What was vague, and the one change that fixed it
```

#### 3.1.3 Decide in Advance What Would Change Your Mind

Set the decision threshold: say what evidence will trigger change, where it will come from and what action follows.

**Sharpen prompt** (paste into AI chat, replace the bracketed lines):

```
You are checking whether this decision threshold is clear enough before you move forward.

Constraint:
The decision threshold must be specific enough that two people would make the same course correction from it.

Example of the standard:
Vague: "We will keep watching the search results and change course if needed."
Sharp: "If fewer than two out of three content creators act on a context-shaped result in the same session, we will stop adding features and fix how context shapes the query before continuing."
The sharp version is specific enough that two people would make the same course correction. The vague one is not.

Working draft:
Threshold: [what evidence will trigger change]
Evidence source: [where that evidence comes from]
Action that follows: [what action follows if it is met or missed]

Task:
Decide whether this decision threshold is specific enough that two people would make the same course correction. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Can you state what evidence will trigger change, where it will come from and what action follows?

Return:
- Verdict: clear, or needs work
- The corrected three lines, or the original three if already clear
- What was vague, and the one change that fixed it
```

#### 3.2.1 The Difference Between Learning and Being Stuck

Name the learning signal: say what question is being answered, what signal will answer it and what decision comes next.

**Sharpen prompt** (paste into AI chat, replace the bracketed lines):

```
You are checking whether this learning signal is clear enough before you move forward.

Constraint:
The learning signal must be specific enough that two people would call the same work progress from it.

Example of the standard:
Vague: "We are iterating and learning as we go."
Sharp: "After each round of testing, we check whether content creators acted on at least one context-shaped result. If they did, the context layer is working and we iterate on result quality. If they did not, we stop and investigate whether the context is shaping the query at all."
The sharp version is specific enough that two people would call the same work progress. The vague one is not.

Working draft:
Learning question: [what question is being answered]
Signal: [what signal will answer it]
Next decision: [what decision comes next]

Task:
Decide whether this learning signal is specific enough that two people would call the same work progress. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Can you state what question is being answered, what signal will answer it and what decision comes next?

Return:
- Verdict: clear, or needs work
- The corrected three lines, or the original three if already clear
- What was vague, and the one change that fixed it
```

#### 3.2.2 Explain Your Decisions Before Asking for Review

Explain the review context: say what was decided, what trade-off it created and what question you want reviewers to answer.

**Sharpen prompt** (paste into AI chat, replace the bracketed lines):

```
You are checking whether this review context is clear enough before you move forward.

Constraint:
The review context must be specific enough that two people would ask reviewers for the same kind of feedback from it.

Example of the standard:
Vague: "Here is the latest version, let me know what you think."
Sharp: "We chose to shape search results using saved context instead of browsing history. The trade-off is that results are only as good as the context the user sets. The question for reviewers is whether the context setup flow is clear enough that a content creator would complete it without help."
The sharp version is specific enough that two people would ask reviewers for the same kind of feedback. The vague one is not.

Working draft:
Decision made: [what was decided]
Trade-off created: [what trade-off it created]
Question for reviewers: [what reviewers should answer]

Task:
Decide whether this review context is specific enough that two people would ask reviewers for the same kind of feedback. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Can you state what was decided, what trade-off it created and what question you want reviewers to answer?

Return:
- Verdict: clear, or needs work
- The corrected three lines, or the original three if already clear
- What was vague, and the one change that fixed it
```

#### 3.2.3 Iteration Should Increase Value, Not Just Add Surface Area

Check the iteration value test: say what changed, what user outcome it is meant to improve and what signal will show that it did.

**Sharpen prompt** (paste into AI chat, replace the bracketed lines):

```
You are checking whether this iteration value test is clear enough before you move forward.

Constraint:
The iteration value test must be specific enough that two people would judge the same release as worthwhile from it.

Example of the standard:
Vague: "We shipped an update and it feels better."
Sharp: "We changed how context shapes the AI search query. The test is whether content creators now act on results more often than before the change. If the actionable result rate stays the same or drops, the change did not increase value."
The sharp version is specific enough that two people would judge the same release as worthwhile. The vague one is not.

Working draft:
Release change: [what changed in this iteration]
User outcome to improve: [what user outcome it should improve]
Proof signal: [what signal will show that it helped]

Task:
Decide whether this iteration value test is specific enough that two people would judge the same release as worthwhile. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Can you state what changed, what user outcome it is meant to improve and what signal will show that it did?

Return:
- Verdict: clear, or needs work
- The corrected three lines, or the original three if already clear
- What was vague, and the one change that fixed it
```

#### 3.3.1 What "Ready" Actually Means Once Real Users Are Looking

Define the readiness rule: say what has to be true, how it will be checked and who owns any remaining risk.

**Sharpen prompt** (paste into AI chat, replace the bracketed lines):

```
You are checking whether this readiness rule is clear enough before you move forward.

Constraint:
The readiness rule must be specific enough that two people would make the same ship or hold call from it.

Example of the standard:
Vague: "We will ship when it feels ready."
Sharp: "Ready means a content creator can complete three searches with saved context and act on at least two results, the deployment runs without manual steps, and any known limitations are documented in the UI."
The sharp version is specific enough that two people would make the same ship or hold call. The vague one is not.

Working draft:
Pass check: [what has to be true]
How it is checked: [how it will be checked]
Remaining risk owner: [who owns any remaining risk]

Task:
Decide whether this readiness rule is specific enough that two people would make the same ship or hold call. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Can you state what has to be true, how it will be checked and who owns any remaining risk?

Return:
- Verdict: clear, or needs work
- The corrected three lines, or the original three if already clear
- What was vague, and the one change that fixed it
```

#### 3.3.2 Name the Risks Yourself Before Users Find Them in Production

Name the launch risk: say what might break, what would trigger it and what response reduces the damage.

**Sharpen prompt** (paste into AI chat, replace the bracketed lines):

```
You are checking whether this launch risk is clear enough before you move forward.

Constraint:
The launch risk must be specific enough that two people would prepare for the same failure from it.

Example of the standard:
Vague: "There are probably some edge cases we have not thought of."
Sharp: "If a content creator’s saved context contains only a few words, the AI search may return results no different from a generic search. The trigger is any context shorter than a sentence. The response is to prompt the user to add more detail before running the search."
The sharp version is specific enough that two people would prepare for the same failure. The vague one is not.

Working draft:
Risk: [what might break]
Likely trigger: [what would trigger it]
Fallback or mitigation: [what response reduces the damage]

Task:
Decide whether this launch risk is specific enough that two people would prepare for the same failure. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Can you state what might break, what would trigger it and what response reduces the damage?

Return:
- Verdict: clear, or needs work
- The corrected three lines, or the original three if already clear
- What was vague, and the one change that fixed it
```

#### 3.3.3 Are You Comfortable Putting Your Name on This Build?

Set the ownership threshold: say what is still imperfect, what would happen if it failed and why shipping is still acceptable under those conditions.

**Sharpen prompt** (paste into AI chat, replace the bracketed lines):

```
You are checking whether this ownership threshold is clear enough before you move forward.

Constraint:
The ownership threshold must be specific enough that two people would make the same release call from it.

Example of the standard:
Vague: "It is good enough to ship."
Sharp: "The context layer sometimes returns similar results for different queries when the saved context is very specific. If this happens, the user sees less variety than expected. Shipping is acceptable because the core flow still works, the limitation is documented and the fix is scoped for the next iteration."
The sharp version is specific enough that two people would make the same release call. The vague one is not.

Working draft:
Unresolved gap: [what is still imperfect]
User impact if it fails: [what would happen if it failed]
Why shipping is acceptable now: [why shipping is still acceptable under those conditions]

Task:
Decide whether this ownership threshold is specific enough that two people would make the same release call. If it already is, say so. If it is vague, rewrite it to meet the standard in the example above.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Can you state what is still imperfect, what would happen if it failed and why shipping is still acceptable under those conditions?

Return:
- Verdict: clear, or needs work
- The corrected three lines, or the original three if already clear
- What was vague, and the one change that fixed it
```

## Go deeper

Those are all 27 prompts. For the worked examples in full, the diagrams, and a free 1:1 working session to apply this to what you are building, see vibe2value.com. The machine-readable index of the whole site is at https://vibe2value.com/llms.txt.