# Prd Writer

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

- Repository: https://github.com/holaboss-ai/holaOS (11451 stars)
- Category: Engineering
- License: see repository
- Last updated: 2026-10-28
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add holaboss-ai/holaOS --skill prd-writer -g -a claude-code -y`
Codex: `npx skills add holaboss-ai/holaOS --skill prd-writer -g -a codex -y`
Cursor: `npx skills add holaboss-ai/holaOS --skill prd-writer -g -a cursor -y`
Gemini CLI: `npx skills add holaboss-ai/holaOS --skill prd-writer -g -a gemini-cli -y`

## Description

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

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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

The rest: https://github.com/holaboss-ai/holaOS/blob/HEAD/apps/desktop/electron/default-skills/prd-writer/SKILL.md