# Prd Architect

> 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.

- Skill: `roedyrustam/prd-architect-2` (Agent Skill)
- Install (CLI): `npx skillmds@latest add roedyrustam/prd-architect-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/roedyrustam/prd-architect-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: roedyrustam (https://skillmd.com/u/roedyrustam)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/roedyrustam/prd-architect-2

---


# 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)

```markdown
# [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:

```markdown
## 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