vibes-plug 1.0.0 → 2.5.0

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

@@ -1,204 +1,214 @@
----
-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.
+---
+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).
+
+### 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
+
+### 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: vibes-plug-swarm
+---
+
+# 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.

package/skills/autonomous-red-teamer/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: autonomous-red-teamer
+description: "AI-driven dynamic security fuzzing, exploit generation (XSS, SQLi, SSRF, Prompt Injection), and automated patch remediation / Fuzzing keamanan dinamis berbasis AI, eksploitasi, dan remediasi otomatis."
+author: vibes-plug-swarm
+---
+
+# Autonomous Red Teamer (AI Hacker & Pen-Tester)
+
+[English](#english) | [Bahasa Indonesia](#bahasa-indonesia)
+
+---
+
+<a name="english"></a>
+## English
+
+### Description
+An adversarial subagent designed to ruthlessly attack and penetrate the code generated by the main AI agent before deployment. Moving beyond static analysis (SAST), it performs dynamic, AI-driven adversarial fuzzing by generating and executing exploit payloads (SQLi, XSS, SSRF, IDOR, Prompt Injections) in a sandboxed environment. If it successfully breaches the system, it forces the main agent to rewrite the code with robust security boundaries.
+
+### Trigger Conditions
+- During Phase 6 (Automated Testing & Security Audit) of the CI/CD pipeline.
+- When generating complex authentication, payment gateways, or RLS policies.
+- When handling untrusted user input or file uploads.
+
+### Operating Protocol
+1. **Reconnaissance**: Scans the target architecture to identify attack surfaces (API endpoints, database queries, file uploads, LLM prompts).
+2. **Exploit Generation**: Crafts targeted malicious payloads using specialized frameworks (e.g., ZAP, Burp Suite APIs, custom python fuzzer scripts).
+3. **Execution**: Blasts the local staging environment or sandbox with payloads.
+4. **Analysis & Remediation**: If an exploit succeeds (e.g., bypasses auth, crashes the server, extracts unintended data), it halts the pipeline, generates a CVE-style report, and instructs the main agent to apply patches (input validation, rate limiting, parameterized queries).
+
+## Orchestration & Integration
+- Connects to `secure-fuzz-testing` for native memory fuzzing (Rust/Go).
+- Works alongside `authentication-identity-expert` to test auth bypasses.
+- Guards `doku-payment-gateway` and `saas-billing` against tampering and replay attacks.
+- Invokes `rate-limit-abuse-prevention` to mitigate DDoS and brute-force discoveries.
+
+---
+
+<a name="bahasa-indonesia"></a>
+## Bahasa Indonesia
+
+### Deskripsi
+Sub-agen *adversarial* yang dirancang khusus untuk menyerang dan meretas kode yang dihasilkan oleh agen AI utama sebelum di-deploy. Melampaui batasan analisis statis (SAST), skill ini melakukan *fuzzing* dinamis dengan membuat dan menjalankan *payload* eksploitasi (SQLi, XSS, SSRF, IDOR, Prompt Injection) di lingkungan Sandbox. Jika berhasil menembus sistem, ia akan memaksa agen utama untuk merombak kode tersebut dengan batas keamanan yang lebih kuat.
+
+### Kondisi Pemicu
+- Saat Fase 6 (Pengujian Otomatis & Audit Keamanan) pada pipeline CI/CD.
+- Saat membuat sistem autentikasi, payment gateway, atau kebijakan RLS yang kompleks.
+- Saat menangani input pengguna yang tidak terpercaya atau upload file.
+
+### Protokol Operasi
+1. **Pengintaian (Reconnaissance)**: Memindai arsitektur target untuk mengidentifikasi permukaan serangan (endpoint API, query database, upload file, prompt LLM).
+2. **Pembuatan Eksploit**: Merakit *payload* berbahaya khusus menggunakan framework (mis. ZAP, API Burp Suite, skrip fuzzer Python kustom).
+3. **Eksekusi**: Menembakkan eksploitasi ke lingkungan staging atau sandbox lokal.
+4. **Analisis & Remediasi**: Jika eksploitasi berhasil (misalnya melewati autentikasi, membuat server *crash*, mengekstrak data sensitif), proses pipeline akan dihentikan, ia akan membuat laporan gaya CVE, dan menginstruksikan agen utama untuk menerapkan *patch* perbaikan (validasi input, rate limiting, parameterized queries).
+
+## Integrasi Orkestrasi
+- Terhubung dengan `secure-fuzz-testing` untuk fuzzing memori native (Rust/Go).
+- Bekerja berdampingan dengan `authentication-identity-expert` untuk menguji kerentanan autentikasi.
+- Menjaga `doku-payment-gateway` dan `saas-billing` dari serangan manipulasi dan *replay attack*.
+- Memanggil `rate-limit-abuse-prevention` untuk memitigasi celah DDoS dan *brute-force* yang ditemukan.

package/skills/autonomous-swarm-director/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: autonomous-swarm-director
+description: "Elevates the AI from a single-threaded agent into a Swarm Director. Teaches the agent how to break down complex tasks and autonomously invoke and orchestrate multiple subagents in parallel to achieve a goal."
+author: "Roedy Rustam"
+---
+
+# Autonomous Swarm Director (Multi-Agent Parallelism)
+
+[English](#english) | [Bahasa Indonesia](#bahasa-indonesia)
+
+---
+
+<a name="english"></a>
+## English
+
+### Description
+Claude and other standard models are constrained by sequential, single-threaded responses. Antigravity has the native `invoke_subagent` capability. This skill elevates you from a "Coder" to a "Director." It gives you the "superpower" to split a massive task (e.g., building 5 pages at once) into parallel operations, spawning specialized subagents, delegating work, and merging their outputs upon completion.
+
+### Trigger Conditions
+Activate this skill when:
+- The user requests a very large feature that would take too long to write sequentially.
+- The user specifically asks to "work in parallel" or use a "team of agents."
+- You detect a task that can be easily parallelized (e.g., writing 10 unit tests for 10 different files).
+
+### Core Concepts
+
+#### 1. Swarm Orchestration Protocol
+1. **Analyze:** Break the user's request into independent, non-overlapping tasks.
+2. **Spawn:** Use `invoke_subagent` to spawn multiple `research` or `self` subagents concurrently. Pass very specific, scoped `Prompt` instructions to each.
+3. **Wait & Monitor:** You do not need to poll. Antigravity will wake you up when a subagent finishes and sends a message back.
+4. **Adversarial Critique (Red Teaming):** Before merging the code, spawn a specialized "Auditor" subagent whose sole job is to aggressively find security vulnerabilities, edge cases, or performance bottlenecks in the subagents' work.
+5. **Merge & Resolve:** Once the code passes the adversarial critique, merge their code/findings, resolve conflicts, and report the final unified output to the user.
+
+#### 2. Agent Constraints
+- Do NOT spawn subagents for tasks that require modifying the exact same file simultaneously to avoid git/file conflict issues. 
+- Use the `branch` or `share` Workspace parameter in `invoke_subagent` if the subagents need to modify code safely.
+- Do NOT spawn more than 5 subagents at once unless explicitly approved by the user, as this consumes heavy resources.
+
+#### 3. Mandatory Documentation for New Projects
+- If the swarm is tasked with starting a new project from scratch, the Director MUST ensure that `PRD.md`, `ERD.md`, and `DOKUMENTASI.md` are generated (e.g., by delegating to a `prd-architect` subagent) before any other implementation work begins.
+
+---
+
+### Integration with Other Skills (MANDATORY)
+- `multi-agent-orchestration` — The theoretical foundation of graph-based agents, which this skill puts into native practice.
+- `project-context-mapper` — Subagents must be fed the context map to ensure they know where they are working.
+
+### Referenced By Orchestrators (MANDATORY)
+- `brainstorming` — Add to "AI & LLM Integration".
+- `zero-to-prod-orchestrator` — Phase 4 (AI Agents & Swarms).
+
+---
+
+<a name="bahasa-indonesia"></a>
+## Bahasa Indonesia
+
+### Deskripsi
+Claude dibatasi oleh respon berurutan (single-threaded). Antigravity memiliki fitur `invoke_subagent`. Skill ini mengangkat derajat Anda dari sekadar "Programmer" menjadi "Direktur Swarm (Pasukan)". Anda memiliki "kekuatan super" untuk memecah tugas raksasa menjadi beberapa bagian dan menyuruh beberapa sub-agen mengerjakannya secara paralel (bersamaan).
+
+### Kondisi Pemicu
+- Saat pengguna meminta pembuatan fitur berskala besar yang akan sangat lama jika dikerjakan satu per satu.
+- Saat tugas bisa diparalelkan (misal: menulis dokumentasi untuk 10 API *endpoint* yang berbeda).
+
+### Panduan Singkat
+- **Pecah & Delegasikan:** Gunakan tool `invoke_subagent`. Berikan peran spesifik (misal: `Frontend Developer`, `Database Schema Architect`) ke setiap sub-agen.
+- **Tidur & Tunggu:** Setelah sub-agen dikerahkan, Anda tidak perlu melakukan `polling`. Sistem akan membangunkan Anda otomatis saat sub-agen selesai dan mengirim pesan.
+- **Hindari Tabrakan File:** Jangan menugaskan dua sub-agen untuk mengedit file yang sama secara bersamaan. Bagilah tugas berdasarkan komponen atau modul yang berbeda.
+- **Kritik Adversarial (Red Teaming):** Sebelum kode digabungkan, panggil sub-agen "Auditor" khusus yang bertugas mencari kerentanan keamanan, edge case, atau kelemahan logika dari pekerjaan sub-agen lainnya.
+- **Dokumentasi Wajib (Proyek Baru):** Jika tim ditugaskan membuat proyek baru dari awal, Direktur WAJIB memastikan `PRD.md`, `ERD.md`, dan `DOKUMENTASI.md` dibuat (misalnya dengan mendelegasikan ke sub-agen `prd-architect`) sebelum pekerjaan koding dimulai.