context-to-prd

Context to document

Write "already thoroughly discussed requirements" directly into a PRD.No interviews— you already have enough context; asking again is a waste.

Usage boundaries

• Applicable: the requirements have already been discussed clearly with AI, and the problem, users, scope, and boundaries all have conclusions; only the document is missing.
• Not applicable：
  • Requirements are still verbal and boundaries have not been clarified → first use requirement-clarify for a round of interviews
  • Need to reuse an existing product experience baseline, or need to create an incremental PRD (writing only this change) → use prd-write
  • Need to review an already written PRD → use grill-with-prd

Relationship with prd-write (important)

Both producethe same structure: both use template.md 's sections 0–10 as the skeleton, writing the same file prd.md. The difference is only in the process:

	This Skill	prd-write
Whether to interview	No interviews	No interviews
Whether reading the product experience baseline is mandatory	Not mandatory. If there is one, read it and write it into section 2; if not, write "no baseline"	Must check. Incremental mode relies on it to clearly write "reuse / local / candidate / deviation"
Typical scenario	Thoroughly discussed, written in one pass	A feature in iteration that needs to align with existing specifications

Both produce the same prd.md; do not run them consecutively. Writing one is enough; the other is a substitute.

Before starting

1. Determine the feature name, usinglowercase hyphens（user-auth、payment-flow); target docs/prd/<feature-name>/prd.md。
2. If a PRD with the same name already exists, first ask the user:update, create another feature directory, or keep the original— do not silently overwrite.
3. Check docs/product/<project-name>/. If there is a baseline, read it and write it into section 2; if not, write "no baseline", and do not invent product-level rules out of thin air.

Process

1. Sort out the context

From this conversation,already settledpick out the things: problem, target roles, scope,explicitly not doing, known constraints, acceptance criteria.

What is not settleddo not decide on its behalf— write it into section 9 "Open questions", indicating the owner. The "explicitly not doing" item is the easiest to miss; proactively go back and look for it: was anything excluded during the discussion?

2. Explore the codebase

If you have not yet understood the codebase, look through it first. Use the project's domain vocabulary throughout, and follow the existing architecture decision records (ADRs) for the relevant areas.

3. Sort out modules (this Skill's unique output)

Sort out the main modules that need to be created or modified, and proactively look forindependently testable deep modulesopportunities:

Deep modules: Encapsulates a large amount of functionality, exposing a simple and stable interface to the outside, making it easy to test independently. Conversely, shallow modules spread complexity outward, so testing and changes will drag in a whole area.

Confirm with the user whether these module divisions meet expectations, and which modules need tests written.

Write the conclusion into Section 10 "Handover Notes", not into Section 7— module division and test scope are implementation decisions, Section 7 only writes behavior the user can verify. If the two are mixed together, during review no one can tell which item is a requirement and which is an approach.

4. Writing

Using template.md 's Sections 0–10 as the skeleton, write into docs/prd/<feature-name>/prd.md(automatically create if the directory does not exist).

• Mode: no product baseline, or this is the first version/major module → full; during iteration only one feature is changed → incremental
• Section 7Organize by user-verifiable behavior. For each requirement, clearly write the role, trigger conditions, main flow, state changes, permissions, exceptions, and acceptance results — see Section 7 of the template for writing examples
• Mark facts with sources; mark reasonable inferences with [INFERRED]; anything that cannot be confirmed goes into Section 9
• Do not make up content just to fill the template. Leaving it blank is better than writing it wrong

Deliverable

docs/prd/<feature-name>/prd.md, completely isomorphic with prd-write .

What not to do

• Do not interview users (that is requirement-clarify 's job).
• Do not make business decisions on the user's behalf that have not been discussed; only lay out the options and consequences clearly.
• Do not write code or file paths — they will quickly become outdated.
• Do not make up content because "it looks bad for this section of the template to be empty".

Pre-delivery check

• The deliverable structure is consistent with template.md 's Sections 0–10
• Existing prd.md has not been unintentionally overwritten
• Anything not settled in the conversation has gone into Section 9 with the owner clearly stated, and not a single item has been made up as a fact
• Section 7 writes user-verifiable behavior, not a page list or technical tasks
• After writing, scan once for garbled text:grep -rnI $'\xef\xbf\xbd' docs/prd/<feature-name>/

Next step

• After writing, hand it to grill-with-prd for item-by-item stress testing —do not skip this step, you cannot see contradictions in a PRD you wrote yourself.
• When external visual evidence is needed, use web-design-extractor; when an independent review prototype is needed, use design-spec-prototyper。