vibes-plug 2.5.0 → 2.14.1

package/CONTRIBUTING.md

@@ -1,199 +0,0 @@
-# Contribution Guide / Panduan Kontribusi
-
-[English](#english) | [Bahasa Indonesia](#bahasa-indonesia)
-
----
-
-<a name="english"></a>
-## English
-
-Thank you for contributing to **Vibes Plug**! This guide is designed to make it easy for you if you have *forked* this repository on GitHub to add or update *skills* according to proper standards.
-
-### Contribution Flow (Step-by-Step)
-
-#### 1. Sync Your Local Repository
-Ensure your local repository is connected to the main repository (*upstream*) to get the latest updates.
-
-If you haven't added the main repository as an *upstream* remote, run the following command in your terminal/PowerShell inside the `vibes-plug` directory:
-
-```bash
-# Add upstream remote
-git remote add upstream https://github.com/roedyrustam/vibes-plug.git
-```
-
-Before you start creating a new skill, sync your local `main` branch with upstream:
-
-```bash
-# Switch to main branch
-git checkout main
-
-# Pull the latest updates from upstream
-git pull upstream main
-
-# Sync it to your GitHub fork (origin)
-git push origin main
-```
-
-#### 2. Create a New Branch
-Always create a new, descriptive branch for the changes you want to make:
-
-```bash
-git checkout -b feat/add-skill-<skill-name>
-# Example: git checkout -b feat/add-skill-fast-api
-```
-
-#### 3. Create a New Skill Module
-1. Navigate to the `skills/` directory.
-2. Create a new folder with your skill name using **kebab-case** (e.g., `skills/fast-api`).
-3. Create a `SKILL.md` file inside that folder. You can copy the template from [SKILL.md](file:///c:/Users/roedy/.gemini/config/plugins/vibes-plug/skills/skill_baru/SKILL.md).
-
-Set up the metadata (frontmatter) at the very top of the `SKILL.md` file:
-
-```yaml
----
-name: kebab-case-skill-name
-description: "Short English description / Deskripsi singkat"
-author: "Your Name or GitHub Username"
----
-```
-
-The document body must have the following sections:
-- `# Skill Name`
-- `## Description`
-- `## Instructions` (Contains detailed guidelines, code styling rules, etc.)
-- `## Trigger Conditions` (Conditions/context under which this skill should be activated by the agent)
-
-#### 4. Register the Skill in README.md and BLUEPRINT.md
-To make your new skill recognized and easily discoverable:
-1. **`README.md`**: Register your skill in the **Features and Available Skills** section under the relevant category.
-2. **`BLUEPRINT.md`**: Register your skill module in the **Skill Modules** section.
-
-#### 5. Run the Standardization Script
-We provide an automated script to format markdown, align technology stack versions (e.g., React 19, Next.js 15), and fix emoji encoding issues.
-
-Run the following command before committing:
-
-```bash
-node scripts/update_skills.js
-```
-
-Ensure the script runs successfully and check if any of your new skill files were updated.
-
-#### 6. Commit and Push Changes
-Once everything is neat and validated, commit your changes:
-
-```bash
-git add .
-git commit -m "feat: add skill <skill-name>"
-git push origin feat/add-skill-<skill-name>
-```
-
-#### 7. Create a Pull Request (PR)
-1. Open your forked repository page on GitHub (e.g., `https://github.com/username/vibes-plug`).
-2. You will see a yellow button saying **"Compare & pull request"**. Click that button.
-3. Provide a clear description of the purpose and utility of the skill you added.
-4. Submit your Pull Request (PR) to the `main` branch of the original repository (`roedyrustam/vibes-plug`).
-
-### Additional Rules & Tips
-> [!NOTE]
-> - Ensure instructions are written in a clear and instructive language.
-> - Avoid duplicate instructions with existing skills. If your skill is similar, consider updating an existing skill instead.
-> - Do not include extra frontmatter fields other than `name`, `description`, and `author`, as they will be cleaned automatically by the `update_skills.js` script.
-
----
-
-<a name="bahasa-indonesia"></a>
-## Bahasa Indonesia
-
-Terima kasih telah berkontribusi ke **Vibes Plug**! Panduan ini dirancang khusus untuk mempermudah Anda yang telah melakukan *fork* repositori ini di GitHub agar dapat menambahkan atau memperbarui *skills* dengan standar yang sesuai.
-
-### Alur Kontribusi (Step-by-Step)
-
-#### 1. Sinkronisasi Repositori Lokal Anda
-Pastikan repositori lokal Anda terhubung dengan repositori utama (*upstream*) agar selalu mendapatkan pembaruan terbaru.
-
-Jika Anda belum menambahkan repositori utama sebagai *upstream*, jalankan perintah berikut di terminal/PowerShell di dalam direktori `vibes-plug`:
-
-```bash
-# Tambahkan remote upstream
-git remote add upstream https://github.com/roedyrustam/vibes-plug.git
-```
-
-Sebelum mulai membuat skill baru, lakukan sinkronisasi branch `main` lokal Anda dengan upstream:
-
-```bash
-# Pindah ke branch main
-git checkout main
-
-# Tarik pembaruan terbaru dari upstream
-git pull upstream main
-
-# Sinkronisasikan ke fork GitHub Anda (origin)
-git push origin main
-```
-
-#### 2. Buat Branch Baru
-Selalu buat branch baru yang deskriptif untuk perubahan yang ingin Anda lakukan:
-
-```bash
-git checkout -b feat/add-skill-<nama-skill>
-# Contoh: git checkout -b feat/add-skill-fast-api
-```
-
-#### 3. Buat Modul Skill Baru
-1. Masuk ke direktori `skills/`.
-2. Buat folder baru dengan nama skill Anda menggunakan format **kebab-case** (misalnya `skills/fast-api`).
-3. Buat file `SKILL.md` di dalam folder tersebut. Anda bisa menyalin template dari [SKILL.md](file:///c:/Users/roedy/.gemini/config/plugins/vibes-plug/skills/skill_baru/SKILL.md).
-
-Atur format metadata (frontmatter) di bagian paling atas file `SKILL.md`:
-
-```yaml
----
-name: nama-skill-kebab-case
-description: "Deskripsi singkat / Short description"
-author: "Nama Anda atau Username GitHub"
----
-```
-
-Struktur isi dokumen harus memiliki bagian berikut:
-- `# Nama Skill`
-- `## Deskripsi`
-- `## Instruksi` (Berisi panduan detail, aturan penulisan kode, dll.)
-- `## Kondisi Pemicu` (Kondisi/konteks kapan skill ini harus diaktifkan oleh agen)
-
-#### 4. Daftarkan Skill di README.md dan BLUEPRINT.md
-Agar skill baru Anda dikenali dan mudah ditemukan:
-1. **`README.md`**: Daftarkan skill Anda di bagian **Fitur dan Skills yang Tersedia** di bawah kategori yang relevan.
-2. **`BLUEPRINT.md`**: Daftarkan modul skill Anda di bagian **Skill Modules**.
-
-#### 5. Jalankan Script Standardisasi
-Kami menyediakan script otomatis untuk merapikan markdown, menyelaraskan versi stack teknologi (misal React 19, Next.js 15), serta memperbaiki isu encoding emoji.
-
-Jalankan perintah berikut sebelum melakukan commit:
-
-```bash
-node scripts/update_skills.js
-```
-
-Pastikan script berjalan dengan sukses dan laporkan jika ada file skill baru Anda yang diperbarui.
-
-#### 6. Commit dan Push Perubahan
-Setelah semuanya rapi dan tervalidasi, commit perubahan Anda:
-
-```bash
-git add .
-git commit -m "feat: add skill <nama-skill>"
-git push origin feat/add-skill-<nama-skill>
-```
-
-#### 7. Buat Pull Request (PR)
-1. Buka halaman repositori hasil fork Anda di GitHub (misal: `https://github.com/username/vibes-plug`).
-2. Anda akan melihat tombol kuning bertuliskan **"Compare & pull request"**. Klik tombol tersebut.
-3. Berikan deskripsi yang jelas mengenai tujuan dan kegunaan dari skill yang Anda tambahkan.
-4. Kirim Pull Request (PR) Anda ke branch `main` repositori asal (`roedyrustam/vibes-plug`).
-
-### Aturan Tambahan & Tips
-> [!NOTE]
-> - Pastikan instruksi ditulis dengan bahasa yang jelas dan instruktif.
-> - Hindari duplikasi instruksi dengan skill yang sudah ada. Jika skill Anda mirip, pertimbangkan untuk memperbarui skill yang telah ada.
-> - Jangan menyertakan frontmatter tambahan di luar `name`, `description`, dan `author`, karena akan dibersihkan secara otomatis oleh script `update_skills.js`.

package/SECURITY.md

@@ -1,21 +0,0 @@
-# Security Policy
-
-## Supported Versions
-
-Use this section to tell people about which versions of your project are
-currently being supported with security updates.
-
-| Version | Supported          |
-| ------- | ------------------ |
-| 5.1.x   | :white_check_mark: |
-| 5.0.x   | :x:                |
-| 4.0.x   | :white_check_mark: |
-| < 4.0   | :x:                |
-
-## Reporting a Vulnerability
-
-Use this section to tell people how to report a vulnerability.
-
-Tell them where to go, how often they can expect to get an update on a
-reported vulnerability, what to expect if the vulnerability is accepted or
-declined, etc.

package/skills/ai-cost-token-optimizer/SKILL.md

@@ -1,52 +0,0 @@
----
-name: ai-cost-token-optimizer
-description: "Expert guide for LLM API cost optimization, Prompt Caching, model routing (Flash/Pro/Opus), semantic caching, and token budgeting / Panduan ahli optimasi biaya API LLM, Prompt Caching, model routing, dan semantic caching."
-author: vibes-plug-swarm
----
-
-# AI Cost & Token Optimizer
-
-[English](#english) | [Bahasa Indonesia](#bahasa-indonesia)
-
----
-
-<a name="english"></a>
-## English
-
-### Purpose & Overview
-Production-grade guidelines for FinOps in AI engineering — prompt caching (Anthropic Prompt Caching, Gemini Context Caching), dynamic model routing (routing lightweight queries to Flash/Haiku and complex reasoning to Pro/Opus), semantic caching with Redis/GPTCache, and real-time token expenditure tracking.
-
-### Key Capabilities
-- **Prompt & Context Caching**: Storing static system prompts, long-context documents, and schemas in cache to reduce token costs by up to 90%.
-- **Model Router**: Heuristic and classifier-based routing between ultra-fast Flash models and high-reasoning Pro models.
-- **Semantic Caching**: Hashing query vector embeddings to serve cached responses for semantically identical user queries.
-
-```typescript
-// Model Routing Strategy Example
-export function selectOptimalModel(promptLength: number, taskType: 'classification' | 'reasoning' | 'summary') {
-  if (taskType === 'classification' || promptLength < 500) {
-    return 'gemini-3.5-flash'; // High speed, ultra low cost
-  }
-  return 'gemini-3.1-pro'; // Complex reasoning
-}
-```
-
----
-
-<a name="bahasa-indonesia"></a>
-## Bahasa Indonesia
-
-### Deskripsi
-Panduan tingkat produksi untuk FinOps dalam rekayasa AI — prompt caching (Anthropic Prompt Caching & Gemini Context Caching), routing model dinamis (mengarahkan tugas ringan ke Flash/Haiku dan tugas penalaran ke Pro/Opus), semantic caching dengan Redis, dan pelacakan anggaran token real-time.
-
-### Fitur Utama
-- **Prompt & Context Caching**: Menyimpan prompt sistem dan dokumen konteks panjang di cache untuk menghemat hingga 90% biaya token.
-- **Model Router**: Routing otomatis berdasarkan heuristik antara model ultra-cepat Flash dan model penalaran Pro.
-- **Semantic Caching**: Memanfaatkan embedding vector query untuk menyajikan respon cache pada pertanyaan pengguna yang serupa secara semantik.
-
-
-## Orchestration & Integration
-- Integrates with `ai-llm-integration-expert`, `token-saver`, `llm-cost-arbitrage-router`, and `zero-to-prod-orchestrator`.
-
-## Integrasi Orkestrasi
-- Terintegrasi dengan `ai-llm-integration-expert`, `token-saver`, `llm-cost-arbitrage-router`, dan `zero-to-prod-orchestrator`.

package/skills/asisten_ramah/SKILL.md

@@ -1,41 +0,0 @@
----
-name: asisten-ramah
-description: "Skill to make Antigravity respond in a friendly manner / Skill untuk membuat Antigravity membalas dengan ramah."
-author: "Roedy Rustam"
----
-
-# Asisten Ramah / Friendly Assistant
-
-[English](#english) | [Bahasa Indonesia](#bahasa-indonesia)
-
----
-
-<a name="english"></a>
-## English
-
-### Description
-This skill is a basic example to make Antigravity (me) always respond with a friendly, warm, and polite language style.
-
-### Instructions
-- Always start the conversation or response with a friendly greeting (e.g., "Hello!", "Hi there!", or "Ready to help!").
-- Always be polite and use plenty of emojis in responses.
-- If the user asks about code, always provide words of encouragement before presenting the code.
-
-### Trigger Conditions
-Always active for every interaction with the user.
-
----
-
-<a name="bahasa-indonesia"></a>
-## Bahasa Indonesia
-
-### Deskripsi
-Skill ini adalah contoh dasar untuk membuat Antigravity (saya) selalu membalas dengan gaya bahasa tertentu yang ramah dan sopan.
-
-### Instruksi
-- Anda harus selalu memulai percakapan atau jawaban dengan kata sapaan yang ramah (misalnya: "Halo!", "Hai di sana!", atau "Siap membantu!").
-- Selalu bersikap sopan dan gunakan banyak emoji dalam jawaban.
-- Jika pengguna bertanya tentang kode, selalu berikan semangat sebelum memberikan kodenya.
-
-### Kondisi Pemicu
-Selalu aktif untuk setiap interaksi dengan pengguna.

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

@@ -1,214 +0,0 @@
----
-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

@@ -1,63 +0,0 @@
----
-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-swarm-director/SKILL.md

@@ -1,69 +0,0 @@
----
-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.