Sample prompts

Good prompts are how non-technical founders direct AI tools. You do not need to memorize syntax — copy a prompt, paste it into chat, and refine the answer until it matches what you want.

This page walks through the story → spec → plans → build sequence LaunchWithCursor expects, with copy-ready prompts you can adapt. We use one hypothetical product throughout: a blog with free and paid articles.

Where these prompts fit

Why two documents before code? The User Story describes who uses the product and what they need in plain language. MVP-SPEC (many teams call this a PRD) turns that into what we will actually build for v1 — scope, tech choices, must-haves, and explicit “not in MVP” items. AI builds from the spec and phase plans, not from a vague idea in one message.

LaunchWithCursor does not generate these files for you on the website. Draft them externally, commit them in Git, and the platform reflects your repo after each extension scan or GitHub push.

If you have not connected your editor yet, start with Install & sign in. When you are ready to ship, continue to Deploy & hosting.

Existing project → LaunchWithCursor

Use this when the codebase already exists (bought, inherited, or built before you installed the extension) and you want to know if it can deploy on LaunchWithCursor.

Paste in Agent mode in your AI coding assistant:

I have an existing project and want to host it on LaunchWithCursor.

Before changing any code or structure:

1. Read .launchwithcursor/pack/LAUNCHWITHCURSOR/ if it exists (install the LaunchWithCursor extension and open this folder first if the pack is missing).
2. Assess whether this codebase can be moved comfortably to LaunchWithCursor deploy — consider stack (many work: Next.js, NestJS, Vite, Express, Laravel, Django/Flask/FastAPI, static HTML, Bun, Java, Go; optional BYO Dockerfile), monorepo vs single app, database (Postgres **or** MySQL), background jobs, file uploads, and email. Next.js + NestJS + TypeScript is the **best-documented greenfield path**, not the only allowed one.
3. Tell me clearly: **yes, good fit**, **possible with these changes**, or **not a good fit yet** — and why in plain language. Do not start refactoring until I approve your decision.

If it is a good fit or fixable, outline a high-level migration plan (folders/services, what to provision on Deploy — including Postgres vs MySQL if needed, and Env vars). Reference the LaunchWithCursor pack for deploy rules — do not invent platform internals. See DEPLOY/stacks.md for non-JS recipes.

If it is not a good fit, list the minimum changes or alternatives I would need before retrying.

Your assistant should decide first, then plan — not rewrite the repo until you agree. For greenfield products, skip this and start with Step 1 below.

Step 1 — User Story prompt

Use this in ChatGPT, Claude, or Gemini when you are starting from an idea and want a structured story document before technical planning.

Hypothetical product: A blog where some articles are public and others require a paid annual subscription.

I would like to create a blog website where I can publish my articles. Some articles will be available to the general public; others will only be available to people who have subscribed by paying an annual subscription fee.

Help me write a User Story document for this website. The document should include:

1. Product Overview
2. Product Goals
3. User Types
4. Business Rules
5. User Stories — each with Acceptance Criteria
6. User Journeys for the different types of users

Use markdown. Keep v1 scope realistic for a solo founder building with AI.

What “good” looks like

Your assistant should produce sections you can challenge and edit, not a novel. For example:

Sample user story

US-002 — Browse articles

As a visitor, I want to browse published articles, so that I can discover content that interests me.

Acceptance criteria

• Published articles appear in a clear list or grid.
• Each article shows title, featured image, category, tags, author, and publication date.
• The visitor can open an article to read it.

Sample business rule

BR-001 — Free content

Free articles must be fully readable without an account.

Sample user journey (free reader)

Visitor → lands on blog home → browses or searches → opens a free article → reads it completely
Or → opens a premium article → reads a preview (e.g. first 30%) → sees subscription prompt → decides whether to subscribe

Save the result as USER-STORY.md in your repo root and commit it. After your next scan, it appears under Spec & Plans → User Story on your project dashboard.

Step 2 — MVP-SPEC prompt (from your User Story)

Once the User Story feels right, use the same chat tool (ChatGPT, Claude, or Gemini) to turn it into a product requirements document.

Help write the product requirements document (MVP-SPEC) for this blog product, based on the User Story document we already wrote.

Output markdown suitable for AI-assisted development. Include at minimum:

- Product summary and target users
- Must-have features for v1
- Explicit NOT in MVP list
- User flows for free readers, subscribers, and admin/author
- Payments approach (annual subscription) and content gating rules
- Auth approach (who needs an account)
- Mobile strategy (PWA vs desktop-only) with a recommendation
- Success criteria for “done enough to launch”

Reference the business rules and acceptance criteria from the User Story. Do not expand scope beyond v1.

Save the result as MVP-SPEC.md in your repo root and commit it. The platform syncs it to Spec & Plans automatically.

Why this matters: Vague specs produce vague code. A clear MVP-SPEC is the input for build phase plans and for every implement prompt that follows.

Step 2b — Create build phases (Agent mode)

After MVP-SPEC.md exists in your repo, switch to Agent mode in your AI coding assistant (Cursor, VS Code, etc.) — not Plan or Ask mode — so it can create files. Paste the prompt below to create docs/plans/: one file per phase plus phase-verify.md last.

This prompt tells your assistant to read the LaunchWithCursor pack in your repo so phase plans match how you will deploy on the platform.

