sandbaseai 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. Resolve the current schema with sandbase_describe_tool before using a listed capability through sandbase_call_tool.
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".
# 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.