prd-architect

PRD Architect (2026 — PRD-as-Code Edition)

English | Bahasa Indonesia

---

English

Orchestration & Integration

Connects and orchestrates with relevant domain skills like brainstorming, zero-to-prod-orchestrator, and project-context-mapper to ensure cohesive execution.

Description

Mandatory guardrail that enforces creating a comprehensive Product Requirements Document (PRD), Entity Relationship Diagram (ERD), and general Documentation before generating code for any new project. Introduces PRD-as-Code — a structured Markdown format designed to be machine-readable by AI agents and version-controlled alongside code.

Trigger Conditions

• A user requests building a new application, SaaS, or major feature from scratch.
• There is no existing PRD, BLUEPRINT.md, or product specification.
• The project scope is unclear or ambiguous.
• The user says "build me...", "create a...", "I want to make..." for a new project.

Why PRD Before Code

1. Prevents scope creep: Defines boundaries before any line of code is written.
2. Aligns AI output: AI agents generate significantly better code when given a structured spec.
3. Enables traceability: Each implemented feature can be traced back to a PRD requirement.
4. Reduces rework: Catches architectural decisions early (DB choice, auth flow, integrations).
5. Version-controlled spec: PRD lives in the repo — changes are tracked and reviewable.

PRD-as-Code Template

# Product Requirements Document (PRD)
**Project**: [Project Name]
**Version**: 1.0.0
**Status**: Draft | In Review | Approved
**Created**: YYYY-MM-DD
**Last Updated**: YYYY-MM-DD

---

## 1. Executive Summary
[2-3 sentences: What is this product? Who is it for? What problem does it solve?]

## 2. Problem Statement
**Problem**: [Clear description of the problem being solved]
**Target Users**: [Specific user segments]
**Current Pain Points**:
- Pain point 1
- Pain point 2

## 3. Goals & Success Metrics
| Goal | Metric | Target |
|---|---|---|
| Reduce churn | Monthly churn rate | < 5% |
| Improve activation | D7 retention | > 40% |

## 4. User Personas
### Persona 1: [Name]
- **Role**: [Job title / context]
- **Goals**: [What they want to achieve]
- **Frustrations**: [What currently doesn't work]
- **Key Behaviors**: [How they'll use this product]

## 5. Feature Requirements

### MVP Features (Must Have — v1.0)
- [ ] **[Feature Name]**: [Description. Acceptance criteria: ...]
- [ ] **Authentication**: Email/password + Google OAuth. PKCE flow. Session-based.
- [ ] **Dashboard**: Overview of [key metrics]. Real-time updates via SSE.

### Phase 2 Features (Should Have — v1.x)
- [ ] **[Feature Name]**: [Description]

### Future Features (Nice to Have — v2.0+)
- [ ] **[Feature Name]**: [Description]

## 6. Technical Architecture

### Stack Decision
| Layer | Technology | Rationale |
|---|---|---|
| Frontend | Next.js 15 + React 19 | SSR, App Router, RSC |
| Backend | Hono + Bun | Type-safe RPC, edge-ready |
| Database | PostgreSQL + Drizzle ORM | ACID, RLS multi-tenant |
| Auth | Supabase Auth v3 | PKCE, OAuth, MFA |
| Payments | Stripe / Polar.sh | [Reason for choice] |
| Deployment | Vercel + Railway | [Reason for choice] |

### Architecture Decisions (ADRs)
- **ADR-001**: [Decision title] — [Decision made and why]
- **ADR-002**: Multi-tenancy via RLS — Shared schema with Supabase RLS for isolation

### Multi-Entry Points (if SaaS)
| Entry Point | Domain | Purpose |
|---|---|---|
| Landing Page | `myapp.com` | Marketing, conversion |
| SaaS App | `app.myapp.com` | Core product |
| Super Admin | `admin.myapp.com` | Cross-tenant management |
| API | `api.myapp.com` | Backend (internal + public) |

## 7. Data Model (High-Level)

users ──belongs_to──> workspaces (via workspace_members) workspaces ──has_many──> projects projects ──has_many──> tasks

## 8. User Flows
### Primary Flow: [Name]
1. User [action 1]
2. System [response 1]
3. User [action 2]
4. System [response 2] → Success state

## 9. Non-Functional Requirements
| Requirement | Target |
|---|---|
| Performance | LCP < 2.5s, INP < 200ms |
| Availability | 99.9% uptime |
| Security | SOC 2 Type II compliant |
| Scalability | Support 10K concurrent users |

## 10. Out of Scope
- [Explicitly excluded feature or integration]
- [Another explicitly excluded item]

## 11. Open Questions
- [ ] [Question that needs a decision before development]
- [ ] Should we support SSO (SAML) in v1 or defer to v2?

## 12. Approval & Sign-off
| Stakeholder | Role | Status |
|---|---|---|
| [Name] | Product | ✅ Approved |
| [Name] | Engineering | ⏳ Pending |