7 expert-grade prompts to take you from "I have 12 features" to a LIVE Lovable URL with the best MVP, QA'd. Action-first. Built for the Build Sprint 60-min session. Paste-ready.
Each prompt summons a specific scope-killing expert in its ROLE section. Marty Cagan (Inspired) on PM discipline. Bob Moesta (JTBD) on user journey. Ryan Singer (Shape Up) on shaping and pitching. Senior PM personas on PRDs that ship. Erin Catto on Lovable + Supabase patterns. Cal Newport on project plans that don't slip.
"Save this as `[prompt-name].md` in my project folder." Claude Code / Cursor create the file directly. claude.ai users copy-paste into a new .md file. By end of session you have 7 .md files documenting your entire scope decision.
Optional. Run ONCE at the top of your chat. Claude introspects what it knows about your project (from your hackathon landing page or past sessions), confirms it, then auto-fills [BRACKETS] in every subsequent prompt.
# ROLE
You are my Build Sprint scope partner for the next 90 minutes. You'll help me draft a 1-page PRD, map my user journey, and plan a 24-day build.
# GOAL
Before we start: read what you know about my project from prior context (landing page from Saturday's hackathon, past discussions, my product idea). Then confirm with me.
# OUTPUT
Restate, in this exact format:
- **Product (one line):** [your understanding]
- **Target user (specific):** [your understanding]
- **Pain it solves:** [your understanding]
- **What we shipped Saturday:** [your understanding of the landing page]
- **Approximate email signups so far:** [if mentioned]
End with: "Reply 'yes' if accurate, or correct any line. I'll auto-fill these in every prompt for the rest of the session."
# DELIVERABLE — save to project folder
After I confirm the context is right, tell me: "Save this confirmed context as `project_context.md` in my project folder." This becomes the reference document Claude (and you) reuse for the next 23 days.
# SELF-CHECK
- ✓ Did I list ALL 5 fields above?
- ✓ Did I use the user's actual words where possible?
- ✓ Am I asking for confirmation, not assuming?
- ✓ Did I (Claude) save `project_context.md` after confirmation?
First we go BIG. Claude reads your Saturday hackathon landing page, understands the promise you made + who you're serving, and produces a complete 1-page PRD with the top 10 features that would make this product great. This is your full ambition document. Tomorrow we'll cut. Today we capture.
# ROLE
You are a senior product manager who has shipped at scale at top-tier consumer companies and coached hundreds of thousands of PMs on writing 1-page PRDs that actually ship. You read landing pages like x-rays — you can tell from the hero what feature must exist for the promise to be real.
# GOAL
Write the COMPLETE 1-page PRD for my product, sourced from the landing page I shipped Saturday. Capture the top 10 features that would make this product great. Big and complete first. We'll cut next.
# CONTEXT (Claude will reuse prior context — fill only what's needed)
NOTE · This is a 30-day program. If we've talked about this product before, Claude reuses that context. Only fill the brackets Claude doesn't already know.
- Saturday landing page URL: [LOVABLE / NETLIFY URL]
- OR landing page text (if URL isn't accessible): [PASTE HERO + SUBHEAD + BULLETS]
- Product name: [NAME]
- Email signups since Saturday: [NUMBER]
- Any verbatim feedback from early signups: [QUOTES OR "NONE YET"]
- Days to v1 ship: 5
# CONSTRAINTS
- Every feature in the PRD must directly serve the promise made on the landing page
- Features are verb-first user actions (e.g., "Upload 3 articles → get next in your voice") — not infrastructure ("auth system")
- The 10 features must be RANKED in order of impact on the hero promise
- Each feature has 1-line description max
- Format: fits on one phone screen if printed
# OUTPUT FORMAT
**📋 PRD · [PRODUCT NAME] · v1 (full ambition)**
**1. Hero line (from your landing page)**
[Restated verbatim or refined in 1 sentence]
**2. Target user (observable, not persona)**
[The specific moment + behavior, e.g., "Freelance writers 1+ week behind on their content calendar"]
**3. The promise (what your landing page tells them they'll get)**
[1 sentence — what does the user walk away with?]
**4. Top 10 features (ranked by impact on the promise)**
| Rank | Feature (verb the user does) | Why it serves the promise |
|------|------------------------------|---------------------------|
| 1 | [feature] | [1-sentence why] |
| 2 | [feature] | [1-sentence why] |
| 3 | [feature] | [1-sentence why] |
| 4 | [feature] | [1-sentence why] |
| 5 | [feature] | [1-sentence why] |
| 6 | [feature] | [1-sentence why] |
| 7 | [feature] | [1-sentence why] |
| 8 | [feature] | [1-sentence why] |
| 9 | [feature] | [1-sentence why] |
| 10 | [feature] | [1-sentence why] |
**5. Success metric (the ONE number we'll know by Day 30)**
[One number. Measurable. Forces a pass/fail decision.]
**6. What we'll learn from v1**
[The ONE question this product answers about real users.]
# DELIVERABLE — save to project folder
After generating the PRD, save the output as a Markdown file. Tell Claude: "Save this as `prd_v1_full.md` in my project folder." If using Claude Code or Cursor, the file is created directly. Otherwise copy-paste into a new .md file.
# IF CLAUDE CAN'T READ YOUR LANDING PAGE URL
Claude can't browse the web directly. If the URL fails:
- Option A: Open your landing page → select all text → copy → paste into the prompt
- Option B: Screenshot the hero, scroll down, screenshot each section → upload all to Claude
- Option C: Describe the landing page in 3 lines: hero · subhead · CTA
# SELF-CHECK
- ✓ Are EXACTLY 10 features listed?
- ✓ Is each feature a verb the user does (not infrastructure)?
- ✓ Does feature #1 directly deliver the hero promise?
- ✓ Are features ranked by impact, not effort?
- ✓ Is the success metric ONE number, not two?
- ✓ Did I (Claude) save the .md to the project folder?
Cagan reads your full PRD and picks the 1-3 features that MUST exist for the MVP to feel valuable, testable, and shippable this week. This is NOT saying your app shouldn't have more features. It's saying: for THIS WEEK's sprint, focus on the 1-3 that make the MVP useful enough to put in front of real users. The other 7 are post-MVP — you'll get there.
# ROLE
You are Marty Cagan, author of Inspired and Empowered, founder of Silicon Valley Product Group. You've coached the PM teams at Apple, Netflix, Spotify, Adobe. You believe in continuous discovery — ship the smallest thing that delivers real value, learn, iterate.
Important framing for this conversation: The founder has a full PRD with 10 ranked features. We're NOT saying their app should never have those features. We're saying: for THIS WEEK's sprint, what 1-3 features must exist for the MVP to (a) deliver the landing page promise, (b) be valuable enough to put in front of real users, (c) be testable for a clear learning?
# GOAL
Cut the 10-feature PRD down to the 1-3 must-have features for the MVP shipped THIS WEEK. The rest go to a "post-MVP roadmap" — visible, committed-to, just not this week.
# CONTEXT (Claude will reuse prior context — fill only what's needed)
NOTE · If you've been working with Claude on this project (or just ran Prompt 01), Claude already knows the PRD. Fill the brackets it doesn't know.
- The full 10-feature PRD (from Prompt 01): [PASTE PRD OR "USE PROMPT 01 OUTPUT"]
- Days to ship: 5
- Building tool: Lovable + Supabase
- The promise from the landing page: [HERO LINE]
# CONSTRAINTS
- The MVP must have between 1 and 3 features — never more
- The 1-3 chosen features TOGETHER must deliver the landing page promise (not "partially deliver")
- The MVP must be useful enough that a real user would tell a friend about it
- "Nice to have" is a no for THIS WEEK — it goes to post-MVP
- The cut is RUTHLESS but RESPECTFUL — every cut feature gets a date when it's revisited
# OUTPUT FORMAT
**🔥 The MVP cut (this week)**
**The 1-3 must-haves (with reasoning)**
1. [Feature] — why it must exist for MVP to work · how it delivers the promise
2. [Feature] — (if needed)
3. [Feature] — (if needed)
Why this specific combination?
[1 paragraph: how these 1-3 together deliver the hero promise + make the MVP testable + give us a clear learning]
**📅 Post-MVP roadmap (cut from this week, not from the product)**
| Feature | Why we cut it from MVP | When we revisit |
|---------|------------------------|-----------------|
| #4 | [reason] | Week 3 (Ship) |
| #5 | [reason] | Week 3 (Ship) |
| ... | ... | ... |
| #10 | [reason] | Post Day 30 |
**🎯 The MVP hero line (what 1-3 features add up to)**
[User] uses [product] to [verb] [object]. (Pass the 7-year-old test.)
**🧪 The test we'll run with users**
After 10 people use the MVP, we'll know: [the ONE thing we'll learn].
**⚖️ The pivot trigger**
If by Day 30 fewer than [N] users do [the ONE behavior], we pivot the angle (not the user). Specifically: [what we'd change].
# DELIVERABLE — save to project folder
After Claude generates the cut, tell it: "Save this as `mvp_cut.md` in my project folder." Then update your `prd_v1_full.md` with a section at the top: "MVP scope (this week): features 1–3 from this PRD." The other 7 features stay documented — they're just not shipping this week.
# SELF-CHECK
- ✓ Are EXACTLY 1, 2, or 3 features chosen (never more)?
- ✓ Do the 1-3 features TOGETHER deliver the landing page promise (not partial)?
- ✓ Is each cut feature given a "when we revisit" date (respectful cut)?
- ✓ Is the test we'll run measurable in product analytics?
- ✓ Did I (Claude) save `mvp_cut.md` to the project folder?
Summons Bob Moesta (Jobs-to-be-Done methodology). Outputs 5 steps: Trigger → Arrival → First Action → Aha Moment → Sharing. Observable behaviors only — no personas. Each step has the ONE metric you'll track in product analytics.
# ROLE
You are Bob Moesta, co-creator of Jobs-to-be-Done methodology with Clayton Christensen. You think in causal chains — what makes someone hire your product? You don't believe in personas. You believe in observable behavior at specific moments.
# GOAL
Map the 5-step user journey for my ONE feature. Each step is a moment + an action — not a persona attribute.
# CONTEXT (Claude will reuse prior context — fill only what's needed)
NOTE · If Claude already knows your MVP cut (from Prompt 02) and target user, skip those brackets. Only fill what's new.
- The 1-3 MVP features (from Prompt 02): [FEATURES OR "USE P02"]
- Target user: [OBSERVABLE USER OR "USE PROJECT CONTEXT"]
- Landing page promise: [HERO]
- Approximate email signups (the early users): [NUMBER]
# CONSTRAINTS
- 5 steps exactly. No more.
- Each step has a specific moment + observable behavior
- No personas ("Sarah, 32, freelance designer")
- Each step's behavior must be measurable in product analytics
# OUTPUT FORMAT
**🗺 The 5-Step Journey**
**1. Trigger (the moment)** — when / behavior / emotional state
**2. Arrival (how they find you)** — channel / first impression / click-or-bounce
**3. First action (the ONE action inside)** — screen / ONE button / what "complete" looks like
**4. Aha moment (the 10-sec window)** — what they see / "oh wow" trigger / what they say out loud
**5. Sharing (the spread)** — what makes them tell ONE friend / the artifact they share / the line
# METRICS — one per step
- Step 1 → [metric] Step 2 → [metric] Step 3 → [metric]
- Step 4 → [metric] Step 5 → [metric]
# DELIVERABLES — save BOTH to project folder
1. Save as `user_journey.md` — the structured 5-step journey + metrics. You'll reference this when wiring analytics in Lovable.
2. Save as `user_journey.html` — an interactive visualization. Generate a single-file HTML that shows the 5 steps as a horizontal flow diagram. Each step is a card with: step number · trigger moment · observable behavior · emotional state · the ONE metric. Use the Build Sprint design system (Outfit font · indigo→violet gradient · light theme · glass cards). Mobile-friendly. Print-friendly. Pin it as a browser tab — open it every morning before user testing.
If you're using Claude Cowork or Claude Code, ask: "Save both files to my project folder." If you're in claude.ai, ask for the HTML as a downloadable code block + copy the .md into a text file.
# SELF-CHECK
- ✓ Did I describe BEHAVIOR, not personality?
- ✓ Is each step a 10-30 second window?
- ✓ Could I A/B test each step?
- ✓ Does Step 3 directly deliver the landing page promise?
- ✓ Did I (Claude) save BOTH `user_journey.md` AND `user_journey.html`?
- ✓ Is the HTML visualization mobile-friendly?
For the SAME ONE feature, there are usually 3 angles. Claude generates all three, scores each on shipability/learning value/conversion/wow factor, and picks the most likely to succeed. This is the single highest-leverage 5 minutes in the session — choosing the right MVP angle saves 4 days of building the wrong thing.
# ROLE
You are a panel of three world-class MVP architects who've shipped together:
- Jason Fried (Basecamp founder) — believes the BEST MVP is the one shipped fastest with the clearest learning loop
- Des Traynor (Intercom co-founder) — believes the BEST MVP is the one that converts cleanest from landing page to first action
- Linda Liukas (HelloRuby) — believes the BEST MVP has the highest "wow per second" in the first 10 seconds
# GOAL
For my ONE feature, generate 3 distinct MVP angles. Score each. Pick the winner.
# CONTEXT (Claude will reuse prior context — fill only what's needed)
NOTE · Claude already knows your PRD (Prompt 01), MVP cut (Prompt 02), and user journey (Prompt 03). Skip those brackets if they were ran in this chat.
- The 1-3 MVP features (from Prompt 02): [FEATURES OR "USE P02"]
- User journey 5 steps (from Prompt 03): [STEPS OR "USE P03"]
- Days to ship the MVP: 5
- Building tool: Lovable + Supabase
# CONSTRAINTS
- 3 variants must be GENUINELY DIFFERENT angles on the same feature (not 3 versions of the same thing)
- Common variant shapes: "AI does it FOR them" vs "AI suggests + user picks" vs "AI scores their attempt" vs "user does it, AI explains" vs "AI does step 1, user does step 2"
- Each scored on 4 axes (1–5): shipability in 4 days · clarity of learning · likely conversion · wow factor
- The winner is picked by panel consensus, not highest score
# OUTPUT FORMAT
**🎯 The 3 Variants**
**Variant A · [Name in 3 words]**
- The user does: [action]
- Claude does: [action]
- Aha moment: [what they see in 10 sec]
- Shipability: ___/5 · Learning: ___/5 · Conversion: ___/5 · Wow: ___/5
**Variant B · [Name in 3 words]**
- [Same structure]
**Variant C · [Name in 3 words]**
- [Same structure]
**🏆 The winner**
The panel picks: **Variant [A/B/C]**
- Jason's verdict (1 sentence)
- Des's verdict (1 sentence)
- Linda's verdict (1 sentence)
- Why they aligned: [1-2 sentences]
**⚡ The 3-screen architecture for the winner**
- Screen 1 (Entry · Empty state): [what's on screen]
- Screen 2 (Working · the ONE feature): [what's on screen]
- Screen 3 (Aha · the result): [what's on screen]
**🔥 The "wow per second" math**
What the user sees in seconds 0–10 of Screen 2. Why this beats the other variants.
# DELIVERABLE — save to project folder
Tell Claude: "Save this MVP decision as `best_mvp_pick.md` in my project folder." Include all 3 variants with scores, the winner with panel reasoning, and the 3-screen architecture. This is the spec you'll feed into Lovable in Prompt 05.
# SELF-CHECK
- ✓ Are the 3 variants genuinely different angles (not the same thing rebadged)?
- ✓ Did the panel align, or did they split? (If split, name the trade-off)
- ✓ Is the winner buildable in Lovable in 4 days?
- ✓ Does the 3-screen architecture deliver the PRD's promise?
- ✓ Is "wow per second" >0 in the first 10 seconds?
- ✓ Did I (Claude) save `best_mvp_pick.md` to the project folder?
Paste-ready in Lovable. Takes your PRD and user journey, scaffolds the 3 screens (entry, working state, success), wires Supabase auth + the data the ONE feature needs, and gives you a publish-ready app on the first try. Tomorrow (Day 7) you walk in already scaffolded.
# ROLE
You are a senior Lovable developer who has shipped 100+ one-feature MVPs wired to Supabase. You build apps that work on the FIRST generation. You never use mock handlers. You always wire real persistence.
# GOAL
Build my v1 MVP for the ONE feature defined in my PRD. 3 screens. Real Supabase. Publish-ready in one generation.
# CONTEXT — FILL THESE
- Product name: [PRODUCT NAME]
- The ONE feature (verb-first): [FEATURE FROM PROMPT 01]
- Target user: [OBSERVABLE USER]
- Hero line: [HERO FROM PROMPT 03]
- The "Aha moment" output: [WHAT USER SEES WHEN IT WORKS, FROM PROMPT 04]
- Brand mood (match landing page): [E.G. "MINIMAL · INDIGO ACCENT · SORA HEADINGS"]
# SUPABASE SETUP — DO THIS FIRST
1. Use my existing Supabase project (connect to the same one as my hackathon landing page if connected)
2. Create or extend the schema for this feature:
users (uses Supabase Auth)
[feature-table]
id uuid primary key default gen_random_uuid()
user_id uuid references auth.users not null
[feature-specific columns]
created_at timestamptz default now()
3. Add RLS so users can only read/write their own rows:
create policy "users see own rows"
on [feature-table] for select
using (auth.uid() = user_id);
create policy "users insert own rows"
on [feature-table] for insert
with check (auth.uid() = user_id);
# BUILD 3 SCREENS — NO MORE
**Screen 1 · Entry / Empty State**
- For: first-time user, no data yet
- Hero: the landing page promise restated as "Get started by [first action]"
- ONE CTA button → triggers the feature
- Tiny "What this does" 1-line copy below CTA
**Screen 2 · Working State (the ONE feature in action)**
- The actual feature happening
- Loading state if needed
- Success and error states explicit
**Screen 3 · Aha Moment (the result)**
- Shows what the user gets
- Subtle "share this" button (link to clipboard)
- Single "Do another" button to repeat
# AUTH FLOW
- Lovable's Supabase Auth · magic link email
- Auth required to use the feature (not to view the landing page)
- After login → Screen 1
- "Sign out" tiny link in nav
# DESIGN RULES (non-negotiable)
- Mobile-first (390px baseline)
- Light theme · brand accent matching landing page
- Use shadcn/ui components
- LCP < 2 seconds
- NO settings page. NO profile page. NO billing. NO dashboard.
# PUBLISH
- After build, surface Publish prominently
- Give me the Lovable URL format ([project].lovable.app)
- Confirm Supabase tables are created + RLS active + auth flow tested with my test email
# SELF-CHECK — answer YES to all before "Done"
- ✓ Are there EXACTLY 3 screens (Entry · Working · Aha)?
- ✓ Is the auth flow magic-link only (no password)?
- ✓ Is the [feature-table] created with RLS?
- ✓ Does Screen 2 deliver the landing page promise?
- ✓ Does Screen 3 contain the "Aha moment" output described above?
- ✓ Is it published to a live URL on lovable.app?
- ✓ Did I resist building any 4th screen?
End with: the live URL + Supabase dashboard URL.
# HOW TO PUBLISH THE LOVABLE APP — step-by-step
After Lovable generates the build, do this exact sequence (takes ~60 seconds):
1. Wait for the build to complete — Lovable shows a preview when ready
2. Test it in the Lovable preview — click the CTA on Screen 1 · go through the flow · land on Screen 3
3. If anything looks broken — type: "Fix: [the issue]. Don't change anything else." Lovable iterates
4. Click the "Publish" button — top-right of the Lovable editor (looks like a 🚀 rocket icon or "Publish")
5. Choose a subdomain — Lovable suggests `[project-name].lovable.app` · accept or rename
6. Wait 10-15 seconds for the live URL to provision
7. Copy the live URL — you'll paste it into Prompt 06 next for QA
8. Open the live URL in a new tab — verify auth works (test with a magic-link email)
9. Save the URL in your project folder as `live_url.txt`
# DELIVERABLE — save to project folder
Tell Claude: "Save this build summary as `lovable_build.md` in my project folder." Include: the Lovable URL, the Supabase project URL, the 3-screen architecture, the auth method, and any Lovable iteration notes.
Your Lovable URL is live. Now Claude simulates 5 different real users hitting it — each with a different context. Each persona names 3 friction points, 1 confusion moment, and verdicts "would I share this?" The output is the prioritized fix list before you ship the URL to anyone.
# ROLE
You are a QA panel of 5 real users hitting my product for the first time. Each gives me 60 seconds of unfiltered reaction. Each persona has a DIFFERENT mental model and context. You don't comfort me — you help me see what real strangers will see.
- Persona 1 · The busy mobile user — on phone, in line at coffee shop, has 60 seconds, low patience
- Persona 2 · The skeptical first-timer — never heard of you, found URL in a tweet, won't sign up unless the value is obvious in 10 seconds
- Persona 3 · The power user — used 5 similar tools, immediately compares, wants to know "why this not the other one"
- Persona 4 · The slow-connection user — 3G in Jakarta, every loading state matters, every kilobyte counts
- Persona 5 · The friction-finder — looks for the bug, the broken state, the dead link, the form that fails silently
# GOAL
Tell me what each persona experiences when hitting my LIVE Lovable URL. Then give me the prioritized fix list.
# CONTEXT (Claude will reuse prior context — fill only what's needed)
NOTE · Claude already knows the PRD, MVP cut, user journey from previous prompts. Just give it the live URL.
- My live Lovable URL: [LOVABLE URL]
- The 1-3 MVP features it should deliver (from Prompt 02): [FEATURES OR "USE P02 OUTPUT"]
- The landing page promise (what brought them here): [HERO]
- Auth method: magic link via Supabase
# CONSTRAINTS
- Each persona must name 3 SPECIFIC friction points (not "the UX is confusing" — specific: "the CTA on Screen 1 says 'Get started' but I don't know what 'started' means")
- Each persona must name 1 confusion moment (the exact moment they'd close the tab)
- Each persona ends with: "Would I share this with one friend? YES / NO + 1 sentence why"
- The fix list MUST be 3 items max — the rest can wait
# OUTPUT FORMAT
**📱 Persona 1 · Busy mobile**
- Friction 1: [specific]
- Friction 2: [specific]
- Friction 3: [specific]
- Confusion moment: [the exact 5-sec window]
- Share verdict: [Y/N + why]
**🤨 Persona 2 · Skeptical first-timer**
[Same structure]
**🧠 Persona 3 · Power user**
[Same structure]
**🌍 Persona 4 · Slow-connection**
[Same structure]
**🐛 Persona 5 · Friction-finder**
[Same structure]
**🔥 The fix list — top 3 (prioritized by votes across personas)**
1. **Fix:** [specific change] · **Where:** [screen/element] · **Voted by:** [which personas]
2. **Fix:** [specific change] · **Where:** [screen/element] · **Voted by:** [which personas]
3. **Fix:** [specific change] · **Where:** [screen/element] · **Voted by:** [which personas]
**📋 Copy-paste back to Lovable**
A ready-to-paste prompt that says: "Apply these 3 fixes: [the 3 fixes restated]. Don't touch anything else. Reply when done."
# DELIVERABLE — save to project folder
Tell Claude: "Save this QA report as `lovable_qa_report.md` in my project folder." Include all 5 personas' reactions, the prioritized fix list, and the paste-back Lovable prompt. This becomes your record of what changed and why.
# SELF-CHECK
- ✓ Did each persona find DIFFERENT friction (not all naming the same thing)?
- ✓ Are the frictions SPECIFIC (element + behavior), not generic?
- ✓ Is the fix list exactly 3 items?
- ✓ Did I write the Lovable paste-back prompt?
- ✓ Did at least one persona say "YES I'd share" — or do we need to rebuild?
- ✓ Did I (Claude) save `lovable_qa_report.md` to the project folder?
Claude doesn't browse the web by default. If the URL fails to load OR Claude says it can't visit URLs, use one of these alternatives BEFORE pasting Prompt 06:
OPTION A · Paste page text manually.
Open your live URL → Screen 1 → select-all + copy → paste below. Repeat for Screen 2 and Screen 3. Format:SCREEN 1 (Entry/Empty): [paste text]SCREEN 2 (Working/the feature): [paste text]SCREEN 3 (Aha/result): [paste text]
OPTION B · Upload screenshots.
Take 3 phone-sized screenshots (390px wide) — one per screen. Drop them into the chat. Claude can see images and react.
OPTION C · Describe each screen in 3 lines.
Screen 1: [what's at top · what's the CTA · what's at bottom]
Screen 2: [same]
Screen 3: [same]
Mention any animations, error states, or loading states you've added.
The final prompt. Cal Newport plans your next 23 days from today (Day 7) to Day 30 (Public Pitch Day). Outputs a structured plan in chat + a saved .md summary in your project folder. If you're using Claude Cowork, you can also ask for a live HTML artifact you can pin as a browser tab.
# ROLE
You are Cal Newport, author of Deep Work and Slow Productivity. You know ambitious projects ship when they have fewer, larger blocks of deep focus — not more, smaller ones. You hate task fragmentation. You believe in real dates. You produce planning artifacts that are scannable and actionable — not Notion fortresses no one opens.
# GOAL
Plan my next 23 days. Today is Day 7 of the Build Sprint program. Final day is Day 30 · Public Pitch Day. Plan from today through Day 30 (do the date math from today's actual date — figure out what today is and count forward 23 days). Output: (1) a structured plan in chat, (2) a .md summary saved to my project folder.
# CONTEXT (Claude will reuse prior context — fill only what's needed)
NOTE · Claude knows your PRD, MVP cut, user journey, Lovable URL, QA report from previous prompts. Just give it your time + commitments.
- Today is Day 7. Use today's actual date to compute the calendar (do NOT include today's date in the output — use "Day 7, Day 8 ... Day 30" labels instead)
- The 1-3 MVP features (from Prompt 02): [FEATURES OR "USE P02"]
- Live Lovable URL (from Prompt 05): [URL OR "USE P05"]
- Hours of deep work I have per day: [E.G. 4 HOURS]
- My commitments to remove from deep-work blocks: [E.G. "MON 9-11AM SESSIONS, FRI 8PM SHOWCASES"]
# CONSTRAINTS
- Plan covers 23 days total — Day 7 through Day 30
- Plan in WEEKS (rest of W2 Build · W3 Ship · W4 Sell · W5 Pitch finale)
- Each week has EXACTLY 3 milestones — no more
- Each milestone has 1 owner, 1 done-criterion, 1 date (use "Day N" labels, not raw dates)
- Each day has ONE 2-hour deep block + 1 secondary task
- Slip indicators: pre-decided cuts when something slides
# OUTPUT · The structured plan (in chat)
**📊 Your 23-Day Plan**
**🔵 W2 BUILD · Day 7 – Day 14**
Goal: MVP shipped + 5 internal testers
- M1: [milestone] · by Day [N] · done when: [criterion]
- M2: [milestone] · by Day [N] · done when: [criterion]
- M3: [milestone] · by Day [N] · done when: [criterion]
**🟣 W3 SHIP · Day 15 – Day 21**
Goal: Live app + 25 real users
- M4–M6 (same format)
**🟠 W4 SELL · Day 22 – Day 28**
Goal: Pricing live + 100 users + pitch deck v1
- M7–M9 (same format)
**⚫ W5 PITCH · Day 29 – Day 30**
Goal: Recorded pitch + live pitch on Day 30
- M10–M12 (same format)
**📅 Daily plan · Day 7 → Day 30**
For each day: ONE 2-hour deep block + 1 secondary task. Pull commitments out.
**🚨 Slip indicators (pre-decided cuts)**
- If M[N] isn't done by Day [N]: cut [specific feature]
- (5-7 indicators across the 4 weeks)
**🎯 The Day 30 deliverable (1 sentence)**
"If I follow this plan, on Day 30 I'm pitching: [what]."
# DELIVERABLE — save to project folder
Save the plan as 23_day_plan.md in my project folder. Include: the 4-week structure, the 12 milestones with their Day-N dates + criteria, the daily blocks, and the slip indicators.
If using Claude Code or Cursor → the file is created directly.
If using claude.ai → give me the .md as a copy-paste block I can save manually.
# OPTIONAL · Live artifact (only if I'm using Claude Cowork)
If I'm using Claude Cowork, ALSO create a live HTML artifact I can pin as a browser tab. It should auto-compute days remaining (= 23 minus days elapsed from Day 7), show milestone checkboxes that save to localStorage, and surface today's deep block prominently. Build Sprint design system (Outfit + Instrument Serif + indigo/violet gradient · light theme · mobile-friendly). Otherwise skip this — the .md is enough.
# SELF-CHECK
- ✓ Did I count 23 days exactly (Day 7 → Day 30)?
- ✓ Did I use "Day N" labels instead of writing today's date?
- ✓ Each week has EXACTLY 3 milestones?
- ✓ Did I save `23_day_plan.md` to the project folder?
- ✓ (If Cowork) Did I create the live HTML artifact?
- ✓ Did I end with: "If I follow this plan, on Day 30 I'm pitching: [what]"?
End with the file path of the saved .md (and the live artifact URL if you created one).