Each phase file should include Tests & verification: what the assistant will run (unit, integration, or e2e) before claiming that phase done. You do not manually QA after every phase — the plan tells the AI how to self-check.

Each file should also end with ## Cursor prompt and a fenced copy-paste block tailored to that phase — the exact text you paste into a new chat when you are ready to implement.

Read MVP-SPEC.md, .launchwithcursor/pack/LAUNCHWITHCURSOR/METHOD/03-phases-overview.md, and SKILLS/frontend/README.md (also BACKEND.md and Infrastructure.md).

Create docs/plans/ with one markdown file per build phase this MVP needs (for example phase-1.md, phase-2.md, …) AND docs/plans/phase-verify.md.

Each build phase file must include:
- Goals and deliverables
- Frontend compliance (SKILLS/frontend file + rule numbers)
- Backend compliance where applicable
- Tests & verification — what the AI assistant will run before claiming done (e.g. unit/integration/e2e commands, key user flows to exercise in the browser). The founder does not manually QA between phases; the plan must say how you self-check.
- Done-when checklist
- As the LAST section: a heading ## Cursor prompt followed by one fenced copy-paste block the founder can paste into their AI editor unchanged to implement ONLY that phase (reference docs/plans/phase-N.md; cite skills from the plan; run Tests & verification; self-check done-when; do not start the next phase)

Use as many or as few numbered phases as the MVP requires — do not pad to a fixed count.
phase-verify.md must follow SKILLS/frontend/verify-checklist.md (fix only) and end with ## Cursor prompt the same way.
No code — markdown plans only.

Important: the founder must be in Agent mode (not Plan or Ask mode) so you can create these files.

Commit the new docs/plans/ files, then run an extension scan or push to GitHub so Spec & Plans → Build Phases on your project shows them.

Step 2c — Did you include tests in each phase?

This is worth asking right after plans are drafted:

Did you include tests in the plan phases when necessary?

Many assistants write deliverables and done-when lists but skip how they will verify the work — especially automated or end-to-end tests for what that phase ships. If the answer is vague, paste:

Review every file in docs/plans/ except phase-verify.md.

For each build phase, check whether the plan includes a clear Tests & verification section that states:
- What automated tests to add or run for that phase's deliverables (unit, integration, or e2e — only what this phase ships)
- Which commands to run (for example npm test, npm run test:e2e) and what should pass before claiming done
- Any short browser smoke steps you will run yourself to confirm the feature works

The founder does not manually QA after every phase — but each phase plan must tell you how you verify your own work before moving on.

If any phase is missing this, update that phase file. Keep changes minimal; do not rewrite unrelated sections or expand MVP scope.

Why this matters: Per-phase self-checks catch broken flows early. Phase Verify is still the last gate before launch — it is not the first time your app should be exercised.

Step 2d — Does each plan file end with a Cursor prompt?

Good phase plans include a ready-to-copy implement block at the bottom. Open any docs/plans/phase-N.md — the last section should look like:

## Cursor prompt

Implement phase 4 from docs/plans/phase-4.md only. Read MVP-SPEC for mobile strategy. PWA only if required — SKILLS/PWA.md (not required for this project). Apply SKILLS/frontend/surfaces.md Rule 31. Self-check done-when. Do not start Phase 5.

If that section is missing, paste this in Agent mode:

Review every file in docs/plans/ including phase-verify.md.

Each plan file must end with ## Cursor prompt and a fenced copy-paste implement block for that file only.

Add or fix missing sections minimally. Do not expand MVP scope.

Step 3 — Implement one build phase

After docs/plans/ exists in your repo and shows up under Spec & Plans, implement one phase at a time in your editor. Do not ask the AI to “build the whole app” in one message.

Open docs/plans/phase-1.md (or whichever phase you are on), scroll to ## Cursor prompt, and paste that block into a new chat. Your project’s Build Phases tab also offers copy buttons when plans are synced.

Example shape (your phase 1 file will be tailored to your MVP):

Implement phase 1 from docs/plans/phase-1.md only.

Follow AGENTS.md and the frontend skills cited in that plan (design-system.md, visual-foundation.md, forms.md as needed).
Apply SKILLS/BACKEND.md and SKILLS/Infrastructure.md Phase 1 checklist where relevant.

Run the Tests & verification steps listed in that phase file (tests, e2e, or smoke checks).
Self-check the phase done-when before claiming done.
Do not start phase 2.

For Phase Verify (always last), copy the ## Cursor prompt from docs/plans/phase-verify.md or use the copy button on your Build Phases tab.

Quick fix prompt (when something breaks)

Something is broken. Here is what I expected: [describe].
Here is what happened: [describe].
Error message or screenshot: [paste].

Only fix this issue. Do not refactor unrelated code.

What to do next

1. Connect your editor — Install & sign in
2. Existing repo? Run the Existing project → LaunchWithCursor prompt first
3. Draft User Story and MVP-SPEC with ChatGPT, Claude, or Gemini; commit them to your repo
4. Create build phase plans with your AI coding assistant in Agent mode; commit docs/plans/
5. Implement phase by phase, then read Deploy & hosting and consider Manual testing before launch

These prompts will evolve as we learn what founders need most. Start with the blog example, swap in your product, and tighten scope until v1 feels shippable.