What is a PRD in vibe coding?

What is a PRD in vibe coding?

A PRD in vibe coding is the product requirements document you hand to an AI coding agent before it writes the app. It names one user, one problem, the first-release scope, the work you are leaving out, and the checks that show a feature is done. It is the second step of the vibe coding workflow, after Vibe Research.

People also search for this as a vibe coding PRD or as PRD vibe coding. The document is the same. The vibe-prd skill writes it to docs/PRD-[AppName]-MVP.md after you answer its questions. The web app keeps that artifact in the project.

A PRD does not choose the stack, the schema, or the deployment target. Those decisions belong in the technical design so you can change one layer without rewriting the other. The vibe planner shows that handoff as a stage on the map.

PRD template for vibe coding

This outline matches the sections the PRD skill and the public Part II prompt ask the model to fill. Copy it, replace the brackets, and delete any line you cannot answer yet. The full question flow, which changes for a vibe coder, a developer, or someone in between, is the vibe coding prompt template for the PRD.

# PRD: [Product name] MVP

## Product overview
- Name:
- One-sentence problem:
- Launch goal:

## Target users
- Who has the problem:
- What they do today:

## Problem statement
- What is broken:
- Why it matters now:

## User journey
Discovery -> first use -> success

## MVP features
### Must have
- Feature:
  - User story: As a [user], I want to [action] so that [benefit].
  - Acceptance check: A tester can observe...

### Not in this MVP
- Item, and why it waits:

## Success metrics
- Metric, and how you will count it:

## Design direction
- Words that describe the interface:

## Constraints
- Platform, budget, date, or tools:

## Definition of done
- [ ] Required behavior works
- [ ] Non-goals stayed out
- [ ] Failure behavior is defined

A filled example is more useful than a blank outline. The rest of this page annotates the public Reddit-to-AI PRD so you can see how those headings look with real product decisions.

What PRD coding means here

PRD coding means the coding agent builds from that approved document instead of from a one-line prompt. In this workflow the agent also reads the technical design and the agent instructions, then implements one approved slice at a time. The PRD is the product boundary. It is not a promise that the generated code is correct.

If you do not have a PRD yet, start with research or paste the Part II prompt. If you already have one, use the five-step vibe coding workflow to see where the PRD sits before the build.

What this example proves

The public example is called Reddit to AI. Its product idea is a Chrome extension that turns a Reddit thread into a prompt a user can review before sending to an AI chat. The project shipped before these workflow documents existed, so the repository labels the files as a reconstruction. They show the shape of a complete handoff. They are not proof of a launch date, user count, revenue result, or development speed.

That limitation is useful. You can assess the documents themselves without being asked to believe a success story. Open the example directory and compare the research, PRD, technical design, AGENTS.md, and MEMORY.md files.

Start with one user and one problem

The example does not begin with “build a Chrome extension.” It begins with a desktop Reddit reader who already uses an AI chat and loses time copying long discussions. That distinction matters. A platform is an implementation choice; the user problem explains why any implementation should exist.

The PRD narrows the main job to a visible flow: capture the open thread, filter noise, preview the prompt, and send or copy it. A coding agent can trace each planned feature back to that flow. If a proposed feature does not help the flow, it needs a strong reason to enter the MVP.

Turn features into checks

A feature name gives an agent a direction. An acceptance check tells the agent and reviewer when to stop. In the public PRD, the preview feature must show the final prompt, allow editing, report its size, and warn when it becomes too large. Those statements describe behavior a tester can observe.

Failure behavior needs the same treatment. The planned send action depends on websites whose page structure can change. The PRD therefore requires a copy fallback if automatic pasting fails. The corresponding technical design tells the builder to deliberately break a selector and confirm that the fallback appears. That link between requirement and test is more valuable than an adjective such as “reliable.”

Use non-goals to protect the MVP

The example defers history, batch processing, more browsers, more languages, and additional AI destinations. These are not bad ideas. They are work that the first release does not need. Writing them down helps when an agent notices an easy way to add “one more” feature.

A non-goal should include a reason or a condition for reconsideration. “Firefox later if the Chrome version gets traction” is clearer than “Firefox is out of scope forever.” The first form protects the current build and keeps the product decision reversible.

I also add quality refusals: no silent scrape failure, no sending content before preview, and no broken automatic paste without a manual fallback. These rules describe unacceptable behavior. They are especially useful for AI agents because they close shortcuts that can look technically complete.

Written non-goals also limit later work. When the product is already live, the production review gates start from one approved PRD slice and reject changes that fall outside it.

Hand technical decisions to the right document

The PRD says what the product must do. The technical design decides how to build it. In this example, the design selects a Manifest V3 Chrome extension with plain JavaScript and no backend. It records the accepted weakness: page selectors can break when Reddit or an AI site changes.

That choice affects the file tree, privacy model, test plan, and deployment path. Keeping it in the technical design makes the tradeoff easy to find. It also prevents the PRD from becoming a mixed document where product goals and library choices are hard to revise independently.

Before the build starts, read the PRD and technical design together. Requirements should have a matching implementation path, and technical components should trace back to a requirement. The handoff walkthrough gives you a short review sequence for the whole example set.