vibe2value, built in the open
The shape+build+launch framework is the product. This page is me using it on a real build: vibe2value itself. Every decision here is made with the shape-build-launch skill and recorded as it is sharpened, in the open, so you can see how the skill is used and what it produces.
How I run it
I use the shape-build-launch skill in Claude Code (installed from the marketplace, or pasted from /skill.txt). When a real decision comes up I run /shape-build-launch:guide and work one decision at a time: find the stage, pick the one idea the moment calls for, and sharpen it until two people would build the same thing from it. Only then do I build. The sharpened answer gets recorded below.
The decisions
One made so far, of 27. The rest are the questions still to ask, in order.
| Idea | Produces | Status |
|---|---|---|
| 1.1.1 If You Can't Name the User, You're Guessing What They Want | user.md | Decided |
| 1.1.2 Describe the Pain Without Mentioning the Solution | problem.md | To come |
| 1.1.3 The One-Line Promise That Keeps Your Build Honest Throughout | promise.md | To come |
| 1.2.1 Can You Explain This in 30 Seconds Without Mentioning the Tech? | positioning.md | To come |
| 1.2.2 What Does "Success" Actually Mean for the First Version You Ship? | success.md | To come |
| 1.2.3 The Risks You're Avoiding Naming Are the Ones That Bite You | risks.md | To come |
| 1.3.1 The One Outcome That Makes This Build Worth Doing in the First Place | goal.md | To come |
| 1.3.2 What This Will Not Do (On Purpose) Is Half the Decision | scope.md | To come |
| 1.3.3 Describe One Main Path First, Then Ignore Everything Else | path.md | To come |
| 2.1.1 The Only Path Your Prototype Actually Needs to Walk | prototype-path.md | To come |
| 2.1.2 Where the User First Feels Value Is Where to Start Building | first-value-moment.md | To come |
| 2.1.3 What This Build Is Meant to Teach You, Not Just to Ship | learning-goal.md | To come |
| 2.2.1 The Routine Work Checklist Nobody Talks About | routine-checklist.md | To come |
| 2.2.2 Buy vs Build Is a Strategy Choice, Not an Engineering One | buy-vs-build.md | Decided |
| 2.2.3 Understanding the Shape of the System Before You Change It | system-shape.md | To come |
| 2.3.1 Where the Real Differentiation Actually Lives in Your Build | differentiation.md | To come |
| 2.3.2 Why Cutting Features Is a Design Skill Most Builders Skip | feature-cut.md | To come |
| 2.3.3 The One Metric That Proves This Works for Real Users | proof-metric.md | To come |
| 3.1.1 Why Sharing Early Creates the Learning Your Build Needs | early-sharing-plan.md | To come |
| 3.1.2 Ask for Signals, Not Opinions, From the People You Trust | decision-signal.md | To come |
| 3.1.3 Decide in Advance What Would Change Your Mind | decision-threshold.md | To come |
| 3.2.1 The Difference Between Learning and Being Stuck | learning-signal.md | To come |
| 3.2.2 Explain Your Decisions Before Asking for Review | review-context.md | To come |
| 3.2.3 Iteration Should Increase Value, Not Just Add Surface Area | iteration-value-test.md | To come |
| 3.3.1 What "Ready" Actually Means Once Real Users Are Looking | readiness-rule.md | To come |
| 3.3.2 Name the Risks Yourself Before Users Find Them in Production | launch-risks.md | To come |
| 3.3.3 Are You Comfortable Putting Your Name on This Build? | ownership-check.md | To come |
user.md
knowledge-base/shape-build-launch/shape/user.md
The framework idea: 1.1.1 If You Can't Name the User, You're Guessing What They Want.
What I typed to trigger the skill:
Most likely a dev or solo builder of an app that they want to take to market. They may have vibed something but now need it production ready.
How it mapped: My prompt names who the product is for, which is a name-the-user decision, so it maps to idea 1.1.1.
The skill's Sharpen prompt for naming the user:
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 itWhat the skill returned (saved as user.md):
Verdict: needs work, then sharpened.
- User: a solo developer or builder who has vibe-coded a working prototype of an app.
- Trigger: they decide to take it to market and realise it is not production-ready.
- Outcome: a production-ready app they can trust and launch.
What was vague and the fix: "take it to market" did not say what was missing. Naming production-ready as the gap and the moment it bites made it sharp.
That sharpened user reshaped the homepage to lead with a free 1:1.
buy-vs-build.md
knowledge-base/shape-build-launch/build/buy-vs-build.md
The framework idea: 2.2.2 Buy vs Build Is a Strategy Choice, Not an Engineering One.
What I typed to trigger the skill:
Should I build vibe2value from scratch, or use an existing service like Ghost for content and marketing, plus GitHub to share content?
How it mapped: My prompt asks whether to build from scratch or use a service, which is a buy versus build decision, so it maps to idea 2.2.2.
The skill's Sharpen prompt for the buy versus build decision:
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 itWhat the skill returned (saved as buy-vs-build.md):
Verdict: needs work, then sharpened.
- Decision area: the content and marketing platform for vibe2value.
- Why buy: the platform is plumbing, not where the product makes a unique decision. Building it would spend the scarce resource, judgement and time, on undifferentiated work.
- Deciding constraint: build only what is differentiated (the framework, the skill, the content) and buy the commodity (Ghost, hosting, email, GitHub).
What was vague and the fix: "an existing service or from scratch" did not say where value lives. Naming the platform as plumbing and judgement as the scarce resource made the call obvious.
New here? The framework is free to read: start at start here, or for developers if you build. Want the same skill on your own work? It is at /skill.txt.