# Prd Writer

> Turn a feature idea into a clear PRD — problem, users, requirements, and success metrics.

- Skill: `holaboss-ai/prd-writer` (Agent Skill)
- Install (CLI): `npx skillmds@latest add holaboss-ai/prd-writer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/holaboss-ai/prd-writer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: holaboss-ai (https://skillmd.com/u/holaboss-ai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/holaboss-ai/prd-writer

---


# 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.