Write A Prd

Write a PRD

Intent

Use this skill when there is already a reasonably clear idea or shared understanding of a feature, improvement, or project, and the user wants it captured as a Product Requirements Document (PRD).

This skill can be invoked after a deep interview (for example, using grill-me) or directly for smaller, clearer changes.

Workflow

1. Confirm readiness

   • Briefly restate the feature or project in 2–4 sentences.
   • Ask the user to confirm or correct.
   • If understanding is shallow or ambiguous, run a short grill-me style interview first.

2. Gather inputs

   • Ask for or infer:
     • Target users and key personas
     • Primary goals and success criteria
     • Any constraints (tech, timeline, integrations)
   • Explore the repo to:
     • Verify assumptions about current behavior
     • Find relevant modules, APIs, and data models
     • Note any obvious risks or coupling

3. Sketch major modules

   • Identify the main components or subsystems involved (front-end, back-end, infra, data, etc.).
   • Keep this at the level of “modules” or “responsibilities”, not detailed class diagrams.

4. Draft the PRD

   • Use this template as a default, trimming sections that are clearly unnecessary:

# [Feature / Project Name]

## Overview
One short paragraph that describes what we are building and why.

## Goals and Non-Goals
- Goals:
  - [Goal 1]
  - [Goal 2]
- Non-Goals:
  - [Non-goal 1]

## Users and Use Cases
- [User / Persona 1]: [what they need and why]
- [User / Persona 2]: [what they need and why]

## User Stories
- As a [user], I want to [do something] so that [benefit].
- As a [user], I want to [do something] so that [benefit].

## Functional Requirements
- [Requirement 1: short, testable statement]
- [Requirement 2]

## Constraints and Considerations
- Technical:
  - [...]
- Product / UX:
  - [...]

## High-Level Implementation Notes
- Current code touched:
  - [...]
- New modules or components:
  - [...]
- Risks / Unknowns:
  - [...]

5. Validate with the user

   • Present the PRD and invite corrections, missing cases, or new constraints.
   • Update the PRD until the user is satisfied with scope and clarity.

6. Optional: submit as GitHub issue

   • If the repo uses GitHub issues and the user wants it:
     • Create a single issue with the PRD as the body.
     • Include labels or assignees only if the user specifies conventions.

Style Guidelines

• Favor clear, testable requirements over vague aspirations.
• Keep the PRD as short as possible while covering behavior and constraints.
• Explicitly separate requirements (what must be true) from implementation notes (how we might do it).
• When in doubt, add or refine user stories rather than low-level technical detail.