prd-writing

Writes product requirements documents with problem statements, non-goals, and measurable success criteria.

1|Updated Jul 3, 2026
One-click install
npx skills add https://github.com/Nandansai08/skillz --skill prd-writing-nandansai08
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: prd-writing
Source: https://github.com/Nandansai08/skillz/tree/main/skills/product-pm/prd-writing
Command: npx skills add https://github.com/Nandansai08/skillz --skill prd-writing-nandansai08

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams often build the wrong thing because requirements live in scattered conversations, scope creeps silently, and success is never defined in advance. This Skill structures PRD writing so every document records decisions with evidence, kills scope creep with explicit non-goals, and pre-commits to measurable outcomes. ## Core Features & Use Cases - Evidence-based problem framing: Enforces a problem statement template (user pain + business stake) free of solution vocabulary, backed by interviews, tickets, or funnel data. - Scope containment: Requires a non-goals section with reasons, MoSCoW-ranked requirements, and a would-we-still-ship test for must-haves. - Accountable success criteria: Pre-commits metrics, targets, guardrails, and an instrumentation plan before build starts. - Use Case: Sales requests "invoice customization." The Skill guides you to interview evidence showing customers actually need logo and tax fields, scope the PRD to that, list template editing as a non-goal, and catch a jurisdiction compliance question early — halving the engineering estimate. ## Quick Start Write a PRD for the payout reconciliation feature using the attached support tickets and interview notes as evidence.

Frequently Asked Questions about prd-writing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a PRD problem statement?▼

Write the problem statement as user pain plus business stake with evidence attached: who can't do what because of which obstacle, causing measured user and business cost. Keep all solution vocabulary out — if the feature name appears, it is a justification, not a problem.

What should a PRD include for success criteria?▼

Success criteria should name one or two metrics expected to move, with targets, timeframes, guardrails that must not degrade, and an instrumentation plan. If the tracking events do not exist yet, building them is part of scope.

When should I not write a PRD?▼

Skip the PRD for tiny changes where a well-written ticket suffices, and for solution architecture, which belongs in the engineering design doc downstream. A PRD fits initiatives big enough that multiple people build from a shared document.

Why does a PRD need a non-goals section?▼

Non-goals are explicit exclusions with one-line reasons that prevent scope creep before it starts. Without them, stakeholders add wishlist items through comments and the must-have list triples by design freeze.

How detailed should PRD requirements be?▼

Requirements should specify user outcomes with testable acceptance criteria, ranked MoSCoW-style, not implementation details like schemas or architecture. Over-specified PRDs get malicious compliance instead of the better designs engineers would find.