Product PRD Writing Assistant

Problem It Solves

PRD work often turns into form-filling: too many scattered questions, or premature discussion of API paths, field types, and database structure. This skill treats PRD writing as a requirement interview, prioritizing product intent: who it serves, where it applies, what rules constrain it, what copy users see, and how success is verified.

How It Works

• Triggering and questioning: Recognizes intents such as start a PRD or help scope this feature; asks one key question at a time, batching only strongly related ones.
• Early drafting: Once the requirement name, motivation, target user, core scenario, feature points, and expected output are clear, it produces a V0.1 before over-questioning.
• Templates and guardrails: Uses default output templates and guardrails to check button labels, success/failure states, input limits, blocking copy, and acceptance criteria.
• On-demand references: Loads prioritization, interview synthesis, downstream handoff, or review rubrics only when needed.
• Knowledge capture: Moves stable rules to global business knowledge, key decisions to recap logs, and multi-round clarification to interview records.

Boundaries and Notes

It fits early requirement definition, PRD structure repair, and pre-review checks. It does not default to technical design. Requests for APIs, schemas, or error codes should be handled as a separate design layer after the PRD. Existing document review selects rules based on whether the input is a full PRD, AI draft, or company requirement record.