prd ยท diff
git:20260903.84660c4 to git:20260908.495293d
1 added, 1 removed. Audit A to A.
---
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.'
---
# 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 external product, market, or technical evidence is needed, read [the SandBase API map](references/sandbase-api-map.md). Resolve the current schema with `sandbase_describe_tool` before using a listed capability through `sandbase_call_tool`.
+ When external product, market, or technical evidence is needed, read [the SandBase API map](references/sandbase-api-map.md). Resolve the listed capability with `sandbase_discover`, inspect its returned `name` with `sandbase_inspect`, then follow `execute_as` to call `sandbase_run(name: "<returned name>", arguments: { ... })` using only the current schema. For async results, poll `sandbase_run_get` with the returned `run_id` within the task budget; report pending or failed runs without automatically resubmitting them.
## 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 drafting the PRD, identify material knowledge gaps and ask only for information that cannot be safely inferred or marked `TBD`.
**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".
```diff
# 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**: Do not hide unresolved critical gaps; ask focused questions or mark non-critical unknowns as `TBD`.
- **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**: repository search, text search, and authorized web-retrieval capabilities.
### 4. Evaluation
- **Benchmark**: Test with 50 common developer questions.
- **Pass Rate**: 90% must match expected citations.