WHAT — Draft and review a Product Requirements Document (PRD) using the template. Business-level
Scanned 9/2/2026
Install to Claude Code
npx -y skills add ulises-jeremias/agent-toolkit --skill prd --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Prd?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/ulises-jeremias-prd)More formats (shields.io, HTML) on the badges page.
---
name: prd
description: WHAT — Draft and review a Product Requirements Document (PRD) using the template. Business-level
requirements, acceptance criteria, and traceability. Does not replace the product owner. English for
tickets, PRs, and client-facing text unless the user asks otherwise.
origin:
type: first-party
---
# PRD — Product Requirements (WHAT)
**Template:** `references/default-template.md` — local reference, kept up to date with the standard structure.
## Default guardrails (before any final content)
1. Apply **`output-handshake`**: confirm **where** the final PRD will be stored (path, Doc page, task, paste-only, etc.) and that a **human** will review. Engagements may store PRDs in different places; do not assume.
2. Then follow the steps below.
## When to use
- A feature or product increment needs a **shared agreement** on scope, users, and acceptance.
- The team must **trace** work from PRD → implementation → tests.
- An engagement uses an **Operations**-style doc hub with linked requirements documents.
## Instructions
1. **Open the PRD template** (`references/default-template.md`) and keep section headings **aligned** with it: Objective, User flow / Personas, Entities & use cases, Acceptance criteria, Edge cases, Integrations, Timeline, Approvals.
2. For **discovery** in an existing repository, delegate repository inspection to **`assistant`**; cite `AGENTS.md` and test/lint commands from the project.
3. **Acceptance criteria** must be testable and in **English** for work items/PRs (match `workflow-generic-project`).
4. Link **stakeholder approval** to your engagement process (task lists, doc pages, or client sign-off). Do not invent sign-off if not agreed.
5. For **ticket updates**, use the appropriate tool (`clickup-cli`, `jira-*`, etc.) to post a short plan comment or attach links — do not paste the full document into a task; link the Doc or page when possible.
## What not to do
- Do not copy the full text of an external template into this skill; use `references/default-template.md` as the local canonical reference.
- Do not skip **edge cases** or **integrations** when the PRD is meant for handoff to a TRD.
## References
- `output-handshake` — destination and review (required first for final output)
- `references/default-template.md` — local PRD template
- `references/example-unified-api.md` — PRD example for an API strategy initiative
- `workflow-generic-project` — delivery phases and ticket traceability
- `trd` — next step for technical design from an approved PRD
- `planning` — estimation and capacity before commitment
- `epic`, `user-story`, `task` — downstream breakdown
- `clickup-cli`, `jira-*` — ticket / comment operations (per engagement)

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!