PRD: capture intent before code
A PRD (Product Requirements Document) records the intended outcome, scope, constraints, non-goals and acceptance criteria so an agent does not invent the meaning of done. It is the smallest durable statement of intent that prevents critical gaps from becoming implementation assumptions.
PRD is the first Core phase of AI Architect Mastery's AI Driven Development Methodology. Approved intent feeds the PLAN, then bounded TASKs and evidenced IMPLEMENTATION.
Why intent comes first
Without a written PRD, AI-assisted development can become a chat window full of ad hoc prompts: useful in the moment, but with no durable record of what was agreed. Scope drifts silently. The next agent session or teammate cannot reconstruct the original intent.
Every downstream phase depends on that intent. An agent given a vague instruction may fill important gaps with its own assumptions. The PRD makes those decisions visible while the human can still clarify them.
What a working PRD records
- What is being built and why.
- What is explicitly in scope and out of scope.
- Constraints such as architecture, security, performance and existing conventions.
- Acceptance criteria that make the intended result observable.
Inputs, output and responsibility
Input: human intent, relevant project context and known constraints. Output: an approved requirements artifact. Owner: the Human Architect owns the intent and acceptance; an agent may help research or draft it without deciding unresolved product or architecture questions independently.
A PRD can be a short versioned document that travels with the project. It is not an unnecessarily long enterprise specification. Update it when scope genuinely changes, not merely to make it agree with whatever the agent happened to build.
Constructed example: owner-only export
Outcome: only the record owner may export through the existing interface. Non-goal: redesigning report formatting. Constraints: use the existing authorization conventions. Acceptance: owners can export, non-owners receive no record contents and the successful output format remains unchanged.
Illustrative human decision: approve example PRD E1 for ordinary, single-owner records because the outcome and denial criteria are explicit. Shared-record policy remains an open question, not an implied permission. Resulting artifact: E1 records that scope and those three acceptance criteria; encountering shared records requires a return to the human before that scope can expand. This is a constructed decision, not a real project approval.
What if intent is incomplete?
If shared-record ownership is undefined, record the uncertainty instead of authorizing an invented policy. During later work, the same finding may require a controlled return to PRD and a refresh of affected plans and assignments.
Related concepts
Watch the PRD methodology overview on YouTube (optional video; this text is the current reference).