vibes-plug 1.0.0

package/skills/payment-gateway-expert/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: payment-gateway-expert
+description: "Expert guide for integrating payment gateways (Stripe, PayPal, Xendit, Midtrans, DOKU) and secure webhooks into SaaS platforms / Panduan ahli integrasi payment gateway dan webhook aman."
+author: "Antigravity"
+---
+
+# Payment Gateway Expert / Ahli Payment Gateway
+
+[English](#english) | [Bahasa Indonesia](#bahasa-indonesia)
+
+---
+
+<a name="english"></a>
+## English
+
+### Description
+Expert guide for integrating major payment gateways (Stripe, PayPal, Xendit, Midtrans, DOKU) into modern SaaS platforms. Covers checkout flows, secure webhook handling, subscription management, and synchronization with local databases.
+
+### Instructions
+- **Security First**: Always validate webhook signatures before processing any payment event. Never trust client-side data for prices or payment status. For DOKU, ensure signature components (like request target) are arranged strictly according to documentation.
+- **Idempotency**: Implement idempotency keys for all payment creation requests to avoid duplicate charges. Webhook handlers must also be idempotent. For DOKU, include a unique `Request-Id` header.
+- **State Synchronization**: Ensure the local database (e.g., PostgreSQL, Supabase) is updated immediately and transactionally upon receiving successful webhook events.
+- **Subscription Management**: Map the provider's subscription statuses (e.g., `active`, `past_due`, `canceled`) accurately to the SaaS platform's internal state machine.
+- **Testing**: Use sandbox/test environments provided by the gateways and simulate webhooks using CLI tools (like Stripe CLI) during development.
+
+### Trigger Conditions
+Active whenever the user is working on billing integration, payment checkout, webhook handling, or integrating platforms like PayPal, Stripe, Xendit, Midtrans, or DOKU.
+
+---
+
+<a name="bahasa-indonesia"></a>
+## Bahasa Indonesia
+
+### Deskripsi
+Panduan ahli untuk mengintegrasikan payment gateway utama (Stripe, PayPal, Xendit, Midtrans, DOKU) ke platform SaaS modern. Mencakup alur checkout, penanganan webhook yang aman, manajemen langganan, dan sinkronisasi dengan database lokal.
+
+### Instruksi
+- **Keamanan Utama**: Selalu validasi signature webhook sebelum memproses event pembayaran apa pun. Jangan pernah mempercayai data dari sisi klien untuk harga atau status pembayaran. Untuk DOKU, pastikan komponen signature (seperti request target) disusun secara ketat sesuai dokumentasi.
+- **Idempotensi**: Implementasikan kunci idempotensi (idempotency keys) untuk semua permintaan pembuatan pembayaran untuk menghindari tagihan ganda. Handler webhook juga harus idempoten. Untuk DOKU, sertakan header `Request-Id` unik.
+- **Sinkronisasi State**: Pastikan database lokal (misal: PostgreSQL, Supabase) diperbarui secara langsung dan transaksional saat menerima event webhook yang berhasil.
+- **Manajemen Langganan**: Petakan status langganan dari provider (misal: `active`, `past_due`, `canceled`) secara akurat ke state machine internal platform SaaS.
+- **Pengujian**: Gunakan lingkungan sandbox/test yang disediakan oleh gateway dan simulasikan webhook menggunakan tool CLI (seperti Stripe CLI) selama pengembangan.
+
+### Kondisi Pemicu
+Aktif setiap kali pengguna sedang mengerjakan integrasi billing, checkout pembayaran, penanganan webhook, atau mengintegrasikan platform seperti PayPal, Stripe, Xendit, Midtrans, atau DOKU.

package/skills/performance-web-vitals/SKILL.md

@@ -0,0 +1,332 @@
+---
+name: performance-web-vitals
+description: "Expert guide for Web Performance optimization: Core Web Vitals (LCP, INP, CLS), bundle analysis, image optimization, rendering strategies, and Lighthouse score improvement / Panduan ahli untuk optimasi performa web: Core Web Vitals (LCP, INP, CLS), analisis bundle, optimasi gambar, strategi rendering, dan peningkatan skor Lighthouse."
+author: "Roedy Rustam"
+---
+
+# Web Performance & Core Web Vitals Expert
+
+[English](#english) | [Bahasa Indonesia](#bahasa-indonesia)
+
+---
+
+<a name="english"></a>
+## English
+
+### Description
+Expert guide for measuring, diagnosing, and optimizing web application performance with a focus on **Core Web Vitals** (LCP, INP, CLS), JavaScript bundle optimization, image and font loading strategies, rendering performance, and achieving high Lighthouse scores. Covers Next.js 15, React 19, and modern browser APIs.
+
+### Trigger Conditions
+- Improving Lighthouse performance score below 90.
+- Diagnosing poor LCP, INP, or CLS metrics.
+- Reducing JavaScript bundle size or eliminating render-blocking resources.
+- Optimizing image loading, lazy loading, or font delivery.
+- Implementing React performance patterns (memo, useDeferredValue, Suspense).
+- Setting up Real User Monitoring (RUM) for Core Web Vitals.
+- Optimizing server response times (TTFB).
+
+---
+
+### Core Web Vitals Targets (2024+)
+
+| Metric | Good | Needs Improvement | Poor | Measures |
+|---|---|---|---|---|
+| **LCP** (Largest Contentful Paint) | ≤ 2.5s | 2.5–4.0s | > 4.0s | Loading performance |
+| **INP** (Interaction to Next Paint) | ≤ 200ms | 200–500ms | > 500ms | Interactivity (replaced FID) |
+| **CLS** (Cumulative Layout Shift) | ≤ 0.1 | 0.1–0.25 | > 0.25 | Visual stability |
+| **FCP** (First Contentful Paint) | ≤ 1.8s | 1.8–3.0s | > 3.0s | Perceived loading |
+| **TTFB** (Time to First Byte) | ≤ 800ms | 800–1800ms | > 1800ms | Server responsiveness |
+
+---
+
+### LCP Optimization Strategies
+
+#### 1. Identify and Optimize the LCP Element
+```typescript
+// Measure LCP with web-vitals library
+import { onLCP, onINP, onCLS } from 'web-vitals';
+
+onLCP((metric) => {
+  console.log('LCP:', metric.value, 'element:', metric.attribution.lcpEntry?.element);
+  // Send to analytics
+  sendToAnalytics({ name: metric.name, value: metric.value });
+});
+```
+
+#### 2. Preload LCP Image (Hero Image)
+```html
+<!-- In <head> — preload the hero image before CSS blocks it -->
+<link rel="preload" as="image" href="/hero.webp"
+      imagesrcset="/hero-480.webp 480w, /hero-800.webp 800w"
+      imagesizes="(max-width: 600px) 480px, 800px"
+      fetchpriority="high">
+```
+
+#### 3. Next.js Image Component (LCP Hero)
+```tsx
+import Image from 'next/image';
+
+// LCP image: priority=true + fill or explicit size
+<Image
+  src="/hero.webp"
+  alt="Hero banner"
+  width={1200}
+  height={600}
+  priority           // disables lazy loading, adds preload link
+  fetchPriority="high"
+  quality={85}
+  sizes="(max-width: 768px) 100vw, 1200px"
+/>
+
+// Below-the-fold images: lazy load (default)
+<Image
+  src="/product.webp"
+  alt="Product"
+  width={400}
+  height={300}
+  // loading="lazy" is the default — no need to specify
+/>
+```
+
+---
+
+### INP Optimization Strategies
+
+#### 1. Break Up Long Tasks
+```typescript
+// BAD: Long synchronous task blocks the main thread
+function processLargeList(items: Item[]) {
+  return items.map(expensiveTransform); // blocks for 500ms
+}
+
+// GOOD: Yield control back to browser between chunks
+async function processLargeListAsync(items: Item[]) {
+  const results: Result[] = [];
+  for (let i = 0; i < items.length; i++) {
+    results.push(expensiveTransform(items[i]));
+    if (i % 50 === 0) await scheduler.yield(); // yield every 50 items
+  }
+  return results;
+}
+```
+
+#### 2. React 19 — Concurrent Features for INP
+```tsx
+import { useTransition, useDeferredValue, startTransition } from 'react';
+
+// Non-urgent state updates — mark as transitions
+function SearchResults() {
+  const [query, setQuery] = useState('');
+  const [isPending, startTransition] = useTransition();
+  const deferredQuery = useDeferredValue(query);
+
+  return (
+    <>
+      <input
+        value={query}
+        onChange={(e) => {
+          setQuery(e.target.value); // urgent: update input immediately
+          startTransition(() => {
+            // non-urgent: defer expensive filtering
+          });
+        }}
+      />
+      {isPending && <Spinner />}
+      {/* deferredQuery triggers re-render without blocking input */}
+      <ResultsList query={deferredQuery} />
+    </>
+  );
+}
+```
+
+#### 3. Virtualize Long Lists
+```tsx
+// Use TanStack Virtual for large lists (1000+ items)
+import { useVirtualizer } from '@tanstack/react-virtual';
+
+function VirtualList({ items }: { items: Item[] }) {
+  const parentRef = useRef<HTMLDivElement>(null);
+  const virtualizer = useVirtualizer({
+    count: items.length,
+    getScrollElement: () => parentRef.current,
+    estimateSize: () => 60, // estimated row height in px
+    overscan: 5,
+  });
+
+  return (
+    <div ref={parentRef} style={{ height: '600px', overflow: 'auto' }}>
+      <div style={{ height: virtualizer.getTotalSize() }}>
+        {virtualizer.getVirtualItems().map((vItem) => (
+          <div
+            key={vItem.key}
+            style={{ position: 'absolute', top: vItem.start, height: vItem.size }}
+          >
+            <ItemRow item={items[vItem.index]} />
+          </div>
+        ))}
+      </div>
+    </div>
+  );
+}
+```
+
+---
+
+### CLS Optimization Strategies
+
+```css
+/* 1. Reserve space for images with aspect-ratio */
+img, video {
+  width: 100%;
+  height: auto;
+  aspect-ratio: 16 / 9; /* prevents layout shift before load */
+}
+
+/* 2. Reserve space for dynamic content */
+.ad-container {
+  min-height: 250px; /* reserve ad slot height */
+}
+
+/* 3. Use font-display: optional or swap */
+@font-face {
+  font-family: 'Inter';
+  src: url('/fonts/inter.woff2') format('woff2');
+  font-display: optional; /* no invisible text, no layout shift */
+}
+```
+
+```tsx
+// 4. Avoid inserting content above existing content
+// BAD: inserting notification banner at top pushes content down
+setShowBanner(true); // causes CLS
+
+// GOOD: use position:fixed or reserve space at the top
+<div className="h-12">{showBanner && <Banner />}</div>
+```
+
+---
+
+### Bundle Optimization
+
+#### Next.js Bundle Analysis
+```bash
+# Analyze bundle composition
+ANALYZE=true npm run build
+# Or use @next/bundle-analyzer
+```
+
+#### Code Splitting Patterns
+```tsx
+import dynamic from 'next/dynamic';
+
+// Dynamic import — code splits automatically
+const HeavyChart = dynamic(() => import('@/components/HeavyChart'), {
+  loading: () => <ChartSkeleton />,
+  ssr: false, // disable SSR for client-only components
+});
+
+// Lazy load with React.lazy (non-Next.js)
+const Modal = React.lazy(() => import('./Modal'));
+```
+
+#### Tree-shaking Checklist
+- Use named imports: `import { debounce } from 'lodash-es'` (not `import _ from 'lodash'`)
+- Set `"sideEffects": false` in `package.json` for libraries.
+- Avoid `import *` from large libraries.
+- Replace `moment.js` with `date-fns` or `dayjs`.
+- Use `sharp` for server-side image processing.
+
+---
+
+### React Performance Patterns
+
+```tsx
+// memo — skip re-render if props didn't change
+const ExpensiveList = memo(({ items }: { items: Item[] }) => (
+  <ul>{items.map((i) => <li key={i.id}>{i.name}</li>)}</ul>
+));
+
+// useCallback — stable function reference for memo children
+const handleDelete = useCallback((id: string) => {
+  setItems((prev) => prev.filter((i) => i.id !== id));
+}, []); // empty deps = stable reference
+
+// useMemo — memoize expensive calculations
+const sortedItems = useMemo(
+  () => [...items].sort((a, b) => a.name.localeCompare(b.name)),
+  [items]
+);
+```
+
+---
+
+### Performance Monitoring Setup
+
+```typescript
+// report-vitals.ts — send Core Web Vitals to analytics
+import { onCLS, onINP, onLCP, onFCP, onTTFB } from 'web-vitals';
+
+function sendToAnalytics({ name, value, id, navigationType }: Metric) {
+  // Send to PostHog, Google Analytics, or your own endpoint
+  fetch('/api/analytics/vitals', {
+    method: 'POST',
+    body: JSON.stringify({ name, value: Math.round(value), id, navigationType }),
+    keepalive: true, // ensures request completes even if page unloads
+  });
+}
+
+onCLS(sendToAnalytics);
+onINP(sendToAnalytics);
+onLCP(sendToAnalytics);
+onFCP(sendToAnalytics);
+onTTFB(sendToAnalytics);
+```
+
+---
+
+### Lighthouse Score Improvement Checklist
+
+- [ ] LCP image has `priority` or `fetchpriority="high"` + preload link.
+- [ ] All non-LCP images use `loading="lazy"`.
+- [ ] Fonts loaded with `font-display: optional` or preloaded with `rel="preload"`.
+- [ ] No render-blocking `<script>` tags without `defer` or `async`.
+- [ ] Bundle size < 200KB gzipped for initial JS.
+- [ ] Images served in WebP/AVIF format with `srcset`.
+- [ ] Server response time (TTFB) < 600ms — use CDN edge caching.
+- [ ] Long tasks (> 50ms) are broken up or deferred.
+- [ ] Virtual lists used for > 100 items.
+- [ ] Unused CSS removed (PurgeCSS / Tailwind purge).
+- [ ] HTTP/2 or HTTP/3 enabled on server.
+- [ ] Resource hints: `dns-prefetch`, `preconnect` for third-party origins.
+
+---
+
+<a name="bahasa-indonesia"></a>
+## Bahasa Indonesia
+
+### Deskripsi
+Panduan ahli untuk mengukur, mendiagnosis, dan mengoptimalkan performa aplikasi web dengan fokus pada **Core Web Vitals** (LCP, INP, CLS), optimasi JavaScript bundle, strategi loading gambar dan font, performa rendering, dan mencapai skor Lighthouse yang tinggi.
+
+### Kondisi Pemicu
+- Meningkatkan skor Lighthouse di bawah 90.
+- Mendiagnosis metrik LCP, INP, atau CLS yang buruk.
+- Mengurangi ukuran JavaScript bundle atau menghilangkan resource yang memblokir render.
+- Mengoptimalkan loading gambar, lazy loading, atau pengiriman font.
+- Mengimplementasikan pola performa React (memo, useDeferredValue, Suspense).
+- Menyiapkan Real User Monitoring (RUM) untuk Core Web Vitals.
+
+### Target Core Web Vitals
+
+| Metrik | Baik | Perlu Perbaikan | Buruk |
+|---|---|---|---|
+| **LCP** | ≤ 2,5 detik | 2,5–4,0 detik | > 4,0 detik |
+| **INP** | ≤ 200ms | 200–500ms | > 500ms |
+| **CLS** | ≤ 0,1 | 0,1–0,25 | > 0,25 |
+
+### Ringkasan Strategi Optimasi
+
+- **LCP**: Preload hero image, gunakan `priority` di Next.js Image, optimalkan TTFB dengan CDN.
+- **INP**: Pecah long task dengan `scheduler.yield()`, gunakan `useTransition` React 19, virtualisasi list panjang.
+- **CLS**: Reservasi ruang untuk gambar dengan `aspect-ratio`, hindari penyisipan konten di atas konten yang sudah ada.
+- **Bundle**: Analisis bundle, gunakan dynamic import, tree-shaking, dan named imports.
+- **Monitoring**: Implementasikan `web-vitals` library untuk melaporkan metrik ke analytics secara real-time.

package/skills/prd-architect/SKILL.md

@@ -0,0 +1,191 @@
+---
+name: prd-architect
+description: "Mandatory guardrail skill that enforces creating a comprehensive Product Requirements Document (PRD) before generating code for new projects / Skill khusus untuk memaksa pembuatan Product Requirements Document (PRD) sebelum mulai coding pada setiap proyek baru."
+author: "Roedy Rustam"
+---
+
+# PRD Architect (2026 — PRD-as-Code Edition)
+
+[English](#english) | [Bahasa Indonesia](#bahasa-indonesia)
+
+---
+
+<a name="english"></a>
+## English
+
+### Description
+Mandatory guardrail that enforces creating a comprehensive Product Requirements Document (PRD) 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
+
+```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 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 |
+```
+
+### Enforcement Protocol
+1. **Detect**: When user requests a new project build.
+2. **Pause**: Do NOT generate any code.
+3. **Generate PRD**: Create a pre-filled PRD draft based on the user's description.
+4. **Review**: Present to user for approval/edits.
+5. **Confirm**: Once PRD is approved, proceed to `zero-to-prod-orchestrator` Phase 1.
+6. **Reference**: Cite the PRD in all subsequent code generation decisions.
+
+---
+
+<a name="bahasa-indonesia"></a>
+## Bahasa Indonesia
+
+### Deskripsi
+Guardrail wajib yang memaksa pembuatan Product Requirements Document (PRD) komprehensif sebelum membuat kode untuk proyek baru apapun. Memperkenalkan **PRD-as-Code** — format Markdown terstruktur yang dirancang agar dapat dibaca mesin oleh agen AI dan dikontrol versi bersama kode.
+
+### Kondisi Pemicu
+- Pengguna meminta membangun aplikasi, SaaS, atau fitur besar baru dari awal.
+- Tidak ada PRD, BLUEPRINT.md, atau spesifikasi produk yang ada.
+- Ruang lingkup proyek tidak jelas atau ambigu.
+- Pengguna berkata "buatkan saya...", "buat sebuah...", "saya ingin membuat..." untuk proyek baru.
+
+### Mengapa PRD Sebelum Kode
+1. **Mencegah scope creep**: Mendefinisikan batas sebelum satu baris kode pun ditulis.
+2. **Menyelaraskan output AI**: Agen AI menghasilkan kode yang jauh lebih baik saat diberi spesifikasi terstruktur.
+3. **Memungkinkan keterlacakan**: Setiap fitur yang diimplementasikan dapat ditelusuri kembali ke persyaratan PRD.
+4. **Mengurangi pengerjaan ulang**: Menangkap keputusan arsitektur lebih awal (pilihan DB, alur auth, integrasi).
+5. **Spesifikasi dengan kontrol versi**: PRD hidup di repo — perubahan dilacak dan dapat ditinjau.
+
+### Template PRD-as-Code
+Template PRD mencakup 12 bagian:
+1. **Ringkasan Eksekutif**: Apa produk ini, untuk siapa, masalah apa yang diselesaikan.
+2. **Pernyataan Masalah**: Deskripsi masalah yang jelas dengan persona pengguna target.
+3. **Tujuan & Metrik Keberhasilan**: Target terukur yang terkait dengan tujuan bisnis.
+4. **Persona Pengguna**: Peran, tujuan, frustrasi, dan perilaku kunci.
+5. **Persyaratan Fitur**: MVP (Harus Ada), Fase 2 (Sebaiknya Ada), Masa Depan (Bagus Dimiliki).
+6. **Arsitektur Teknis**: Keputusan stack dengan justifikasi, ADR, multi-entry points.
+7. **Model Data**: Hubungan antar entitas tingkat tinggi.
+8. **Alur Pengguna**: Alur langkah-demi-langkah untuk interaksi utama.
+9. **Persyaratan Non-Fungsional**: Performa, ketersediaan, keamanan, skalabilitas.
+10. **Di Luar Ruang Lingkup**: Apa yang secara eksplisit dikecualikan.
+11. **Pertanyaan Terbuka**: Keputusan yang perlu dibuat sebelum pengembangan.
+12. **Persetujuan**: Pemangku kepentingan dan status tanda tangan.
+
+### Protokol Penegakan
+1. **Deteksi**: Saat pengguna meminta pembangunan proyek baru.
+2. **Jeda**: JANGAN hasilkan kode apapun.
+3. **Buat PRD**: Buat draf PRD yang sudah diisi berdasarkan deskripsi pengguna.
+4. **Tinjau**: Sajikan kepada pengguna untuk persetujuan/edit.
+5. **Konfirmasi**: Setelah PRD disetujui, lanjut ke `zero-to-prod-orchestrator` Fase 1.
+6. **Referensi**: Kutip PRD dalam semua keputusan pembuatan kode selanjutnya.