Prd Writing

5. Run quality gate before finalizing. Use references/prd-quality-checklist.md. Fix gaps before delivering final output.

Writing Rules

• Use concrete, testable statements; avoid ambiguous language like "optimize", "friendly", or "fast enough".
• Attach priority to requirements (P0/P1/P2).
• Define acceptance criteria as observable outcomes.
• Separate "what/why" (PRD) from "how" (implementation details), unless user explicitly asks for technical design depth.
• Use exact calendar dates when mentioning milestones or versions.

Output Requirements

Include these minimum outputs:

1. Document metadata (version, date, owner, status).
2. Problem and objective definition.
3. Requirement source and priority mapping.
4. Module-based functional design sections.
5. Unified non-functional and governance standards.
6. References and change log.

Resource Usage

• Use references/prd-template.md to generate the PRD skeleton.
• Use references/prd-quality-checklist.md to validate completeness and quality.
• Reuse the template headings directly unless the user requests a custom structure.

Response Pattern

When responding, follow this order:

1. State assumptions (if any).
2. Provide the PRD draft in Markdown with stable heading hierarchy.
3. End with a short "Open Questions" section if key inputs are missing.

Constraints

• Keep the skill independent from any specific business context.
• Keep the skill independent from any specific framework, language, or architecture stack.
• Use placeholders when domain facts are unknown; never fabricate business facts.