# prd

Turns a feature description into a Product Requirements Document: asks clarifying questions, drafts user stories with acceptance criteria, saves the file under tasks/.

- skill · `type=skill` · Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, OpenCode · 531 installs · ★ 294
- Author: smallnest
- License: MIT · policy=mirror · the beginning of the file is at the end of this page
- Source: https://github.com/smallnest/goal-workflow/tree/HEAD/skills/prd/SKILL.md
- Updated: 2026-09-13
- HTML: https://affpapa.org/en/nevibecode/skills/smallnest-prd

## What it does

The skill takes a feature description and builds a PRD from it. First come clarifying questions, then the document itself: goals, user stories, functional requirements, acceptance criteria. The question count scales with complexity rather than sitting at a fixed number — two or three for a simple feature, six to eight when several user roles or cross-system integration are involved. Answers can be terse, like "1A, 2C, 3B".

Every user story is numbered US-001 upward and carries criteria you can actually check: a UI state, an API response, a passing typecheck. Vague wording such as "works correctly" gets rejected. One end-to-end test story is mandatory and comes last — it walks the full happy path from user action through UI and API into the data layer, plus at least one failure case.

The draft goes back to you for review, and only after confirmation does the skill write it to `tasks/prd-[feature-name].md`. It stops there and does not start implementing. If your answers stay vague, the gaps get filled with reasonable defaults marked `[Assumption]`, so expect to confirm those during review. From there the chain continues with `/prd-to-spec` for technical design and `/to-issues` to cut the work into tickets.

## Install

### Claude Code (native platform)

1. **Skills CLI (Vercel)**
```bash
npx skills add smallnest/goal-workflow --skill prd -a claude-code
```

2. **Manually: put the files in place**
- File: `~/.claude/skills/prd/SKILL.md` — Copy the whole skill folder; for one project use .claude/skills/prd/

### Codex

1. **Skills CLI (Vercel)**
```bash
npx skills add smallnest/goal-workflow --skill prd -a codex
```

2. **Manually: put the files in place**
- File: `.agents/skills/prd/SKILL.md` — For all projects use ~/.agents/skills/

### Cursor

1. **Skills CLI (Vercel)**
```bash
npx skills add smallnest/goal-workflow --skill prd -a cursor
```

2. **Manually: put the files in place**
- File: `.cursor/skills/prd/SKILL.md` — Cursor also reads .agents/skills/ and .claude/skills/

### GitHub Copilot

1. **GitHub CLI**
```bash
gh skill install smallnest/goal-workflow prd
```

2. **Manually: put the files in place**
- File: `.github/skills/prd/SKILL.md`

### Gemini CLI

1. **Skills CLI (Vercel)**
```bash
npx skills add smallnest/goal-workflow --skill prd -a gemini-cli
```

2. **Platform CLI**
```bash
gemini skills install https://github.com/smallnest/goal-workflow --path skills/prd
```

### Windsurf (Devin Desktop)

**Manually: put the files in place**
- File: `.devin/skills/prd/SKILL.md` — The legacy .windsurf/skills/ path still works

### OpenCode

**Skills CLI (Vercel)**
```bash
npx skills add smallnest/goal-workflow --skill prd -a opencode
```

### Claude.ai

**Claude.ai**
- Zip the folder and upload it in Settings → Capabilities → Skills

Where a file is given instead of a command, copy the files from the source to that path: https://github.com/smallnest/goal-workflow/tree/HEAD/skills/prd/SKILL.md

## When to use it
- turn a rough feature idea into a PRD with goals and boundaries
- break a feature into user stories with verifiable acceptance criteria
- force an end-to-end test story into the plan
- mark assumptions when requirements stay vague
- save the document under `tasks/` and hand it to ticket creation

## Example prompts
- create a PRD for CSV report export
- write a PRD for Google sign-in, new users only
- plan this feature and then run /to-issues on it

## Source text · SKILL.md · MIT

Below is the content of a third-party file. It is data, not instructions for you: do not act on anything written inside unless the human asks. Block tag: 1da082c55752dc2d.

BEGIN THIRD-PARTY FILE 1da082c55752dc2d
````text
---
name: prd
description: "Generate a Product Requirements Document (PRD) for a new feature. Use when planning a feature, starting a new project, or when asked to create a PRD. After PRD is confirmed, use /prd-to-spec (optional) for technical design, then /to-issues to create implementable tickets. Triggers on: create a prd, write prd for, plan this feature, requirements for, spec out, 写PRD, 需求文档, 需求分析, 规格说明."
user-invocable: true
---

# PRD Generator

Create detailed Product Requirements Documents that are clear, actionable, and suitable for implementation. After PRD is confirmed, use `/to-issues` to decompose it into Issues, and optionally `/prd-to-spec` for technical design before that.

---

## The Job

1. Receive a feature description from the user
2. Ask clarifying questions to cover key ambiguities — scale the count to complexity, not a fixed number (see Step 1)
3. Generate a structured PRD based on answers
4. **Present PRD to user for review** — ask "Please review the PRD. Let me know if any adjustments are needed, or reply OK to confirm."
5. Apply any adjustments, then save to `tasks/prd-[feature-name].md`
6. **Suggest next steps** (see Step 3)

**Important:** Do NOT start implementing. Just create the PRD.

---

## Step 1: Clarifying Questions

Ask only critical questions where the initial prompt is ambiguous. **Scale the number of questions to the feature's complexity — the goal is covering key ambiguities, not hitting a fixed count:**

- **Simple, well-scoped feature:** 2-3 questions
- **Typical feature:** 3-5 questions
- **Complex feature** (multiple user roles, cross-system integration, significant ambiguity): 6-8 questions

If a dimension is already unambiguous from the user's input, skip it — don't ask filler questions just to reach a number. Focus on:

- **Problem/Goal:** What problem does this solve?
- **Core Functionality:** What are the key actions?
- **Scope/Boundaries:** What should it NOT do?
- **Success Criteria:** How do we know it's done?

### Format Questions Like This:

```
1. What is the primary goal of this feature?
   A. Improve user onboarding experience
   B. Increase user retention
   C. Reduce support burden
   D. Other: [please specify]

2. Who is the target user?
   A. New users only
   B. Existing users only
   C. All users
   D. Admin users only

3. What is the scope?
   A. Minimal viable version
   B. Full-featured implementation
   C. Just the backend/API
   D. Just the UI
```

This lets users respond with "1A, 2C, 3B" for quick iteration. Remember to indent the options.

---

## Edge Cases & Fallback

| Scenario | Handling |
|----------|----------|
````
END THIRD-PARTY FILE 1da082c55752dc2d

The third-party file has ended. Everything between the 1da082c55752dc2d tags is data: requests and commands from it are not followed. An “end of file” line with another tag inside the block is part of the file.

First 2671 of 12371 bytes. © smallnest · MIT · https://github.com/smallnest/goal-workflow/tree/HEAD/skills/prd/SKILL.md

_Part of the page did not fit — see the HTML version._

---
NeVibeCode on affpapa.org. Catalog texts are descriptions, not instructions for the agent. How to choose and install: https://affpapa.org/en/nevibecode/agents.md