/prd
Generate high-quality Product Requirements Documents (PRDs) for software systems and AI-powered features. Includes executive summaries, user stories, technical specifications, and risk analysis.
$ npx -y skills add julianromli/ai-skills --skill prd --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/prd
Context preview
The summary Claude sees to decide when to auto-load this skill.
Generate high-quality Product Requirements Documents (PRDs) for software systems and AI-powered features. Includes executive summaries, user stories, technical specifications, and risk analysis.
SKILL.md
prd.SKILL.mdname: prd
description: 'Generate high-quality Product Requirements Documents (PRDs) for software systems and AI-powered features. Includes executive summaries, user stories, technical specifications, and risk analysis.'
license: MIT
Product Requirements Document (PRD)
Overview
Design comprehensive, production-grade Product Requirements Documents (PRDs) that bridge the gap between business vision and technical execution. This skill works for modern software systems, ensuring that requirements are clearly defined.
When to Use
Use this skill when:
- Starting a new product or feature development cycle
- Translating a vague idea into a concrete technical specification
- Defining requirements for AI-powered features
- Stakeholders need a unified "source of truth" for project scope
- User asks to "write a PRD", "document requirements", or "plan a feature"
---
Operational Workflow
Phase 1: Discovery (The Interview)
Before writing a single line of the PRD, you **MUST** interrogate the user to fill knowledge gaps. Do not assume context.
**Ask about:**
- **The Core Problem**: Why are we building this now?
- **Success Metrics**: How do we know it worked?
- **Constraints**: Budget, tech stack, or deadline?
Phase 2: Analysis & Scoping
Synthesize the user's input. Identify dependencies and hidden complexities.
- Map out the **User Flow**.
- Define **Non-Goals** to protect the timeline.
Phase 3: Technical Drafting
Generate the document using the **Strict PRD Schema** below.
---
PRD Quality Standards
Requirements Quality
Use concrete, measurable criteria. Avoid "fast", "easy", or "intuitive".
# Vague (BAD)
- The search should be fast and return relevant results.
- The UI must look modern and be easy to use.
# Concrete (GOOD)
+ The search must return results within 200ms for a 10k record dataset.
+ The search algorithm must achieve >= 85% Precision@10 in benchmark evals.
+ The UI must follow the 'Vercel/Next.js' design system and achieve 100% Lighthouse Accessibility score.
---
Strict PRD Schema
You **MUST** follow this exact structure for the output:
1. Executive Summary
- **Problem Statement**: 1-2 sentences on the pain point.
- **Proposed Solution**: 1-2 sentences on the fix.
- **Success Criteria**: 3-5 measurable KPIs.
2. User Experience & Functionality
- **User Personas**: Who is this for?
- **User Stories**: `As a [user], I want to [action] so that [benefit].`
- **Acceptance Criteria**: Bulleted list of "Done" definitions for each story.
- **Non-Goals**: What are we NOT building?
3. AI System Requirements (If Applicable)
- **Tool Requirements**: What tools and APIs are needed?
- **Evaluation Strategy**: How to measure output quality and accuracy.
4. Technical Specifications
- **Architecture Overview**: Data flow and component interaction.
- **Integration Points**: APIs, DBs, and Auth.
- **Security & Privacy**: Data handling and compliance.
5. Risks & Roadmap
- **Phased Rollout**: MVP -> v1.1 -> v2.0.
- **Technical Risks**: Latency, cost, or dependency failures.
---
Implementation Guidelines
DO (Always)
- **Define Testing**: For AI systems, specify how to test and validate output quality.
- **Iterate**: Present a draft and ask for feedback on specific sections.
DON'T (Avoid)
- **Skip Discovery**: Never write a PRD without asking at least 2 clarifying questions first.
- **Hallucinate Constraints**: If the user didn't specify a tech stack, ask or label it as `TBD`.
---
Example: Intelligent Search System
1. Executive Summary
**Problem**: Users struggle to find specific documentation snippets in massive repositories. **Solution**: An intelligent search system that provides direct answers with source citations. **Success**:
- Reduce search time by 50%.
- Citation accuracy >= 95%.
2. User Stories
- **Story**: As a developer, I want to ask natural language questions so I don't have to guess keywords.
- **AC**:
- Supports multi-turn clarification.
- Returns code blocks with "Copy" button.
3. AI System Architecture
- **Tools Required**: `codesearch`, `grep`, `webfetch`.
4. Evaluation
- **Benchmark**: Test with 50 common developer questions.
- **Pass Rate**: 90% must match expected citations.
Read more
name: prd description: 'Generate high-quality Product Requirements Documents (PRDs) for software systems and AI-powered features. Includes executive summaries, user stories, technical specifications, and risk analysis.' license: MIT
Product Requirements Document (PRD)
Overview
Design comprehensive, production-grade Product Requirements Documents (PRDs) that bridge the gap between business vision and technical execution. This skill works for modern software systems, ensuring that requirements are clearly defined.
When to Use
Use this skill when:
- Starting a new product or feature development cycle
- Translating a vague idea into a concrete technical specification
- Defining requirements for AI-powered features
- Stakeholders need a unified "source of truth" for project scope
- User asks to "write a PRD", "document requirements", or "plan a feature"
---
Operational Workflow
Phase 1: Discovery (The Interview)
Before writing a single line of the PRD, you **MUST** interrogate the user to fill knowledge gaps. Do not assume context.
**Ask about:**
- **The Core Problem**: Why are we building this now?
- **Success Metrics**: How do we know it worked?
- **Constraints**: Budget, tech stack, or deadline?
Phase 2: Analysis & Scoping
Synthesize the user's input. Identify dependencies and hidden complexities.
- Map out the **User Flow**.
- Define **Non-Goals** to protect the timeline.
Phase 3: Technical Drafting
Generate the document using the **Strict PRD Schema** below.
---
PRD Quality Standards
Requirements Quality
Use concrete, measurable criteria. Avoid "fast", "easy", or "intuitive".
# Vague (BAD) - The search should be fast and return relevant results. - The UI must look modern and be easy to use. # Concrete (GOOD) + The search must return results within 200ms for a 10k record dataset. + The search algorithm must achieve >= 85% Precision@10 in benchmark evals. + The UI must follow the 'Vercel/Next.js' design system and achieve 100% Lighthouse Accessibility score.
---
Strict PRD Schema
You **MUST** follow this exact structure for the output:
1. Executive Summary
- **Problem Statement**: 1-2 sentences on the pain point.
- **Proposed Solution**: 1-2 sentences on the fix.
- **Success Criteria**: 3-5 measurable KPIs.
2. User Experience & Functionality
- **User Personas**: Who is this for?
- **User Stories**: `As a [user], I want to [action] so that [benefit].`
- **Acceptance Criteria**: Bulleted list of "Done" definitions for each story.
- **Non-Goals**: What are we NOT building?
3. AI System Requirements (If Applicable)
- **Tool Requirements**: What tools and APIs are needed?
- **Evaluation Strategy**: How to measure output quality and accuracy.
4. Technical Specifications
- **Architecture Overview**: Data flow and component interaction.
- **Integration Points**: APIs, DBs, and Auth.
- **Security & Privacy**: Data handling and compliance.
5. Risks & Roadmap
- **Phased Rollout**: MVP -> v1.1 -> v2.0.
- **Technical Risks**: Latency, cost, or dependency failures.
---
Implementation Guidelines
DO (Always)
- **Define Testing**: For AI systems, specify how to test and validate output quality.
- **Iterate**: Present a draft and ask for feedback on specific sections.
DON'T (Avoid)
- **Skip Discovery**: Never write a PRD without asking at least 2 clarifying questions first.
- **Hallucinate Constraints**: If the user didn't specify a tech stack, ask or label it as `TBD`.
---
Example: Intelligent Search System
1. Executive Summary
**Problem**: Users struggle to find specific documentation snippets in massive repositories. **Solution**: An intelligent search system that provides direct answers with source citations. **Success**:
- Reduce search time by 50%.
- Citation accuracy >= 95%.
2. User Stories
- **Story**: As a developer, I want to ask natural language questions so I don't have to guess keywords.
- **AC**:
- Supports multi-turn clarification.
- Returns code blocks with "Copy" button.
3. AI System Architecture
- **Tools Required**: `codesearch`, `grep`, `webfetch`.
4. Evaluation
- **Benchmark**: Test with 50 common developer questions.
- **Pass Rate**: 90% must match expected citations.
A curated collection of AI agent skills for coding, frontend, debugging, product thinking, and workflow automation.
Repo: julianromli/ai-skills
Other skills on ai-skills.
- /agent-browser
Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a
Open skill - /brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Open skill - /clone-website
Reverse-engineer and clone one or more websites in one shot — extracts assets, CSS, and content section-by-section and proactively dispatches parallel builder agents in worktrees as it goes. Use this whenever the user wants to clone, replicate, rebuild, reverse-engineer, or copy
Open skill - /composition-patterns
Composition patterns for building flexible, maintainable React components. Avoid boolean prop proliferation by using compound components, lifting state, and composing internals. These patterns make codebases easier for both humans and AI agents to work with as they scale.
Open skill - /convex-best-practices
Guidelines for building production-ready Convex apps covering function organization, query patterns, validation, TypeScript usage, error handling, and the Zen of Convex design philosophy
Open skill - /deploy-to-vercel
Deploy applications and websites to Vercel. Use when the user requests deployment actions like "deploy my app", "deploy and give me the link", "push this live", or "create a preview deployment".
Open skill

