roedyrustam/vibes-plug/prd-architect

PRD Architect & Documentation Lifecycle (2026 Edition)

English | Bahasa Indonesia

<a name="english"></a>

English

Orchestration & Integration

• Upstream Orchestrators: Works under brainstorming and zero-to-prod-orchestrator (Phase 1 - Discovery & PRD, and Phase 8 - Docs Handoff) as the primary specification guardrail.
• Downstream Cooperating Skills:
• spec-driven-development-expert — Convert PRD requirements into executable OpenAPI and TypeSpec contracts.
• domain-driven-design-expert — Model domain bounded contexts and ubiquitous language in PRD sections.
• session-memory-manager — Ground session memory on approved PRD/ERD specifications and ADR records.
• anti-slop — Enforce concrete DDL schemas, verifiable NFR targets, and zero marketing buzzwords.
• production-ready-hardener — Audit documentation completeness before final release.
• documentation-site-expert — Publish approved PRD, API references, and architecture guides to Mintlify, VitePress, or Fumadocs sites.

Description

A mandatory lifecycle guardrail covering two distinct phases:

• Phase 1 (Pre-Code): Enforces creating a comprehensive Product Requirements Document (PRD), ERD, and general Documentation before generating code. Introduces PRD-as-Code — machine-readable and version-controlled.
• Phase 2 (Post-Code / Maintenance): Automatically maintains project documentation after every successful build or feature implementation, updating CHANGELOG.md, BLUEPRINT.md, PROGRESS.md, and Architecture Decision Records (ADRs).

Trigger Conditions

• Phase 1: User requests building a new app/SaaS/feature from scratch; no existing PRD/blueprint; unclear scope.
• Phase 2: A feature, bug fix, or refactor is successfully implemented; user asks to "update docs" or "save progress"; a significant architectural decision is made; milestone completion.

Phase 1: Pre-Code Requirements & Enforcement

Why PRD Before Code: Prevents scope creep, aligns AI output, enables traceability, reduces rework, version-controlled.

Enforcement Protocol

1. Detect: When user requests a new project build.
2. Pause: Do NOT generate any code.
3. Generate Assets (Zero-Slop Standard): Automatically draft PRD.md, ERD.md, DOCUMENTATION.md, and ROADMAP.md (or PROGRESS.md). Enforce anti-slop: zero marketing buzzwords; mandate concrete PostgreSQL DDL schemas, explicit REST/RPC contracts, and verified latency NFR budgets.
4. Review: Present to user for approval/edits.
5. Confirm: Proceed to code generation ONLY after approval.
6. Reference: Cite these documents in all subsequent decisions.

PRD-as-Code Template (12 Sections)

# 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]
**Target Users**: [Specific segments]
**Current Pain Points**: [List]
 
## 3. Goals & Success Metrics
| Goal | Metric | Target |
|---|---|---|
| [Goal] | [Metric] | [Target] |
 
## 4. User Personas
### Persona 1: [Name]
-**Role**: [Job title]
-**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: ...]
### 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 |
|---|---|---|
| [Layer] | [Technology] | [Reason] |
### Architecture Decisions (ADRs)
-**ADR-001**: [Decision title] — [Decision made and why]
### Multi-Entry Points (if SaaS)
| Entry Point | Domain | Purpose |
|---|---|---|
| [Entry] | [Domain] | [Purpose] |
 
## 7. Data Model (High-Level)
users ──belongs_to──> workspaces (via workspace_members)
workspaces ──has_many──> projects
 
## 8. User Flows
### Primary Flow: [Name]
1.User [action 1]
2.System [response 1]
 
## 9. Non-Functional Requirements
| Requirement | Target |
|---|---|
| Performance | LCP < 2.5s, INP < 200ms |
 
## 10. Out of Scope
-[Explicitly excluded item]
 
## 11. Open Questions
-[ ] [Question that needs decision]
 
## 12. Approval & Sign-off
| Stakeholder | Role | Status |
|---|---|---|
| [Name] | [Role] | [Status] |

Phase 2: Post-Code Maintenance & Update Protocol

After every successful feature implementation:

1. CHANGELOG.md: Add entry under [Unreleased] (Keep-a-Changelog standard: Added/Changed/Fixed/Removed/Security).
2. BLUEPRINT.md: Update only if architecture, schema, stack, or entry points changed.
3. PROGRESS.md: Mark completed tasks [x], update next steps.
4. ADR: Create a new ADR (docs/adr/ADR-NNN-title.md) if a significant architectural decision was made and update index (docs/adr/README.md).

Files Maintained Frequency Matrix

ADR Template

# ADR-001: [Title]
**Status**: Accepted | Rejected | Proposed | Deprecated
**Date**: YYYY-MM-DD
**Deciders**: [Team/Individual]
## Context
[What motivated this decision?]
## Decision
[What is being decided?]
## Rationale
[Why this choice?]
## Consequences
**Positive:** / **Negative:**
## Superseded By
[ADR-XXX] (if applicable)

🎨 Automatic Visual Assets Generation Mandate (CRITICAL)

MANDATORY: When building a new application, use generate_image to create a custom logo. Use it as:

1. The primary application logo (header/navbar).
2. The website favicon (favicon.ico).
3. The Open Graph (OG) image for SEO (og:image).

Sovereign Execution, Token Efficiency & Invariants

<a name="bahasa-indonesia"></a>

Bahasa Indonesia

Integrasi Orkestrasi

