| name | prd-architect |
| description | Initial guardrail skill that enforces creating a comprehensive Product Requirements Document (PRD) before generating code. Use whenever the user starts a new project or feature and jumps straight to "build me X" without defined requirements. Trigger on phrases like "build me an app that...", "create a system for...", "I want to build...", or any greenfield request lacking clear scope. Also trigger when the user explicitly asks for a PRD or requirements document.
|
PRD Architect — Requirements Before Code
Guardrail protocol: no significant code generation begins without a clear PRD.
Core Principle
Code written against unclear requirements is technical debt from line one. This skill enforces
a brief but real requirements pass before implementation — proportional to project size, not a
bureaucratic gate for trivial requests.
When This Skill Activates
| Request Type | PRD Needed? |
|---|
| "Build me a SaaS app for X" | ✅ Yes — full PRD |
| "Add a new feature: Y" to existing app | ✅ Yes — lightweight PRD |
| "Fix this bug" | ❌ No — straight to fix |
| "Write a function that does X" | ❌ No — clear, scoped |
| "Refactor this file" | ❌ No — clear, scoped |
| "I want to build a tool that helps people do X" | ✅ Yes — full PRD |
| "Add a button that does Y" | ⚠️ Lightweight — confirm scope only |
Rule of thumb: if the request requires guessing about scope, users, data models, or success
criteria — stop and clarify first. If everything needed to implement correctly is already stated, proceed.
PRD Elicitation Process
Step 1: Identify What's Missing
Before asking questions, check what the user already told you. Don't re-ask for stated info.
Common missing pieces:
- Who is this for? (target user/persona)
- What problem does it solve? (not just what it does)
- Scope boundaries — what's explicitly NOT included in v1?
- Core entities — what data does the system manage?
- Success criteria — how do we know it works?
Step 2: Ask Targeted Questions (Not a Questionnaire Dump)
Ask only what's needed to start. Use the ask_user_input_v0 tool for structured choices when
applicable rather than open-ended prose questions.
❌ Asking 15 questions upfront before any progress
✅ Asking 2-4 high-leverage questions, then proceeding with stated assumptions for the rest
Step 3: Produce the PRD
Generate a structured PRD (template below), then confirm before writing code.
Step 4: Confirm & Proceed
"Here's the PRD based on what you've described. Does this match your intent,
or should I adjust scope before I start building?"
Then proceed to implementation once confirmed (or after one round of revision).
PRD Template (Full)
# [Product/Feature Name] — PRD
**Status**: Draft
**Date**: YYYY-MM-DD
---
## 1. Problem Statement
[1-2 sentences: what problem are we solving, for whom]
## 2. Target Users
| Persona | Description | Primary Need |
|---------|-------------|---------------|
| [Persona 1] | [who they are] | [what they need] |
## 3. Goals
- Goal 1
- Goal 2
## 4. Non-Goals (Explicit Scope Boundaries)
- NOT building X in v1
- NOT supporting Y use case yet
## 5. User Stories
| ID | As a... | I want to... | So that... |
|----|---------|--------------|------------|
| U1 | [user] | [action] | [outcome] |
## 6. Core Entities / Data Model
| Entity | Key Fields | Relationships |
|--------|-----------|----------------|
| User | id, email, name | has many Posts |
| Post | id, title, content, userId | belongs to User |
## 7. Functional Requirements
- [ ] FR1: [specific, testable requirement]
- [ ] FR2: [specific, testable requirement]
## 8. Non-Functional Requirements
- Performance: [e.g., page load < 2s]
- Scale: [e.g., support 1000 concurrent users]
- Security: [e.g., RLS on all tenant data]
## 9. Out of Scope (v1)
- [Explicitly deferred features]
## 10. Success Metrics
- [How we'll know this worked — measurable]
## 11. Open Questions
- [ ] [Anything still unresolved, with owner if applicable]
Lightweight PRD (For Smaller Features)
For features added to an existing system, use a condensed version:
## Feature: [Name]
**Problem**: [1 sentence]
**Solution**: [1-2 sentences]
**In scope**:
- Point 1
- Point 2
**Out of scope**:
- Point 1
**Data changes**: [new fields/tables, or "none"]
**Success looks like**: [1 sentence]
Elicitation Question Bank
Use these as needed — don't ask all of them, pick the highest-leverage 2-4:
Scope & Users
- Who is the primary user of this?
- What's the single most important thing it must do in v1?
- Is there anything you explicitly want to exclude from the first version?
Data
- What are the core "things" this system manages? (e.g., users, orders, posts)
- Does this need to support multiple users/organizations (multi-tenant), or is it single-user?
Constraints
- Any existing stack/tech this needs to fit into?
- Any timeline or "must launch by" constraint?
Success
- How will you know this is working well after launch?
Anti-Patterns to Avoid
❌ Asking 10+ questions before writing anything — kills momentum, frustrates users with clear intent
❌ Skipping PRD for genuinely ambiguous greenfield requests — leads to building the wrong thing
❌ Writing a PRD for a one-line bug fix — disproportionate process for trivial work
❌ Treating the PRD as immutable — it's a starting point, refine as you learn during build
❌ PRD theater — don't pad with boilerplate sections that add no real information for small features
Key Rules
- Scope the PRD to the task size — full template for greenfield products, lightweight for features, none for clear bug fixes/scoped code requests
- Ask the minimum questions needed to start — 2-4 targeted questions, not an exhaustive intake form
- Always include explicit Non-Goals — what's NOT being built is as important as what is
- Core entities/data model before code — prevents costly schema rework later
- Confirm the PRD before implementing — one quick check-in, not a lengthy approval cycle
- PRD is a living document — update it as understanding evolves during implementation
- Don't re-ask what's already been stated — read the request carefully first
- Success metrics must be measurable — "users like it" is not a success metric
