PRD generator for the app you already have
Describe the change you want to make. You get a product requirements document written for a product that already exists: scope, what must not change, acceptance criteria you can check in a preview, and a flag on anything that touches sign-in, payments or customer data. Add a public GitHub repository and it names the files the change will touch, checked against the real file list. Free, no signup.
What you get
A document you can send as it is, and a spec you can hand to a coding agent. Every section is written for a change to a live product.
- Scope
- Goals, non-goals and the users affected, written against the product you already have rather than a blank page
- User stories
- As a…, I want…, so that… — one per real need, not padded to a quota
- Acceptance criteria
- Given, when, then statements you can check yourself by clicking through a preview
- Edge cases
- Empty states, errors, permissions and existing data the change has to survive
- Review flags
- Each piece of work marked safe, needs review or blocked, so changes to sign-in, payments and data get a person's approval
- Real files
- From a public GitHub repo, the files the change will touch. Only paths that exist in the repo are shown
- Exports
- Markdown for your docs or tracker, and a short spec to paste into Cursor, Claude Code or Codex
PRD template
Prefer to write it yourself? This is the same structure the generator fills in, plus the parts only your team can answer: current behaviour, what must not change, and rollout.
# [Name of the change] Status: Draft · Owner: [name] · Last updated: [date] Product area: [the part of the app this touches, and the repository if there is one] [Two or three sentences: what changes, for whom, and why now.] ## Problem [What happens today, who it affects, and the evidence: a support ticket, a metric, a customer quote.] ## Current behaviour [What the product does today in the area this touches. Link the live page or add a screenshot.] ## Goals - [An outcome you will be able to see after release] ## Non-goals - [What this change deliberately does not do] ## Must not change - [Existing behaviour, URLs, data or integrations that have to keep working exactly as they do] ## Users - [Who is affected, and how many if you know] ## User stories - As [a type of user], I want [to do something], so that [they get a benefit]. ## Acceptance criteria Each one should be checkable by clicking through a preview. 1. **Given** [a starting state], **when** [an action], **then** [a visible result]. ## Edge cases - [Empty states, errors, slow connections, permissions, existing data, mobile] ## Analytics - [Event or metric] — [the question it answers] ## SEO and content - [Page titles, URLs, copy, redirects, or "none"] ## Work classification | Item | Classification | Why | | --- | --- | --- | | [Pricing page layout and copy] | Safe | [UI only, no data] | | [New field on the subscription record] | Needs review | [Changes the database schema] | Safe: UI, copy or styling with no data, auth or payment impact. Needs review: touches sign-in, payments, customer data, the database schema, permissions or an integration. Blocked: needs information or access you do not have yet. ## Files likely to change - `path/to/file` — [what changes in it] ## Implementation steps 1. [First step] ## Rollout - [Feature flag, staged release, migration order, and how to roll it back] ## Open questions - [ ] [Question] — [who can answer it]
What makes a PRD for an existing product different
It is scoped against what is already there. A PRD for a new product describes everything; a PRD for a change describes the difference between today and after. Say what the product does now in the area you are touching, and the change becomes something a person can estimate and review, rather than a redesign by accident.
It says what must not change. Live products have URLs people have bookmarked, data customers rely on, and integrations nobody has looked at in a year. Naming them as non-goals is what stops a small change to the pricing page from quietly breaking the checkout that reads from it.
Its acceptance criteria can be checked in a preview. “Given a visitor on the pricing page, when they switch to annual, then every plan shows the yearly price and the saving” is a yes or a no. “Billing should be flexible” is a meeting. Write the first kind and the review before it ships takes minutes.
Limits
Worth reading before you forward the result. The file list is checked; the judgement is not.
- It reads a public repository's file list, description and package.json — not the code inside the files. File suggestions come from names and structure, so treat them as where to look first, not a finished plan.
- Large repositories are cut to the 1,500 most relevant source paths, so a file deep in a big monorepo can be missed. The result says when that happened.
- Private repositories are not read here. Refinar reads them once you connect GitHub.
- It cannot see your analytics, your users or your roadmap. It will not invent numbers, which means targets and priorities are yours to fill in.
- A model writes it. Read it before you send it: the acceptance criteria and review flags are a draft for a person to confirm.
- Each visitor can generate a few PRDs a minute and 15 an hour.
Before you generate one
Is the PRD generator free? Do I need an account?
It is free and there is no signup. You can generate up to 15 PRDs an hour, and the blank template on this page has no limit at all. An account only comes into it if you want Refinar to build the change.
How is this different from other AI PRD generators?
Most start from a blank page and write a PRD for a new product. This one assumes the product exists: it asks what must not change, writes acceptance criteria you can check against the live app, flags work that touches sign-in, payments or customer data, and — given a public repo — names the files the change will touch. Every path is checked against the repository's real file list. A path that is not there is dropped, and the result tells you how many were.
Do you store my repository or my request?
Nothing is saved to an account or a database. Your request, and the file list of the repository if you gave one, are sent to our AI model provider to write the document. The finished PRD is cached for up to an hour, keyed by a fingerprint of what you typed, so the same request twice returns the same document without another model call. We never read the contents of your source files.
Can it read a private repository?
Not on this page. It reads only what anyone could see on GitHub without signing in. Refinar reads private repositories through a GitHub app you install and limit to the repositories you choose — and there it goes past the document: it makes the change in a live preview and opens a pull request for you to review.
Can I use it with Cursor, Claude Code or Codex?
Yes. Copy agent prompt gives you a short spec written for a coding agent: the goal, what is in and out of scope, the verified files to read first, the acceptance criteria as a checklist, and constraints — leave sign-in, payments and database migrations alone unless they are listed, and stop and ask before going beyond the file list. Paste it as the first message of a session.
What makes a good PRD for an existing product?
Three things a PRD for a new product can skip. It scopes the change against what already exists, so nobody rebuilds a page to change a button. It says what must not change — URLs, data, integrations, the behaviour customers rely on. And its acceptance criteria are checks a person can run in a preview, not aspirations, so the review is a yes or a no.
How accurate are the file suggestions?
Every path shown exists in the repository's default branch — that part is checked, not trusted. Whether each file is the right one is a judgement made from file names and structure, not from reading the code, so treat the list as the place to start. New files the change needs are named in the implementation steps rather than the file list, because they cannot be verified yet.