Product Requirements Document (PRD) Authoring

What is it?

This skill generates a high-quality Product Requirements Document (PRD) that establishes shared understanding across product, engineering, and leadership.

It emphasizes problem clarity, reasoning, and trade-offs, not feature lists or implementation details.

When to Use This Skill

Use this skill when you need to:

• •Define a new product or major initiative
• •Reframe or correct an existing PRD
• •Establish alignment before roadmap or feature planning
• •Translate ambiguous ideas into a clear product definition

Do not use this skill for:

• •feature-level specifications
• •roadmap sequencing
• •UI or UX design
• •implementation planning

Core Principles

When authoring a PRD, always prioritize:

1. •User problems over solutions
2. •Explicit assumptions
3. •Clear goals and non-goals
4. •Early acknowledgment of constraints
5. •Measurable success criteria

Analytical Dimensions

Before writing the PRD, reason through:

• •user context and motivation
• •problem framing and urgency
• •goals vs non-goals
• •functional scope boundaries
• •constraints and trade-offs
• •risks and failure modes

These dimensions must be reflected in the final document.

Output Structure

Unless otherwise specified, the PRD should follow the canonical structure defined in:

• •assets/prd.template.md

Sections may be expanded or collapsed as appropriate, but the reasoning integrity must be preserved.

Important Boundaries

This skill must not:

• •ask clarification questions
• •plan next workflow steps
• •create tasks or tickets
• •specify UI, UX, or technical architecture
• •interact with users

All orchestration decisions belong to the calling agent.

Output Expectations

The output should be:

• •clean Markdown
• •directly usable as a PRD artifact
• •neutral and analytical in tone
• •suitable for product, engineering, and leadership review