Interview a "one-sentence requirement" into input that can be used to write a PRD. When the requirement is incomplete, AI will not stop to ask; it will fill it in according to its own understanding—so the gaps must be asked about before writing.
Usage Boundaries
- Applicable: The requirement is still verbal, in chat logs, or a one-sentence description; the requirement source (boss, business side, client) has clearly stated "what is wanted," but not where the boundaries are.
- Not applicable: The requirement is already fully clear, directly write the document → use
prd-write; there is already sufficient context and no interview is needed → usecontext-to-prd。
and grill-with-prd The difference (important, the two do not overlap)
| This Skill | grill-with-prd |
|
|---|---|---|
| Timing | PRD Before writing | PRD After writing |
| Method | ConstructiveInterview—fill in the missing information | AdversarialStress test—question the existing document item by item |
| Output | clarify.md(fed into the step that writes the PRD) |
Write directly back to prd.md |
The two cannot replace each other: without clarify.md , you cannot produce a quality PRD; without grill-with-prd, the boundaries of the written PRD are still vague.
Before Starting
- Determine the feature name, using the hyphenated format
<feature-name>; target directorydocs/prd/<feature-name>/。 - Check the codebase first, then ask people. If the answer can be found from existing code, existing PRDs, or the experience baseline under
docs/product/, do not ask the user—asking about things already known will wear down their patience. - Organize what the user has already said into a "known" list, and start the interview from places outside "known."
Interview Rules
- Ask only one question at a time, and wait for the user to answer before asking the next one. Do not throw out a string of questions at once.
- For each question, giveyour guessed default answer, and let the user confirm or correct it. This is much faster than open-ended questioning and makes it easier to uncover the real boundaries.
- When the user cannot answer, record it as
[UNKNOWN]and note who needs to decide it,do not make it up for them。
Five Types of Information to Clarify
| Category | What to Clarify | Typical Follow-up Questions |
|---|---|---|
| Target Role | Who uses it, how many roles there are, where the permission differences are | "User" → Is it operations or an administrator? Do they see the same entry point |
| Trigger Scenario | When it will be used, where to enter from | "An export function is needed" → Export from the list page or the detail page? Export the current filtered results or the full set |
| Scope | What this phase does, and to what extent | "Supports batch operations" → What is the batch limit? What happens if some fail? |
| Explicitly out of scope | What seems related but is not being done in this cycle | Users usually omit this,so you must proactively ask— this item directly determines whether the AI will fill it in on its own |
| Known constraints | Time, compliance, dependent upstream and downstream systems | "It has to launch by the end of the month" → When can the XX service it depends on provide the API? |
Artifacts
Write to docs/prd/<feature-name>/clarify.md：
- Known facts (traceable sources)
- Differences in target roles and permissions
- Trigger scenarios and entry points
- Scope / Explicitly out of scope
- Known constraints
- Open questions
Follow the repository's evidence annotation convention: mark facts with sources, mark reasonable inferences with [INFERRED], and mark what cannot be confirmed with [UNKNOWN] and note the owner.
End condition
Each of the five categories of information has a clear answer, or has been recorded as [UNKNOWN] and assigned an owner, and then it can end.Do not aim to ask everything— leaving "still unknown" explicitly on record is more valuable than making up an answer on the spot.
When no one is available to answer (self-answer mode)
When doing a demo, doing regression, or when the user explicitly says "you go through it yourself first," you can use self-answer mode:
- Stillhandle one question at a time, but you provide the default answer for each question yourself, and in
clarify.mdmark the conclusion as[自答], do not write it as if the user had said it. - Two bottom lines cannot be crossed:
- Those involving business decisions(pricing, benefits, priority, launch scope) — even in self-answer mode they must be recorded as
[UNKNOWN]and note the owner. That is not a call you can make for someone else. - Those that can be found from the codebase or an existing PRD— still look them up first, do not self-answer.
- Those involving business decisions(pricing, benefits, priority, launch scope) — even in self-answer mode they must be recorded as
- At delivery, clearly separate the three categories: user-confirmed, self-answered, and still
[UNKNOWN]. Mixing the three together is the biggest risk of this mode— the user will think that the self-answered conclusions have already been approved by them.
What not to do
- Do not write the PRD body (that is the job of
prd-write/context-to-prd). - Do not make business decisions for the user; only take responsibility for laying out the options and consequences clearly.
- Do not throw out all the questions at once.
- Do not repeatedly ask about things that can be found in the codebase.
Next step
Hand clarify.md to prd-write to write a new PRD; if the context is already sufficiently complete, you can also go directly to context-to-prd and write it up.