How to Write a PRD With AI (That Engineers Actually Use)

Most PRDs die the same death: written in isolation, read once, referenced never. The failure usually isn't the document's prose — it's that the PRD encodes decisions nobody explicitly made, so engineers hit every ambiguity during implementation and stop trusting the source. AI changes the economics of drafting a PRD but not the economics of deciding one. This walkthrough shows what a skill-assisted PRD workflow looks like, using the biz-prd skill, and marks clearly where the human work lives.

What you bring to the skill

biz-prd accepts three realistic inputs: a rough idea in a paragraph, meeting notes with attendees arguing about requirements, or existing code you want documented before changing. All three work because the skill's job is structuring, not inventing — it shapes whatever you give it into the standard skeleton: problem statement, goals and non-goals, user stories, functional requirements, non-functional requirements, and success metrics.

Start sloppier than you think. A braindump of "users keep asking for exports, legal wants audit logs, the CEO saw a demo of Competitor B's dashboard" produces a better draft than a polished paragraph that hides the disagreement. The skill will organize the chaos; your job is to make sure nothing gets quietly dropped while organizing it.

The walkthrough

Run it in one long session or several; the shape doesn't change.

1. Feed the raw material. Paste the meeting notes verbatim, or point the agent at the repo. If it's code, ask for the implicit spec first — what the system currently does — then mark which parts are intentional and which are accidents.
2. Read the problem section skeptically. The skill writes a problem statement from your inputs. If it smoothed over the actual disagreement ("stakeholders disagreed on scope" became "a unified approach was needed"), fix it. A PRD that hides conflict transfers the fight into implementation.
3. Audit goals and non-goals. Non-goals are where AI drafts are weakest, because your inputs rarely state exclusions explicitly. Expect the skill to infer them; expect to rewrite half. "No mobile support in v1" is a decision, not an inference.
4. Check user stories against reality. Stories should map to people you have actually observed or spoken with. If a story describes a user you've never met, it's a guess wearing a user's clothes.
5. Leave FR/NFR mostly to the agent, then verify. Functional requirements from existing code are usually accurate. Non-functional requirements (performance targets, accessibility level, data retention) frequently come out as placeholders — fill in your real numbers or mark them TBD explicitly.
6. Stress-test success metrics. "Users are happy" is not a metric. The skill will propose measurable ones; delete any your analytics can't actually count.

Where humans stay in the loop

Two categories of decision cannot be delegated, and pretending otherwise is how AI PRDs lose engineer trust. First, prioritization: what's in v1, what's a fast-follow, what never ships. The skill can present trade-offs — "audit logs and exports both fit, but not with the current team this quarter" — but choosing is the product person's job and should show up in the document with a name attached. Second, trade-off calls: which constraint wins when they conflict (security versus speed of onboarding, data freshness versus cost). A PRD that lists constraints without ranking them re-opens every argument at build time.

If you plan to hand the finished spec to an agent for implementation rather than straight to engineers, structure it accordingly — our piece on spec templates for AI coding agents covers the format differences, and our PM guide covers tooling choices around both.

The honest caveats

A skill-generated PRD is only as good as its inputs; stale meeting notes produce confidently wrong requirements, and the model will not tell you a note was outdated. It also tends toward completeness — every edge case listed, none ranked — so expect to cut. And the first draft will read slightly generic; that's the surface signal engineers use to decide a document isn't worth reading, so inject your domain's vocabulary before circulating.

The meshcode angle

meshcode is a native macOS and Windows app with a multi-pane agent workspace — paste meeting notes in one pane, point a second pane at the codebase, and reconcile both into one PRD while watching each step. It drives your existing Claude Code or Codex subscription, or metered pay-as-you-go credits, and your skills and hooks carry over unchanged. Try it on your next messy meeting notes; the first draft arrives in minutes, and the arguing starts where it should — in the document.

Add the biz-prd skill in the app

👉 Download meshcode — Mac, Windows