prd

name	prd
description	Draft a simplified, PMBOK-compatible Product Requirements Document from a product brief and project charter. Invoke when the planning phase begins and the team needs a structured requirements baseline before decomposing scope into a WBS or epics.

Adapted from bmad-method:bmad-create-prd (MIT, © 2025 BMad Code, LLC). See THIRD_PARTY_NOTICES.md.

When to use

Use this skill at the start of the Planning phase, after a product brief or project charter exists but before scope has been decomposed into a WBS or story backlog. Typical triggers include:

• The project sponsor has approved the charter and the team must now define functional and non-functional requirements.
• A stakeholder review surfaces ambiguity about what is in scope versus out of scope.
• The team needs a requirements baseline to anchor cost estimates, schedule, and risk identification.
• A new team member joins and needs a single document that describes what the project must deliver and why.

Do not invoke for charter authoring (initiation phase) or product-brief creation (precedes this skill). Do not use as a substitute for story decomposition — the PRD is the input to epics-and-stories, not the output.

Summon the SME

Before drafting, load the canonical reference on product requirements documents to ground the output in established practice.

Reading the config. Check .pm-kit.config.json for the sourcesMode field:

• If sourcesMode is "online" (opt-in): fetch the URL stored at key sources.prd in vendor/pm-kit/sources-index.json using your available web-fetch capability. Do not name a specific tool — use whatever your runtime provides. Ground the draft in what you read. Do not fabricate quotations or page numbers.
• If sourcesMode is "offline" or the field is absent (the default): rely on your general knowledge of product requirements documents as described by standard project-management and systems-engineering practice. Cite the canonical URL from vendor/pm-kit/sources-index.json at key sources.prd in the output. Do not fabricate quotations or page numbers.

In both cases, the URL to cite is https://en.wikipedia.org/wiki/Product_requirements_document.

Facilitation script

Walk the user through these steps in sequence. Do not skip steps or combine them.

Step 1 — Gather inputs. Ask the user to supply (or confirm the location of) the product brief and, if available, the approved project charter. Identify the project name, the project sponsor, and the intended audience for this PRD. Confirm the inputs are present before proceeding.

Step 2 — Overview. Draft the Overview section: a two-to-three paragraph description of the problem being solved and the proposed solution. Read the inputs carefully. Do not invent content not present in the inputs.

Step 3 — Goals and non-goals. Elicit from the user: What must the project achieve? What is explicitly excluded? Prompt for at least three goals and at least two non-goals. Goals must be verifiable, not aspirational.

Step 4 — Target users and use cases. Ask the user to name each distinct user type and describe one primary use case per type. Prompt for edge cases if the user provides only one user type.

Step 5 — Functional requirements. Elicit requirements one by one. For each, confirm it is testable: "Given a defined condition, the system must produce a defined, observable output." Number them sequentially (FR-01, FR-02, …). Prompt the user to distinguish requirements from design decisions — requirements say what, not how.

Step 6 — Non-functional requirements. Cover at minimum: performance, security, accessibility, and observability. Ask for quantified targets where possible (e.g., "page load under 2 seconds at P95").

Step 7 — Constraints, assumptions, dependencies, and out-of-scope. Elicit each category in turn. Confirm that out-of-scope items match the non-goals.

Step 8 — Success metrics. Ask how the project will be declared successful. Each metric must be measurable and owned by a named role.

Step 9 — Open questions. Capture any unresolved issues the team must answer before the PRD can be baselined.

Step 10 — Save the artifact. Save the filled artifact to docs/pm-kit/outputs/prd/<short-slug>.md. <short-slug> is a kebab-case ASCII slug (max 40 chars) derived from the project name (e.g., bookswap-campus). Confirm the final path with the user before writing. If the file exists, ask: overwrite, append a date suffix (e.g., -2026-04-20), or pick a new slug. The artifact begins with the three-line provenance header below (HTML comments, do not render):

<!-- Generated by agentic-pm-kit:prd on YYYY-MM-DD -->
<!-- Languages: communication=<value>, output=<value> -->
<!-- Source mode: offline | online -->

Languages

The kit separates the language used for live agent–user dialogue from the language used in the saved artifact. Both values live in .pm-kit.config.json and are free-form strings — read each value verbatim, never infer a language from the conversation, and never select from a hardcoded list.

Facilitation dialogue. Speak to the user during facilitation in the language at language.communication. Use the string verbatim.

Filled artifact (saved TEMPLATE.md output). Produce the written artifact in the language at language.output. If language.output is absent or empty, fall back to language.communication.

Example values either field might contain: "en-US", "es-MX", "Português brasileiro", "Mandarin Chinese". Accept any string as given.

Acceptance gate

When the PRD is complete, point the user to CHECKLIST.md (sibling file) and ask them to verify each item. Remind them that the output must be marked PASS or FAIL. On FAIL, invite the user to return with specific notes so the facilitation can be resumed or corrected.