v4.3.0 to v4.3.0

---

name: prd-architect

description: "Updated to cover both pre-code PRD/ERD/Docs generation AND post-code continuous documentation updates / Diperbarui untuk mencakup pembuatan PRD/ERD/Docs pra-kode DAN pembaruan dokumentasi kontinu pasca-kode."

author: "Roedy Rustam"

version: "4.3.0"

---

# PRD Architect & Documentation Lifecycle (2026 Edition)

[English](#english) | [Bahasa Indonesia](#bahasa-indonesia)

---

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

## English

### Orchestration & Integration

Connects with `anti-slop`, `brainstorming`, `zero-to-prod-orchestrator`, `session-memory-manager` to ensure cohesive execution and zero-slop documentation updates.

### 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`, `DOKUMENTASI.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)

```markdown

# 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

| File | Purpose | Update Frequency |

|---|---|---|

| `CHANGELOG.md` | User-facing list of changes | Every PR / feature |

| `BLUEPRINT.md` | Technical architecture overview | Major structural changes |

| `PROGRESS.md` | Development roadmap and status | Each work session |

| `docs/adr/` | Architecture Decision Records | Each key decision |

#### ADR Template

```markdown

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