product-prd-authoring

Standalone Mode: This skill is part of the prepkit-product plugin.

• spec/product-context.md is optional — provide context inline or create one from the template.
• Output paths (research/, reports/) are relative to your current working directory.
• Facilitation routing is advisory — invoke any skill directly.

Product PRD Authoring

When To Use

• Discovery is settled and the team is ready to define an execution-ready slice
• Engineering needs a handoff doc with traceable requirements
• Scope or non-goals are unclear
• Acceptance scenarios are too vague to test
• The design includes retention loops, nudges, rewards, streaks, or other engagement mechanics

Key Concepts

• Traceability: every requirement ties back to evidence or an explicit hypothesis
• Independent vs. foundational value: some requirements deliver direct user value; others only enable it
• Given/When/Then: behavior-focused acceptance scenarios
• Non-goals: explicit exclusions that hold scope steady

Rules

• Do not start a PRD until discovery and validation are settled
• Read ## Opportunity Map before writing scope, dependencies, or non-goals
• Every major requirement must be tagged as evidence-backed or hypothesis-backed
• Requirements that are only foundational must be labeled explicitly
• Before locking scope, present at least 2 delivery options and recommend the smallest slice that can move the success metric, with everything else recorded as a non-goal — scope locks without option comparison are how teams ship more than the problem requires.
• Scope must include explicit non-goals
• ALL acceptance criteria MUST use Given/When/Then format when behavior is specified. No exceptions. Vague acceptance criteria like "the page loads fast" are not testable — rewrite as "Given [context], When [action], Then [observable outcome]."
• If the slice includes habit loops, gamification, or behavioral nudges, activate product-engagement-design and record safeguards plus counter-metrics in the PRD
• If the slice involves freemium, activation, onboarding-to-value, wow moment design, or in-context upsell mechanics, activate product-engagement-design to load PLG flow design patterns before specifying requirements
• Accessibility requirements must be made explicit: either included in scope with acceptance criteria, or recorded as a deliberate non-goal with a revisit trigger — silence is not a valid disposition
• Frame every requirement around the user outcome it must produce, not the feature it describes — a PRD that specifies features without naming the behavior change it expects cannot be validated after launch
• Apply Show, Don't Tell across all user-facing requirements: for each feature, ask "can the user experience this value directly, or are we asking them to imagine it from a description?" If the answer is "imagine," redesign the interaction to demonstrate. See first-principles-thinking.md in product-discovery-synthesis/references/.
• Apply all output quality gates from references/product-quality-gates.md.
• Every PRD must include at least 3 explicit non-goals. Non-goals with fewer than 3 items indicate insufficient scope discipline — force the team to name what they are deliberately not building, not just what they are building.
• Every PRD must include a kill criterion: the specific condition under which the initiative should be stopped, rolled back, or deprioritized. Format: "Kill if [metric/signal] reaches [threshold] within [timeframe]." A PRD without a kill criterion has no exit strategy.
• Every major requirement must be traced back to a JTBD statement. Requirements not linked to a job are features without a problem — they should be challenged or moved to non-goals. Use the format: "Supports JTBD: When [situation], I want to [motivation], so I can [outcome]."