When I wrote about my PRD and ERD Agent Skills, I spent most of the post on why you want both. I didn't say much about what actually goes in each one. That turns out to be the part people search for, so here it is.

The short answer: the PRD decides what you build and why. The ERD decides how it gets built and in what order. Everything below is about keeping those two apart.

One note before we start. ERD here means Engineering Requirements Document. It is not an entity-relationship diagram, though it does contain data models.

Where each one sits

Dex Horthy of HumanLayer splits the work before code into four steps in his essay Why Software Factories Fail. My skills follow the same split:

1. Product requirements. What we build and why. This is the PRD.
2. System architecture. How services, contracts and data fit together. ERD.
3. Program design. The shape of the code: files, types, signatures and call stacks. ERD.
4. Vertical slices. The build order, one testable end-to-end slice at a time. ERD.

So the PRD is one step and the ERD is the other three. A human signs off at each step, before any code exists.

What goes in a PRD

The PRD stays in product space. It describes what the user experiences. When a technical thought comes up while writing it, and it always does, it gets parked in a list for the ERD instead of being decided on the spot.

These are the sections nearly every PRD needs:

• Description. An elevator pitch someone outside product and engineering gets on one read.
• Problem. The pain in the user's own words, and who has it. If you can't name the problem crisply, the PRD isn't ready.
• Why. The evidence the problem is real. Hard data and assumptions are marked apart.
• Success. What you read after launch to decide it worked. A precise definition, where the number comes from, the baseline, the target and the date to check it. Vague success criteria are the most common way a PRD fails.
• Audience. Who you are building for.
• What. The heart of it: key features, user journeys, design or rough HTML mockups, the actual product copy, what's out of scope, constraints, and edge cases.
• How. The experiment plan, if the feature is an experiment.
• When. Milestones and tentative dates.

Larger PRDs add open questions and notes for architecture, notifications and email, third-party tools, seeding, go-to-market and a glossary.

Notice what is missing. There are no schemas, no endpoints, no file names. A PRD that picks a database has wandered into the ERD's job.

What goes in an ERD

The ERD starts from an approved PRD and turns it into something a coding agent can build and a reviewer can check. It is written in three phases, and each one gets reviewed before the next starts.

System architecture covers:

• A short summary of the PRD, with a link back to it.
• Every open question and edge case from the PRD, sorted into requirements, constraints, engineering problems, or product gaps to send back.
• The contract for each user journey, including the error responses.
• Non-functional requirements like latency, availability and consistency.
• A back-of-the-envelope load estimate, and what really needs to be synchronous.
• Data models and access patterns, with indexes named.
• Components, data flow and a sequence diagram per main flow.
• Client-side error states and analytics events.
• Logging and alerts, single points of failure, and security.

Program design covers:

• A file-tree diff of every file added, changed or removed.
• The key types and function signatures.
• Call-stack trees for any change in control flow.
• Where the tests hook in.
• Each place the codebase allows more than one approach, as a question with a recommendation.

Vertical slices is the build order. The first slice is a tracer bullet, the thinnest path through every layer with mock data behind the contract. Each slice after that adds one capability and replaces one mock with the real thing. Each slice says how to try it and which test proves it.

That last phase matters more than it looks. Left alone, a model plans horizontally: every migration, then every service, then the API, then the UI. Nothing works until the end, and you review it all at once.

Where the line sits

A few rules keep the two documents honest:

• Product intent lives in the PRD. The ERD links to it and copies only what a reader needs. Engineering decisions never get written back into the PRD.
• Product gaps go back to the PRD owner. If the ERD finds missing copy or two parts of the PRD that disagree, it doesn't quietly decide. It asks, with a proposed answer, and designs against that until someone says yes.
• The PRD's out-of-scope list carries forward. Whatever product said "not now" to stays out of the design.
• One of each per feature, updated in place. You don't start a new PRD for version two. You edit the old one and let Git show what changed.

When you need both, one, or neither

Not every change deserves two documents. Both skills size the change first:

• Small (a copy tweak, a bug with an obvious repro): neither. Hand it to the agent.
• Medium (a contained feature in one area): a short PRD, then the ERD continues in the same file, so it's one plan doc.
• Large (a new product surface, or anything where a misread intent is expensive): a full PRD and a full ERD.
• Refactor or infra change: no PRD, because nothing changes for the user. The ERD says so and explains what gets easier or safer.

Get the skills

I packaged both as Agent Skills for Claude Code and Codex. They also work in Cursor, Gemini CLI, GitHub Copilot, Windsurf and any other agent that reads the SKILL.md format. You describe the feature, and the PRD skill drafts the PRD. Once you approve it, the ERD skill writes the plan one phase at a time.

Both are on Agensi as the Engineering Workflow bundle, or on their own as the PRD skill and the ERD skill. For why I built them and how a session goes, see the original post.