---
name: PRD Writer
slug: prd-writer
category: Writing
description: PRD Writer turns a feature idea into a clear PRD covering problem, users, requirements, and success metrics. Use it to align a team before building.
github: "https://github.com/holaboss-ai/holaOS/tree/main/apps/desktop/electron/default-skills/prd-writer"
language: TypeScript
stars: 7385
forks: 641
install: "npx degit https://github.com/holaboss-ai/holaOS/tree/main/apps/desktop/electron/default-skills/prd-writer ~/.claude/skills/prd-writer"
installs_to: ~/.claude/skills/prd-writer
source_path: apps/desktop/electron/default-skills/prd-writer/SKILL.md
collection_size: 25
category_size: 1012
collection_url: "https://dirskills.com/collections/holaboss-ai/holaOS"
added: 2026-08-15T06:51:33.373Z
last_synced: 2026-08-15T06:51:33.373Z
canonical_url: "https://dirskills.com/skills/prd-writer"
---

# PRD Writer

PRD Writer turns a feature idea into a clear PRD covering problem, users, requirements, and success metrics. Use it to align a team before building.

**Install:**

```bash
npx degit https://github.com/holaboss-ai/holaOS/tree/main/apps/desktop/electron/default-skills/prd-writer ~/.claude/skills/prd-writer
```

## README

# Product Spec

Write the spec that gets a team building the right thing. A good PRD isn't a feature list — it's a shared understanding of the problem, who has it, what "done" means, and how you'll know it worked. It closes the gaps where projects usually go sideways.

## When to use this skill

Use Product Spec to turn a feature idea, request, or rough notes into a product requirements document (PRD) or one-pager. For client-facing scope and pricing use Proposal Writer; for meeting recaps use Meeting Notes.

## What a PRD needs to answer

- **Problem** — what user pain or business need this addresses, and why now. If you can't state the problem, the feature isn't ready.
- **Users & context** — who it's for and the situation they're in when they hit this.
- **Goals & non-goals** — what this explicitly will and won't do. Non-goals prevent scope creep as much as goals drive it.
- **Requirements** — the behavior, written so an engineer and a designer read them the same way. Separate must-haves from nice-to-haves.
- **Success metrics** — how you'll measure whether it worked.
- **Open questions & risks** — the unknowns, surfaced rather than buried.

## Principles

- **Problem before solution.** Anchor on the user's pain; a solution with no stated problem is a guess.
- **Unambiguous requirements.** If a requirement can be read two ways, pick one and make it explicit.
- **Right altitude.** Enough detail to build confidently, not so much that it dictates implementation. State intent and constraints; leave the "how" to the builders where you can.
- **Name the unknowns.** List open questions instead of pretending certainty.

## How to work

1. Pin down the problem and the user before anything else.
2. Set goals and non-goals; they bound everything after.
3. Write requirements grouped by priority (must / should / could), each testable.
4. Add success metrics, then list risks and open questions honestly.

## Output format

A structured doc: **Summary**, **Problem**, **Users & Context**, **Goals / Non-goals**, **Requirements** (prioritized), **Success Metrics**, **Risks & Open Questions**. Keep it as short as the problem allows.