vibes-plug 1.0.0 → 2.11.0

package/skills/auto-doc-updater/SKILL.md

@@ -1,204 +1,220 @@
----
-name: auto-doc-updater
-description: "Automatically documents every feature change or bug fix successfully built into CHANGELOG.md and BLUEPRINT.md / Otomatis mendokumentasikan setiap perubahan fitur atau perbaikan bug yang berhasil di-build ke CHANGELOG.md dan BLUEPRINT.md."
+---
+name: auto-doc-updater
+description: "Automatically documents every feature change or bug fix successfully built into CHANGELOG.md and BLUEPRINT.md / Otomatis mendokumentasikan setiap perubahan fitur atau perbaikan bug yang berhasil di-build ke CHANGELOG.md dan BLUEPRINT.md."
 author: "Roedy Rustam"
----
-
-# Auto Documentation Updater (2026 — ADR Edition)
-
-[English](#english) | [Bahasa Indonesia](#bahasa-indonesia)
-
----
-
-<a name="english"></a>
-## English
-
-### Description
-Automatically maintains project documentation after every successful build or feature implementation. Updates `CHANGELOG.md`, `BLUEPRINT.md`, and introduces **Architecture Decision Records (ADRs)** — immutable records of key architectural decisions made throughout the project lifecycle.
-
-### Trigger Conditions
-- A feature, bug fix, or refactor has been successfully implemented and verified.
-- The user asks to "update docs", "document this", or "save progress".
-- After completing a phase in `zero-to-prod-orchestrator`.
-- A significant architectural decision was made (DB choice, auth flow, API design).
-
-### Files Maintained
-
-| 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 |
-
-### CHANGELOG.md Format (Keep-a-Changelog Standard)
-```markdown
-# Changelog
-All notable changes to this project will be documented in this file.
-Format based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
-
-## [Unreleased]
-### Added
-- New feature or capability
-
-## [1.2.0] — 2026-07-29
-### Added
-- Super Admin dashboard on `admin.domain.com` with tenant management
-- Polar.sh billing integration as alternative to Stripe
-- `spa-orchestrator` skill for SPA architecture decisions
-
-### Changed
-- Upgraded React to 19.x with new Compiler (removes need for useMemo/useCallback)
-- Migrated from `tailwind.config.js` to CSS-first `@theme` configuration (Tailwind v4)
-
-### Fixed
-- N+1 query issue in workspace members list endpoint
-- Memory leak in WebSocket connection cleanup
-
-### Security
-- Upgraded Supabase client to Auth v3 with PKCE flow (replaces implicit flow)
-- Service role key moved out of client-side code
-
-## [1.1.0] — 2026-06-15
-### Added
-...
-```
-
-### BLUEPRINT.md Structure
-```markdown
-# [Project Name] — Technical Blueprint
-
-## Architecture Overview
-[High-level diagram or description]
-
-## Tech Stack
-| Layer | Technology | Version |
-|---|---|---|
-| Frontend | Next.js | 15.x |
-| Backend | Hono | latest |
-| Database | PostgreSQL + Drizzle | — |
-| Auth | Supabase Auth | v3 |
-
-## Entry Points
-| URL | Purpose |
-|---|---|
-| `domain.com` | Marketing/Landing |
-| `app.domain.com` | SaaS App |
-| `admin.domain.com` | Super Admin |
-
-## Database Schema (Summary)
-[Key tables and relationships]
-
-## API Endpoints (Summary)
-[Key routes and their purposes]
-
-## Environment Variables Required
-[List of all required env vars]
-```
-
-### Architecture Decision Records (ADRs)
-
-ADRs are **immutable records** of significant architectural decisions. Once created, they are never deleted — only superseded by a new ADR. This creates a historical audit trail of *why* the system is built the way it is.
-
-#### ADR Template (`docs/adr/ADR-NNN-title.md`)
-```markdown
-# ADR-001: Use Supabase for Authentication and Database
-
-**Status**: Accepted
-**Date**: 2026-07-29
-**Deciders**: [Team/Individual]
-
-## Context
-[What is the situation that motivated this decision? What forces are at play?]
-
-We need a database + authentication solution for our SaaS MVP that can be
-delivered quickly without managing infrastructure.
-
-## Decision
-We will use Supabase as our primary backend-as-a-service, providing:
-- PostgreSQL database with Row Level Security (RLS)
-- Auth v3 with PKCE flow (OAuth, magic links, MFA)
-- Realtime subscriptions
-- Storage for user-uploaded files
-
-## Rationale
-- Faster time-to-market than self-hosted Postgres + separate auth service
-- Built-in RLS for multi-tenant isolation without custom middleware
-- Open-source — can self-host later if needed
-- Strong TypeScript SDK with auto-generated types
-
-## Consequences
-**Positive:**
-- No auth infrastructure to manage
-- RLS enforced at DB level — defense in depth
-
-**Negative:**
-- Vendor dependency — migration would require significant refactor
-- RLS requires careful testing to avoid data leakage bugs
-
-## Superseded By
-[ADR-XXX: Migrated to self-hosted Supabase] (if applicable)
-```
-
-#### ADR Index (`docs/adr/README.md`)
-```markdown
-# Architecture Decision Records
-
-| # | Title | Status | Date |
-|---|---|---|---|
-| [ADR-001](./ADR-001-supabase-auth.md) | Use Supabase for Auth + DB | ✅ Accepted | 2026-07-29 |
-| [ADR-002](./ADR-002-polar-billing.md) | Use Polar.sh for billing | ✅ Accepted | 2026-07-29 |
-| [ADR-003](./ADR-003-rls-isolation.md) | Shared Schema + RLS for multi-tenancy | ✅ Accepted | 2026-08-01 |
-| [ADR-004](./ADR-004-ssr-vs-spa.md) | Next.js SSR for main app, SPA for admin | 🔄 Proposed | 2026-08-05 |
-```
-
-### Update Protocol
-After every successful feature implementation:
-1. **CHANGELOG.md**: Add entry under `[Unreleased]` with correct category (Added/Changed/Fixed/Security).
-2. **BLUEPRINT.md**: Update only if schema, stack, or entry points changed.
-3. **PROGRESS.md**: Mark completed tasks `[x]`, update next steps.
-4. **ADR**: Create a new ADR if a significant architectural decision was made (DB choice, auth flow, billing provider, deployment strategy, isolation strategy).
-
----
-
-<a name="bahasa-indonesia"></a>
-## Bahasa Indonesia
-
-### Deskripsi
-Secara otomatis memelihara dokumentasi proyek setelah setiap build atau implementasi fitur yang berhasil. Memperbarui `CHANGELOG.md`, `BLUEPRINT.md`, dan memperkenalkan **Architecture Decision Records (ADR)** — catatan permanen dari keputusan arsitektur kunci yang dibuat sepanjang siklus hidup proyek.
-
-### Kondisi Pemicu
-- Sebuah fitur, perbaikan bug, atau refactor berhasil diimplementasikan dan diverifikasi.
-- Pengguna meminta "perbarui docs", "dokumentasikan ini", atau "simpan progres".
-- Setelah menyelesaikan fase dalam `zero-to-prod-orchestrator`.
-- Keputusan arsitektur signifikan dibuat (pilihan DB, alur auth, desain API).
-
-### File yang Dipelihara
-
-| File | Tujuan | Frekuensi Pembaruan |
-|---|---|---|
-| `CHANGELOG.md` | Daftar perubahan untuk pengguna | Setiap PR / fitur |
-| `BLUEPRINT.md` | Gambaran arsitektur teknis | Perubahan struktural besar |
-| `PROGRESS.md` | Roadmap dan status pengembangan | Setiap sesi kerja |
-| `docs/adr/` | Architecture Decision Records | Setiap keputusan kunci |
-
-### Format CHANGELOG.md (Standar Keep-a-Changelog)
-Gunakan kategori: `Added`, `Changed`, `Fixed`, `Removed`, `Security`. Simpan versi yang belum dirilis di bagian `[Unreleased]` dan turunkan ke versi bernama saat rilis.
-
-### Struktur BLUEPRINT.md
-Ringkasan arsitektur teknis termasuk: stack teknologi dengan versi, entry points (URL), skema database (ringkasan), endpoint API kunci, dan variabel lingkungan yang diperlukan.
-
-### Architecture Decision Records (ADR)
-
-ADR adalah **catatan permanen** dari keputusan arsitektur yang signifikan. Setelah dibuat, tidak pernah dihapus — hanya digantikan oleh ADR baru. Ini menciptakan jejak audit historis tentang *mengapa* sistem dibangun seperti yang ada.
-
-Setiap ADR mencakup: Konteks (situasi yang memotivasi keputusan), Keputusan (apa yang diputuskan), Rasional (mengapa), Konsekuensi (positif dan negatif), dan Digantikan Oleh (jika berlaku).
-
-Kelola ADR dengan indeks di `docs/adr/README.md` yang mencantumkan semua ADR dengan status (Diterima, Ditolak, Diusulkan, Usang).
-
-### Protokol Pembaruan
-Setelah setiap implementasi fitur yang berhasil:
-1. **CHANGELOG.md**: Tambahkan entri di `[Unreleased]` dengan kategori yang benar.
-2. **BLUEPRINT.md**: Perbarui hanya jika skema, stack, atau entry points berubah.
-3. **PROGRESS.md**: Tandai tugas selesai `[x]`, perbarui langkah selanjutnya.
-4. **ADR**: Buat ADR baru jika keputusan arsitektur signifikan dibuat.
+---
+
+# Auto Documentation Updater (2026 — ADR Edition)
+
+[English](#english) | [Bahasa Indonesia](#bahasa-indonesia)
+
+---
+
+<a name="english"></a>
+## 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
+Automatically maintains project documentation after every successful build or feature implementation. Updates `CHANGELOG.md`, `BLUEPRINT.md`, and introduces **Architecture Decision Records (ADRs)** — immutable records of key architectural decisions made throughout the project lifecycle.
+
+### Trigger Conditions
+- A feature, bug fix, or refactor has been successfully implemented and verified.
+- The user asks to "update docs", "document this", or "save progress".
+- After completing a phase in `zero-to-prod-orchestrator`.
+- A significant architectural decision was made (DB choice, auth flow, API design).
+
+### Files Maintained
+
+| 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 |
+
+### CHANGELOG.md Format (Keep-a-Changelog Standard)
+```markdown
+# Changelog
+All notable changes to this project will be documented in this file.
+Format based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
+
+## [Unreleased]
+### Added
+- New feature or capability
+
+## [1.2.0] — 2026-07-29
+### Added
+- Super Admin dashboard on `admin.domain.com` with tenant management
+- Polar.sh billing integration as alternative to Stripe
+- `spa-orchestrator` skill for SPA architecture decisions
+
+### Changed
+- Upgraded React to 19.x with new Compiler (removes need for useMemo/useCallback)
+- Migrated from `tailwind.config.js` to CSS-first `@theme` configuration (Tailwind v4)
+
+### Fixed
+- N+1 query issue in workspace members list endpoint
+- Memory leak in WebSocket connection cleanup
+
+### Security
+- Upgraded Supabase client to Auth v3 with PKCE flow (replaces implicit flow)
+- Service role key moved out of client-side code
+
+## [1.1.0] — 2026-06-15
+### Added
+...
+```
+
+### BLUEPRINT.md Structure
+```markdown
+# [Project Name] — Technical Blueprint
+
+## Architecture Overview
+[High-level diagram or description]
+
+## Tech Stack
+| Layer | Technology | Version |
+|---|---|---|
+| Frontend | Next.js | 15.x |
+| Backend | Hono | latest |
+| Database | PostgreSQL + Drizzle | — |
+| Auth | Supabase Auth | v3 |
+
+## Entry Points
+| URL | Purpose |
+|---|---|
+| `domain.com` | Marketing/Landing |
+| `app.domain.com` | SaaS App |
+| `admin.domain.com` | Super Admin |
+
+## Database Schema (Summary)
+[Key tables and relationships]
+
+## API Endpoints (Summary)
+[Key routes and their purposes]
+
+## Environment Variables Required
+[List of all required env vars]
+```
+
+### Architecture Decision Records (ADRs)
+
+ADRs are **immutable records** of significant architectural decisions. Once created, they are never deleted — only superseded by a new ADR. This creates a historical audit trail of *why* the system is built the way it is.
+
+#### ADR Template (`docs/adr/ADR-NNN-title.md`)
+```markdown
+# ADR-001: Use Supabase for Authentication and Database
+
+**Status**: Accepted
+**Date**: 2026-07-29
+**Deciders**: [Team/Individual]
+
+## Context
+[What is the situation that motivated this decision? What forces are at play?]
+
+We need a database + authentication solution for our SaaS MVP that can be
+delivered quickly without managing infrastructure.
+
+## Decision
+We will use Supabase as our primary backend-as-a-service, providing:
+- PostgreSQL database with Row Level Security (RLS)
+- Auth v3 with PKCE flow (OAuth, magic links, MFA)
+- Realtime subscriptions
+- Storage for user-uploaded files
+
+## Rationale
+- Faster time-to-market than self-hosted Postgres + separate auth service
+- Built-in RLS for multi-tenant isolation without custom middleware
+- Open-source — can self-host later if needed
+- Strong TypeScript SDK with auto-generated types
+
+## Consequences
+**Positive:**
+- No auth infrastructure to manage
+- RLS enforced at DB level — defense in depth
+
+**Negative:**
+- Vendor dependency — migration would require significant refactor
+- RLS requires careful testing to avoid data leakage bugs
+
+## Superseded By
+[ADR-XXX: Migrated to self-hosted Supabase] (if applicable)
+```
+
+#### ADR Index (`docs/adr/README.md`)
+```markdown
+# Architecture Decision Records
+
+| # | Title | Status | Date |
+|---|---|---|---|
+| [ADR-001](./ADR-001-supabase-auth.md) | Use Supabase for Auth + DB | ✅ Accepted | 2026-07-29 |
+| [ADR-002](./ADR-002-polar-billing.md) | Use Polar.sh for billing | ✅ Accepted | 2026-07-29 |
+| [ADR-003](./ADR-003-rls-isolation.md) | Shared Schema + RLS for multi-tenancy | ✅ Accepted | 2026-08-01 |
+| [ADR-004](./ADR-004-ssr-vs-spa.md) | Next.js SSR for main app, SPA for admin | 🔄 Proposed | 2026-08-05 |
+```
+
+### Update Protocol
+After every successful feature implementation:
+1. **CHANGELOG.md**: Add entry under `[Unreleased]` with correct category (Added/Changed/Fixed/Security).
+2. **BLUEPRINT.md**: Update only if schema, stack, or entry points changed.
+3. **PROGRESS.md**: Mark completed tasks `[x]`, update next steps.
+4. **ADR**: Create a new ADR if a significant architectural decision was made (DB choice, auth flow, billing provider, deployment strategy, isolation strategy).
+
+### Skill Orchestration & Handoff
+- **Global Listener**: Invoked automatically after completing milestones in `zero-to-prod-orchestrator`, `brainstorming`, `prd-architect`, or any domain expert skill execution.
+- **Context Handoff**: Coordinates with `session-handoff-resume` to ensure checkpoints and documentation are saved before context switching.
+- **Codebase Auditing**: Coordinates with `vibe-code-gardener` to log dead code purges and structural refactors.
+
+---
+
+<a name="bahasa-indonesia"></a>
+## Bahasa Indonesia
+
+### Integrasi Orkestrasi
+Terhubung dan mengorkestrasi skill domain yang relevan seperti `brainstorming`, `zero-to-prod-orchestrator`, dan `project-context-mapper` untuk memastikan eksekusi yang kohesif.
+
+### Deskripsi
+Secara otomatis memelihara dokumentasi proyek setelah setiap build atau implementasi fitur yang berhasil. Memperbarui `CHANGELOG.md`, `BLUEPRINT.md`, dan memperkenalkan **Architecture Decision Records (ADR)** — catatan permanen dari keputusan arsitektur kunci yang dibuat sepanjang siklus hidup proyek.
+
+### Kondisi Pemicu
+- Sebuah fitur, perbaikan bug, atau refactor berhasil diimplementasikan dan diverifikasi.
+- Pengguna meminta "perbarui docs", "dokumentasikan ini", atau "simpan progres".
+- Setelah menyelesaikan fase dalam `zero-to-prod-orchestrator`.
+- Keputusan arsitektur signifikan dibuat (pilihan DB, alur auth, desain API).
+
+### File yang Dipelihara
+
+| File | Tujuan | Frekuensi Pembaruan |
+|---|---|---|
+| `CHANGELOG.md` | Daftar perubahan untuk pengguna | Setiap PR / fitur |
+| `BLUEPRINT.md` | Gambaran arsitektur teknis | Perubahan struktural besar |
+| `PROGRESS.md` | Roadmap dan status pengembangan | Setiap sesi kerja |
+| `docs/adr/` | Architecture Decision Records | Setiap keputusan kunci |
+
+### Format CHANGELOG.md (Standar Keep-a-Changelog)
+Gunakan kategori: `Added`, `Changed`, `Fixed`, `Removed`, `Security`. Simpan versi yang belum dirilis di bagian `[Unreleased]` dan turunkan ke versi bernama saat rilis.
+
+### Struktur BLUEPRINT.md
+Ringkasan arsitektur teknis termasuk: stack teknologi dengan versi, entry points (URL), skema database (ringkasan), endpoint API kunci, dan variabel lingkungan yang diperlukan.
+
+### Architecture Decision Records (ADR)
+
+ADR adalah **catatan permanen** dari keputusan arsitektur yang signifikan. Setelah dibuat, tidak pernah dihapus — hanya digantikan oleh ADR baru. Ini menciptakan jejak audit historis tentang *mengapa* sistem dibangun seperti yang ada.
+
+Setiap ADR mencakup: Konteks (situasi yang memotivasi keputusan), Keputusan (apa yang diputuskan), Rasional (mengapa), Konsekuensi (positif dan negatif), dan Digantikan Oleh (jika berlaku).
+
+Kelola ADR dengan indeks di `docs/adr/README.md` yang mencantumkan semua ADR dengan status (Diterima, Ditolak, Diusulkan, Usang).
+
+### Protokol Pembaruan
+Setelah setiap implementasi fitur yang berhasil:
+1. **CHANGELOG.md**: Tambahkan entri di `[Unreleased]` dengan kategori yang benar.
+2. **BLUEPRINT.md**: Perbarui hanya jika skema, stack, atau entry points berubah.
+3. **PROGRESS.md**: Tandai tugas selesai `[x]`, perbarui langkah selanjutnya.
+4. **ADR**: Buat ADR baru jika keputusan arsitektur signifikan dibuat.
+
+### Orkestrasi Skill & Serah Terima
+- **Pendengar Global**: Dipanggil secara otomatis setelah menyelesaikan milestone di `zero-to-prod-orchestrator`, `brainstorming`, `prd-architect`, atau skill domain spesialis mana pun.
+- **Serah Terima Konteks**: Berkoordinasi dengan `session-handoff-resume` untuk memastikan checkpoint dan dokumentasi tersimpan sebelum alih konteks.
+- **Audit Codebase**: Berkoordinasi dengan `vibe-code-gardener` untuk mencatat pembersihan dead code dan refactoring struktural.

package/skills/autonomous-chaos-monkey/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: autonomous-chaos-monkey
+description: "AI-driven Chaos Engineering. Randomly injects latency, terminates mock services, and automatically implements circuit breakers / Chaos Engineering berbasis AI. Menyuntikkan latensi secara acak, mematikan layanan simulasi, dan secara otomatis menerapkan circuit breaker."
+author: "Roedy Rustam"
+---
+
+# Autonomous Chaos Monkey (Resilience Engineering Agent)
+
+[English](#english) | [Bahasa Indonesia](#bahasa-indonesia)
+
+---
+
+<a name="english"></a>
+## English
+
+### Description
+Inspired by Netflix's Chaos Monkey, this agent actively tests system resilience by injecting chaos into staging or local development environments. Instead of assuming the network is reliable, it forcibly kills database connections, drops network packets, and injects severe latency into external API calls. It then analyzes the application's failure mode and automatically writes resilience patterns (Circuit Breakers, Retries, Fallback UI) until the system becomes fault-tolerant.
+
+### Trigger Conditions
+- During Phase 7 (DevOps & Production Hardening) before a major launch.
+- When architecting microservices, event-driven systems, or serverless edge databases.
+- When integrating critical external APIs (e.g., Stripe, DOKU, LLM APIs).
+
+### Operating Protocol
+1. **Chaos Injection**: Uses tools like Toxiproxy, Gremlin (via API), or custom network simulation scripts to disrupt connections.
+2. **Observation**: Monitors application logs and user experience (e.g., does it crash? Does the UI hang indefinitely? Does it return a blank screen?).
+3. **Self-Healing Code Generation**: 
+   - Implements Circuit Breaker patterns.
+   - Adds exponential backoff retries.
+   - Implements graceful degradation (e.g., serving cached data or displaying fallback UI states).
+4. **Verification**: Repeats the chaos injection until the system can survive the disruption without severe user impact.
+
+## Orchestration & Integration
+- Connects to `error-resilience-expert` to implement the actual React Error Boundaries and Circuit Breaker logic.
+- Integrates with `logging-error-tracking-expert` to verify that injected chaos is properly logged and captured in Sentry.
+- Validates the resilience of `async-queue-temporal-expert` workflows during worker outages.
+
+---
+
+<a name="bahasa-indonesia"></a>
+## Bahasa Indonesia
+
+### Deskripsi
+Terinspirasi dari Chaos Monkey milik Netflix, agen ini secara aktif menguji ketahanan sistem dengan menyuntikkan kekacauan (*chaos*) ke dalam lingkungan staging atau pengembangan lokal. Alih-alih berasumsi bahwa jaringan selalu stabil, agen ini secara paksa mematikan koneksi database, membuang paket jaringan, dan menyuntikkan latensi parah pada pemanggilan API eksternal. Kemudian, ia menganalisis mode kegagalan aplikasi dan secara otomatis menulis pola ketahanan (*Circuit Breakers*, *Retries*, *Fallback UI*) sampai sistem kebal terhadap gangguan.
+
+### Kondisi Pemicu
+- Saat Fase 7 (DevOps & Pengerasan Produksi) sebelum peluncuran besar.
+- Saat merancang arsitektur microservices, sistem event-driven, atau database serverless.
+- Saat mengintegrasikan API eksternal kritis (misalnya Stripe, DOKU, API LLM).
+
+### Protokol Operasi
+1. **Injeksi Kekacauan**: Menggunakan alat seperti Toxiproxy, Gremlin (via API), atau skrip simulasi jaringan kustom untuk mengganggu koneksi.
+2. **Observasi**: Memantau log aplikasi dan pengalaman pengguna (misal: apakah aplikasi *crash*? Apakah UI macet tanpa batas waktu? Apakah menampilkan layar kosong?).
+3. **Generasi Kode Self-Healing**: 
+   - Menerapkan pola Circuit Breaker.
+   - Menambahkan mekanisme *retry* dengan *exponential backoff*.
+   - Menerapkan degradasi anggun (*graceful degradation*), seperti menyajikan data dari *cache* atau menampilkan state UI pengganti.
+4. **Verifikasi**: Mengulangi injeksi kekacauan hingga sistem mampu bertahan dari gangguan tanpa berdampak fatal pada pengguna.
+
+## Integrasi Orkestrasi
+- Terhubung dengan `error-resilience-expert` untuk mengimplementasikan logika React Error Boundaries dan Circuit Breaker yang sesungguhnya.
+- Terintegrasi dengan `logging-error-tracking-expert` untuk memastikan bahwa kekacauan yang disuntikkan dicatat dengan benar dan terekam di Sentry.
+- Memvalidasi ketahanan alur kerja `async-queue-temporal-expert` selama pekerja (*worker*) mengalami pemadaman.