A product requirements document is useful when design, engineering and testing can derive the same behavior from it. Filling every template heading does not establish that agreement. This guide uses a fictional community repair service adding appointment rescheduling. It connects recorded decisions, a first draft, diagrams and competitive evidence. The example rules are illustrative team decisions, not claims that a system has been built or tested.
Organize the inputs before asking for a draft
“Make rescheduling convenient” hides decisions about who can act, when changes are allowed, whether the technician must approve, when the original slot is released and what happens if a notification fails. Collect the current process, support evidence, technical constraints and meeting notes. Give each input an identifier and date. Separate agreed rules, individual suggestions, untested assumptions and open questions so the agent cannot promote a casual remark into a commitment.
Maintain a decision log containing the question, current decision, rationale, responsible roles, applicable version and any decision it supersedes. For example, D-01 may permit changes before an appointment while leaving the exact cutoff unresolved. Write unresolved explicitly rather than letting a model invent a plausible two-hour deadline. After review, record which requirements, diagrams and cases each change affects.
Deliver a question list and a one-page scope statement first: user, present obstacle, intended improvement, first-release behavior, non-goals, dependencies and acceptance approach. In this example the first release handles a single appointment, not package refunds or a replacement scheduling system. A designer can sketch structure early, but a polished screen should not silently decide unresolved business rules.
Scenario one: turn the scope into a reviewable specification
Separate user tasks from system responsibilities. The user selects a new slot, confirms the change and reads the outcome. The system checks current availability, commits the change and records notification status. Give requirements stable identifiers, such as R-01 for available slots, R-02 for submitting a change and R-03 for repeated submissions. Link rules to evidence or decisions; keep unsupported additions in a proposals section.
For the main use case, specify actor, preconditions, trigger, normal sequence, postconditions and alternatives. The user must be authenticated and authorized for that appointment. A successful postcondition describes saved state, not merely a success toast. Distinguish the user's click, the server accepting a request, the committed appointment change and the delivery of a notification. These are different events with different failure possibilities.
Start a data dictionary with appointment_id, requested_slot_id, revision, request_id and updated_at. For each field specify type, required status, permitted values, empty-value meaning, display behavior and ownership. State the timezone and comparison basis for deadlines. When the interface displays local time, preserve a traceable original value. Do not let a draft invent existing database tables, API fields or connected services.
Write permissions separately. The appointment owner may request a change; whether staff can act on their behalf requires an actual decision. Knowing an appointment identifier must not confer authority. Tracking requirements also need a purpose and minimal fields: viewing, submitting and receiving a result need not include full contact details. The first draft contains requirement cards, use cases, field definitions, permissions and unresolved issues, with length determined by the feature rather than a page target.
Scenario two: model state and handoffs before polishing screens
Select a diagram according to the question. A business flow describes steps and responsibilities. A sequence diagram shows messages between the interface, service and notification component. A state diagram describes allowed changes. A use-case model identifies what each actor can do. Mixing page navigation, persisted appointment state and notification state into one large picture can conceal rather than expose a gap.
Keep appointment and notification states distinct. A confirmed appointment may remain confirmed after a controlled reschedule while its slot and revision change. Its notification can separately be pending, sent or failed. Treating a failed notification as a failed appointment update could cause a retry to repeat a change that already committed. State the transaction boundary, retry conditions and the outcome shown to the user in both text and diagram annotations.
Mermaid is an MIT-licensed open-source diagram option worth evaluating because editable text can be reviewed and versioned with a document. It supports state diagrams and other useful views. A successful render is a syntax result, not evidence that the business process is correct. Check the renderer and version used by the actual document destination; do not promise that any Markdown surface will render a pasted diagram.
Use stable node identifiers, familiar labels and transitions with events and conditions. Split an oversized diagram into availability lookup, confirmation and notification recovery, with shared requirement identifiers. Deliver editable source, a readable export for the destination and a legend. For rendering errors, reduce to a small example and check syntax and version compatibility; do not delete exception paths merely to make the diagram compile.
Worked example: specify contention for the last slot
Suppose two users choose the same final available slot. R-02 should require that at most one request acquires it. The other receives an understandable conflict result and retains the original appointment. “No double bookings” leaves too much unspecified: identify where final availability is checked, how the interface recovers and whether it must refresh available slots.
Now add repeated confirmation clicks, a request timeout after the server committed, a page refresh, a simultaneous staff edit and a target slot that has just closed. request_id and revision are candidate design concepts; technical review determines whether and how to use them. The PRD must specify repeated-request outcomes and conflict behavior without presenting one database implementation as the only acceptable design.
A practical agent request is: “Use only meeting record M-01 and scope S-01. First list conflicts, missing information and decisions needed. Then draft the main flow, alternatives, field dictionary and acceptance matrix. Every rule needs a source or a proposal label. Return editable diagram source. Do not connect to production or claim tests have run.” Review scope and states before expanding the prose to catch mistaken premises early.
The acceptance matrix includes rule identifier, initial conditions, action, expected saved state, user-visible outcome and verification method. In this example a notification failure does not reverse a successful reschedule: the interface distinguishes a completed change from a notification waiting for retry. That is a local example decision, not a universal requirement for every service. Test owners derive checks from the matrix; actual run results remain separate from the expected outcomes written in the specification.
Scenario three: use competitive evidence to challenge the feature
Define a comparison question such as “How do users understand a rescheduling conflict?” Choose comparable products, regions and plans, and record the observation date. Separate official help statements, directly observable interface behavior, marketing claims and unknown items. If an account or paid permission is unavailable, leave the item unverified instead of asking the agent to guess hidden behavior. A competitor having a button does not demonstrate demand among your users.
A comparison table might cover entry point, cutoff explanation, slot-conflict messaging, notification-failure handling and observable accessibility clues. Attach a source locator, short factual summary and verification status to each row. Translate the relevant findings into user stories that name a role, context, action and intended outcome. Add acceptance conditions; “As a user I want convenient rescheduling” does not establish how the system should behave.
Use SWOT to organize hypotheses and constraints, not to manufacture a strategic conclusion. A Must in MoSCoW should follow from the first-release goal or a necessary dependency. If using RICE, define reach, impact, confidence and effort, including where each estimate came from. Unknown data should remain unknown. Compare a user-impact-heavy ordering with a cost-heavy ordering and show where priorities change. Ask engineering for estimate ranges rather than treating a precise model output as a delivery promise.
Deliver the evidence table, prioritization rationale and a retained or deferred list. Record why rejected features were deferred so they are not relitigated at every meeting. Explain which inputs actually changed the decision and which assumptions still need interviews, prototype work or a limited experiment. Competitive research complements user evidence and feasibility review; it cannot replace them.
Apply a matching Skill to the documentation step
Writing Guidelines fits the structure, wording and readability pass on an existing technical PRD after the decisions have sources. It needs the target documentation files and network access to its linked writing handbook. Retrieve that handbook and confirm the intended audience and house style before applying its Vercel-oriented guidance. Supply approved terminology, rule identifiers and the draft. Ask it to preserve constraints and unresolved items and return a change list. Review whether “possible” or “undecided” was accidentally rewritten as a commitment. This skill does not collect competitor evidence, authorize requirements, render diagrams or run acceptance tests.
This guide does not invent installation links for PRD, research or diagram skills named in the source without a verified matching catalog record. When a candidate becomes available, inspect its repository, version, license, dependencies and file or network access requirements, then compare it on the same sanitized repair-service fixture. Installation, discovery, execution and accepted output are separate checkpoints. A package license also does not make model calls or external services free.
Use the documentation tools the team can maintain. A new service is unnecessary when a versioned document, a decision log and editable small diagrams answer the question. Preserve source files alongside exports, and keep document and diagram revisions tied to the same rule version so a stale image cannot contradict the current requirements.
Troubleshooting and frequently asked questions
Why does the draft still feel generic? Check whether the input includes actual roles, rules, failure paths and non-goals. Remove empty headings that do not support a decision. Why does engineering keep finding missing boundaries? Walk through duplicate actions, concurrency, timeout, cancellation, authorization, dependency failure and recovery for every relevant state, then map the answers to cases rather than simply writing more pages.
Must a designer learn a complete modeling toolchain first? Start with a readable actor list, state table and small diagrams. Shared meaning matters more than visual complexity. Does a rendered diagram pass acceptance? It only shows that this renderer accepted the syntax; inspect rule coverage, reachable states and exception behavior separately.
Will AI double throughput? There is no general guarantee. Measure drafting time, review rework, missed rules and total delivery time across comparable tasks. How do we avoid reopening every decision? Use stable identifiers, change ownership, effective versions and an issue log. Recheck associated Skill sources and outputs periodically against a fixed fixture, record replacements, and deliver a PRD that another colleague can use to explain why the feature exists, how it can fail and what counts as done.