PRD template for Claude Code, Cursor and vibe coding

Last updated

What should a PRD template for Claude Code include?

A PRD template for Claude Code should give the agent what it needs to make decisions: an overview and project type, goals, users, prioritized features, a data model, a UI direction, what is out of scope, assumptions, open questions and build notes. Save it as spec.md in your repo root and point the agent at it. The full template is below, ready to copy.

AI coding agents are fast, but they fill every gap you leave with a guess. Ask Claude Code or Cursor to build a booking app and you get a typical booking app: a login screen, a dashboard and features nobody asked for. A short PRD in the repo replaces those guesses with decisions you have already made.

This page gives you a free PRD template for vibe coding and agent-driven builds, shows where to put the file, and explains how to fill it from a real client call instead of from memory. The same file works as a Cursor PRD template, a Claude Code PRD and a spec.md example you can adapt.

The spec.md template

Copy this into a file called spec.md (or PRD.md) at the root of your repo and replace every line in angle brackets. It uses the same core sections as the spec.md TaskyTrack exports (overview, features, data model, visual design, assumptions and open questions), plus goals, out of scope and build notes, which help an AI agent most.

spec.md
# <Project name>

## Overview
<Two or three sentences: what this is, who it is for, and the problem it solves.>
**Target audience:** <who uses it>

## Project type
<Web app | Marketing website | Internal tool | Mobile-first web app>
<One line on why, for example: Content website, no user accounts.>

## Goals
- <An outcome the client wants, in their words>
- <How you will know it worked>

## Users
- **<Role 1>:** <what they need to do>
- **<Role 2>:** <what they need to do>

## Features
<Page by page for a website, feature by feature for an app.>
<Priority: must | should | could>

### 1. <Feature or page name>  `must`
<What it does, as observable behavior, for example:
Owners can book a walk by choosing a dog, a date and a time.>
- **UI:** <screens and states: empty, loading, populated, error>

### 2. <Feature or page name>  `should`
<What it does.>
- **UI:** <screens and states>

## Data model
<Only the data the client described. Delete this section for a content-only website.>

#### `<table_name>`
<What one row represents.>

| Field | Type | Constraints |
|---|---|---|
| `id` | `uuid` | primary key |
| `<field>` | `<type>` | <not null, unique, references other_table(id)> |

## UI direction
- **Primary color:** `<#hex>`
- **Secondary color:** `<#hex>`
- **Mode:** <light | dark | both>
- **Fonts:** <font names>
- **Feel:** <three words the client used, for example friendly, simple, green>

## Out of scope
- <Things the client mentioned that are not in this build>
- <Things you are deliberately not building, for example user accounts>

## Assumptions
- <Anything you decided that the client did not say>

## Open questions (confirm before building)
- <A question the client needs to answer>

## Build notes for the AI agent
- Stack: <for example Next.js, React and Tailwind>
- Build only what is listed under Features. Do not add login, payments or
  admin screens unless they are listed.
- Before starting, ask about any open question that blocks a feature.
- Build one feature at a time and stop for review after each one.
- When a requirement changes, update this file first, then the code.

Step by step

  1. 1

    Copy the template into spec.md

    Create spec.md in the root of your repository and paste the template in. Keeping it in the repo means it is versioned with the code and every agent session can read it.

  2. 2

    Fill it from the client call, not memory

    Work from the transcript of the discovery call. Write features as behavior you can observe, and keep the client's own words for goals and the UI feel. The meeting transcript to PRD guide shows how to pull each section out of a call.

  3. 3

    Be honest in out of scope and assumptions

    These two sections stop the agent from adding work. If there are no user accounts, write that under Out of scope. If you decided something the client did not say, list it under Assumptions.

  4. 4

    Point your AI tool at the file

    In Claude Code, add a line to CLAUDE.md that says the product requirements are in spec.md, or start your prompt with: Read spec.md and build feature 1. In Cursor, reference the file with @spec.md in chat, or add a project rule that tells the agent to follow spec.md.

  5. 5

    Build one feature at a time

    Ask the agent to build a single feature from the list, then review it before moving on. Small steps against a fixed spec are easier to check than one large generation.

  6. 6

    Change the spec first, then the code

    When the client changes their mind, update spec.md before you prompt the agent. The spec stays the source of truth, and the next session starts from the current version.

Why AI coding tools need a PRD

An agent only knows what is in its context. A one-line prompt gives it a goal but no boundaries, so it falls back on common patterns: email login, a settings page, a generic dashboard. Each of those is a wrong guess you then have to undo.

A vibe coding PRD gives the agent the context a developer would ask for on day one: who the users are, which features matter most, what data to store and what the product should look like. It also tells the agent what not to build, which is often the bigger time saver. This is the core idea behind spec-driven development with AI.

Where to put the file

  • Save it as spec.md or PRD.md in the repository root, next to README.md.
  • Commit it, so changes to the requirements are tracked like changes to the code.
  • Claude Code: mention spec.md in CLAUDE.md, the file Claude Code reads at the start of each session, or name it in your first prompt.
  • Cursor: reference @spec.md in chat, or add a short project rule asking the agent to follow it.
  • Any other tool: paste the file's contents at the start of the conversation.

Filling the template from a client call

The template is only as good as what goes into it. Written from memory a day after the call, it carries your interpretation. Written from the transcript, it carries what the client actually asked for.

TaskyTrack does this step for you. Paste the transcript or let our note-taker join the call, and the AI PRD generator drafts the overview, features, data schema, UI direction, assumptions and open questions. You review and approve it, then download it as spec.md in the same structure, ready for the agent.

Reading specs over MCP (Pro and Max)

On the Pro and Max plans, AI coding tools can read your approved specs directly through the TaskyTrack MCP connector instead of a copied file. Add the connector address in Claude, Claude Code, Cursor, VS Code or Windsurf and sign in once. The tool can then list your approved specs and fetch one with a ready-made build prompt.

Only specs you have approved are visible, and the connector is read-only: the tool cannot change anything in your account. More on using your spec with AI coding tools.

Key takeaways

  • Give the agent decisions, not just a goal: features, data, UI direction and what is out of scope.
  • Keep the PRD as spec.md in the repo root and reference it in every session.
  • Fill it from the client call, and update it before you change the code.

Frequently asked

How do I write a PRD for Claude Code?

Use the template on this page: overview, project type, goals, users, prioritized features, data model, UI direction, out of scope, assumptions, open questions and build notes. Save it as spec.md in the repo and tell Claude Code to read it, either in CLAUDE.md or in your first prompt.

Is there a Cursor PRD template?

The same template works in Cursor. Save it as spec.md, reference it with @spec.md in chat, or add a project rule that tells the agent to follow it.

Should I call the file spec.md, PRD.md or CLAUDE.md?

Use spec.md or PRD.md for the requirements. CLAUDE.md is for instructions to Claude Code about how to work in the repo, so it should point to the spec rather than contain it.

What makes a good vibe coding PRD?

Clear priorities, features written as observable behavior, an explicit out of scope list, and build notes that tell the agent to build one feature at a time and ask before guessing. Short and specific beats long and vague.

Do I need a data model for a simple website?

No. If the client did not describe data the site needs to store, delete the Data model section. Leaving it in invites the agent to create a database you do not need.

Can TaskyTrack fill this template for me?

Yes. It drafts the same structure from a client call transcript and exports it as spec.md. See the AI PRD generator.

Related guides

Get practical guides by email

Occasional, useful tips on turning client calls into build-ready specs. No spam. Unsubscribe anytime.

Turn your next call into a spec

Free to start. No card required.

Get started free