Vibe Coding Prompts: Ten With the Distribution Step Built In, and the Runs Behind Them

1. Who and what: the audience and the job
2. Features in order: three to five
3. Screens and states: empty, loading, error
4. Channel surface: pages, invite, card, capture
5. Safeguard, then ask: data rules; questions first

The section order of the prompts in this library, with the channel surface added between states and safeguards.

Counted from the library on 26 September 2026; one prompt can serve more than one channel. Data from src/lib/channelIndex.ts.

Build a one-page site for [product] for [who it is for]. One offer in plain words, one email form above the fold, an inline success state, no redirect.
Distribution: the page must render fully without JavaScript, carry a unique title, meta description and a self-canonical, and include a sitemap and robots file. Add a second public page that answers "[the question these people search]" in 300 words with a definition first.
Safeguard: the leads table is insert-only from the client; never a public read policy.
Before building, ask me anything you need about the audience and the offer, then save the answers to the project knowledge.

Build a workspace app where a user signs up, gets a workspace, and invites teammates by link into the same workspace with a role (owner, admin, member).
Distribution: the invite is the loop. Show who invited whom, confirm to the inviter when an invite is accepted, and offer the link again after the invitee's first successful action.
Safeguard: roles are enforced in the database with row-level security, not only hidden in the UI; never accept a role or workspace id from the client.
Build order: auth and the role check first, then the invite, then screens. Ask me your questions first, then save the decisions to the project knowledge.

Build a directory of [entities] for [audience]: one server-rendered page per entity with its own URL, title, description, an H1 naming it, a definition in the first 100 words, and a Related section linking eight siblings.
Distribution: generate the sitemap from the data with the actual updated dates; add JSON-LD per page; no page ships without unique text.
Safeguard: never generate body text from the slug alone.
Ask me which entities have search demand before building, then save the answers.

Build [a small tool that produces a result the user is proud of: a score, a plan, a card].
Distribution: after the result, one share action that posts a server-generated image card with the result and a link back; the shared link opens the same result read-only with a call to make your own.
Safeguard: the share URL is unguessable and the card never contains personal data.
Ask me who shares this and where, then save the answers.

Build a newsletter site: a subscribe form with double opt-in, an issue archive where each issue is a public page, and a send flow from server code with a log of every send.
Distribution: every issue page has its own title and description and links the two neighbouring issues; unsubscribe is one click and honoured everywhere.
Safeguard: no send to any address without the opt-in flag; the log is written before the send.
Ask me about the provider and the sending domain first, then save the answers.

Build a landing page per [offer] that a paid search ad sends traffic to: headline containing the ad group's phrase, one action, a form that stores the UTM parameters with the lead.
Distribution: one page per ad group from one data file, shared components; a server-side conversion event fires on form success with the stored click id.
Safeguard: message match is a test, not a hope: the headline must contain the phrase from the data file.
Ask me for the ad groups and offers first, then save them.

Build a feedback board where signed-in users post and vote once per item, and a public changelog page with one dated entry per release and an RSS feed.
Distribution: a shipped item links to its changelog entry; the author and voters are notified when status changes; a monthly digest page collects the month's shipped items.
Safeguard: one vote per user enforced in the database; feedback bodies escaped, never rendered as HTML.
Ask me who moderates and how releases are named, then save the answers.

Build a page that turns [a video's topic] into a saveable artifact: the checklist, template or calculator the video promises, behind an email or without one (tell me which).
Distribution: the page URL is short enough to say out loud, renders the artifact server-side, and shows a "from the video" strip with the next step.
Safeguard: no fake counts of downloads or users.
Ask me which videos send traffic and what each promises, then save the answers.

Build [an internal tool] for a team, with a read-only summary page an admin can share with a decision maker: seats in use, activity in 30 days, what the paid tier would change.
Distribution: the summary is aggregate only, revocable, and carries a "request a demo for your team" action that writes a lead.
Safeguard: no member emails on the shared page; the plan card never blocks reading data.
Ask me what a decision maker needs to see, then save the answers.

I want to build [one sentence]. Before writing code, ask me: who the first users are, which one channel they will come from (search, invite, social, email, paid, community, sales), what the first successful action is, and what must never happen with their data. Then write the build prompt in this order: context, core features in priority order, screens and states, the surface that channel needs, safeguards, and a closing line that asks for questions before building. Show me that prompt and wait.