# Write A Prd

> Turn a clarified feature or project idea into a concise Product Requirements Document by combining conversation context with codebase exploration, user stories, and high-level implementation notes, optionally submitting the result as a GitHub issue.

- Skill: `spicy-samson/write-a-prd` (Agent Skill)
- Install (CLI): `npx skillmds@latest add spicy-samson/write-a-prd`
- Raw SKILL.md: https://api.skillmd.com/api/skills/spicy-samson/write-a-prd/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: spicy-samson (https://skillmd.com/u/spicy-samson)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/spicy-samson/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:

```markdown
# [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.