prd-architect

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

1. Scope the PRD to the task size — full template for greenfield products, lightweight for features, none for clear bug fixes/scoped code requests
2. Ask the minimum questions needed to start — 2-4 targeted questions, not an exhaustive intake form
3. Always include explicit Non-Goals — what's NOT being built is as important as what is
4. Core entities/data model before code — prevents costly schema rework later
5. Confirm the PRD before implementing — one quick check-in, not a lengthy approval cycle
6. PRD is a living document — update it as understanding evolves during implementation
7. Don't re-ask what's already been stated — read the request carefully first
8. Success metrics must be measurable — "users like it" is not a success metric