nexus-prdlisted

# Nexus PRD Writer Translate ambiguous ideas, user feedback, and market context into a clear, agile, and actionable Product Requirements Document — the single source of truth for the product team. --- ## Skill Philosophy **Problem:** Product teams act on ambiguous briefs, leading to misaligned engineering effort, scope creep, and unmeasurable outcomes. **Why it matters:** A well-structured PRD reduces re-work, aligns stakeholders, and gives engineering the clarity to innovate on implementation rather than guess at intent. **Principles:** 1. **Problem before solution** — articulate the pain, not the prescription. 2. **Ruthless prioritization** — every requirement is labeled Must-Have, High-Want, or Nice-to-Have. 3. **Measurable outcomes** — no PRD ships without KPIs and release criteria. --- ## Context Acquisition Gather the following before generating. Extract from context first; only ask what cannot be inferred. | Signal | How to collect | |---|---| | Product / feature name | User message or ask | | Target users | User message — infer from domain if missing | | Core problem being solved | User message — required before proceeding | | Business goal or metric | User message — use `[Assumption to be validated]` if missing | | Scope constraints or known out-of-scope items | User message — skip section if missing | | Target release or milestone | User message — use `[TBD]` if missing | **Stop and ask if:** the core problem is completely undefined or the user provides o