• Orkestrator Hulu: Beroperasi di bawah arahan brainstorming dan zero-to-prod-orchestrator (Fase 1 - Discovery & PRD, dan Fase 8 - Handoff Dokumen) sebagai guardrail spesifikasi utama.
• Skill Hilir & Kerja Sama:
• spec-driven-development-expert — Mengubah kebutuhan PRD menjadi kontrak executable OpenAPI dan TypeSpec.
• domain-driven-design-expert — Memodelkan bounded context domain dan bahasa terpadu dalam PRD.
• session-memory-manager — Melandaskan memori sesi pada spesifikasi PRD/ERD dan rekaman ADR yang disetujui.
• anti-slop — Menegakkan skema DDL konkret, target NFR terverifikasi, dan bebas buzzword pemasaran.
• production-ready-hardener — Mengaudit kelengkapan dokumentasi sebelum rilis final.

Deskripsi

Guardrail siklus hidup wajib untuk rekayasa perangkat lunak modern:

• Fase 1 (Pra-Kode / Pre-Code): Memaksa perancangan dokumen spesifikasi (PRD, ERD, Dokumentasi, Roadmap) sebelum sebaris kode pun ditulis. Mencegah pemborosan token dan refaktorisasi berulang.
• Fase 2 (Pasca-Kode / Post-Code): Memelihara dokumentasi hidup secara berkelanjutan setelah setiap fitur selesai: CHANGELOG.md, BLUEPRINT.md, PROGRESS.md, dan Architecture Decision Records (docs/adr/).

Kondisi Pemicu (Trigger Conditions)

• Fase 1 (Wajib Aktif):
• Permintaan proyek baru dari nol ("buatkan aplikasi...", "bikin SaaS...").
• Tidak ada berkas PRD di direktori akar repositori.
• Ruang lingkup kebutuhan atau model data belum terdefinisi secara eksplisit.
• Fase 2 (Pemeliharaan Kontinu):
• Suatu fitur atau modul berhasil diimplementasikan dan diverifikasi lolos tes.
• Pengguna meminta "perbarui dokumentasi" atau "catat perubahan ini".
• Keputusan arsitektur besar diambil (migrasi DB, perubahan auth, adopsi library inti).

Mengapa PRD Sebelum Kode (Why PRD Before Code)

1. Mencegah Scope Creep: Membatasi batas fungsional sebelum implementasi.
2. Penyelarasan Konteks AI: Memberikan grounding akurat bagi seluruh subagen swarm.
3. Traceability Penuh: Setiap endpoint API dan tabel DB memiliki justifikasi kebutuhan pengguna.
4. Zero-Slop Standard: Mengeliminasi buzzword pemasaran dan memastikan skema DDL PostgreSQL, kontrak JSON REST/RPC, serta target latensi NFR terukur secara matematis.

Fase 1: Protokol Penegakan 6 Langkah

1. Deteksi (Detect): Kenali instruksi pembuatan proyek baru dari pengguna.
2. Jeda (Pause): JANGAN membuat atau mengedit berkas kode program apa pun.
3. Hasilkan Berkas Spesifikasi (Zero-Slop): Secara otomatis susun draf PRD.md, ERD.md, DOCUMENTATION.md, dan PROGRESS.md.
4. Tinjau (Review): Sajikan draf kepada pengguna untuk validasi dan penyesuaian parameter bisnis.
5. Konfirmasi (Confirm): Mulai penulisan kode sumber HANYA setelah pengguna memberikan persetujuan ("Proceed", "Lanjut", atau perbaikan disetujui).
6. Jadikan Referensi (Reference): Rujuk dokumen PRD ini dalam setiap keputusan arsitektur dan penulisan tes TDD.

Template PRD-as-Code Standar (12 Bagian Lengkap)

# Product Requirements Document (PRD)
**Project**: [Nama Proyek / Aplikasi]
**Versi**: 1.0.0
**Status**: Draft | In Review | Approved
**Dibuat**: YYYY-MM-DD
**Terakhir Diperbarui**: YYYY-MM-DD
 
---
## 1. Ringkasan Eksekutif (Executive Summary)
[2-3 kalimat lugas: Apa produk ini? Siapa target audiensnya? Masalah spesifik apa yang diselesaikan?]
 
## 2. Pernyataan Masalah (Problem Statement)
-**Masalah Utama**: [Deskripsi konkret pain point di dunia nyata]
-**Target Pengguna**: [Segmen persona spesifik]
-**Kelemahan Solusi Saat Ini**: [Daftar inefisiensi atau risiko dari cara lama]
 
## 3. Sasaran & Metrik Keberhasilan (Goals & Success Metrics)
| Sasaran Bisnis / Teknis | Metrik Evaluasi | Target Kuantitatif |
|---|---|---|
| Kecepatan Transaksi | Latensi p95 Checkout | < 250ms |
| Adopsi Pengguna | Monthly Active Users | 5,000 pengguna di Q1 |
| Kestabilan Sistem | Error Rate API | < 0.05% |
 
## 4. Persona Pengguna (User Personas)
### Persona 1: [Nama Karakteristik]
-**Peran**: [Jabatan / Peran Pengguna, misal: Finance Manager]
-**Tujuan Utama**: [Apa hasil yang ingin mereka capai secepat mungkin]
-**Frustrasi Terbesar**: [Halangan yang paling sering mereka hadapi]
-**Pola Interaksi**: [Bagaimana & kapan mereka membuka aplikasi ini]