vibes-plug 1.0.0 → 2.5.0

package/skills/post-quantum-crypto-migrator/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: post-quantum-crypto-migrator
+description: "FinTech future-proofing. Scans and migrates classical encryption to NIST-approved Post-Quantum Cryptography (PQC) / Migrasi ke Kriptografi Pasca-Kuantum (PQC) yang disetujui NIST untuk sistem FinTech."
+author: vibes-plug-swarm
+---
+
+# Post-Quantum Cryptography Migrator
+
+[English](#english) | [Bahasa Indonesia](#bahasa-indonesia)
+
+---
+
+<a name="english"></a>
+## English
+
+### Description
+An advanced security architect skill designed to future-proof FinTech, SaaS, and Payment integrations (such as DOKU) against the impending threat of Quantum Computers breaking classical encryption (RSA/ECC). It scans codebases for vulnerable cryptographic algorithms and migrates them to NIST-approved Post-Quantum Cryptography (PQC) algorithms, such as CRYSTALS-Kyber (for Key Encapsulation) and CRYSTALS-Dilithium/SPHINCS+ (for Digital Signatures).
+
+### Trigger Conditions
+- During security audits or Phase 6 (Automated Testing & Security Audit).
+- When upgrading high-security financial payment gateways or generating JWT/Session tokens.
+- Explicit user request to make the application "Quantum-Proof".
+
+### Operating Protocol
+1. **Cryptographic Discovery**: Audits all usage of `crypto`, `bcrypt`, `RSA`, `ECDSA`, and `HMAC` operations.
+2. **Hybrid Migration Plan**: Recommends hybrid implementations (combining classical ECC with PQC algorithms like Kyber-512) to comply with modern standards while maintaining backward compatibility.
+3. **Implementation**: Swaps vulnerable implementations with PQC-ready libraries (e.g., OQS - Open Quantum Safe, or modernized webcrypto wrappers supporting Kyber).
+4. **Validation**: Ensures the expanded key sizes and signature sizes of PQC algorithms do not break database schemas or HTTP header limits.
+
+## Orchestration & Integration
+- Enforces extreme security standards alongside `authentication-identity-expert`.
+- Hardens `doku-payment-gateway` and `saas-billing` payload encryption to banking-grade PQC standards.
+- Integrates with `database-orm-expert` to update schema lengths (PQC keys are significantly larger than RSA).
+
+---
+
+<a name="bahasa-indonesia"></a>
+## Bahasa Indonesia
+
+### Deskripsi
+Keterampilan arsitek keamanan tingkat lanjut yang dirancang untuk melindungi integrasi FinTech, SaaS, dan Sistem Pembayaran (seperti DOKU) dari ancaman Komputer Kuantum yang kelak mampu membobol enkripsi klasik (RSA/ECC). Agen ini memindai basis kode untuk mencari algoritma kriptografi yang rentan, lalu memigrasikannya ke standar Kriptografi Pasca-Kuantum (PQC) yang disetujui NIST, seperti CRYSTALS-Kyber (untuk *Key Encapsulation*) dan CRYSTALS-Dilithium/SPHINCS+ (untuk Tanda Tangan Digital).
+
+### Kondisi Pemicu
+- Selama audit keamanan atau Fase 6 (Pengujian Otomatis & Audit Keamanan).
+- Saat memperbarui *payment gateway* keuangan berskala tinggi atau membuat token JWT/Sesi.
+- Permintaan eksplisit dari pengguna untuk membuat aplikasi *"Quantum-Proof"* (Tahan-Kuantum).
+
+### Protokol Operasi
+1. **Penemuan Kriptografi**: Mengaudit seluruh penggunaan operasi `crypto`, `bcrypt`, `RSA`, `ECDSA`, dan `HMAC`.
+2. **Rencana Migrasi Hibrida**: Merekomendasikan implementasi hibrida (menggabungkan algoritma klasik ECC dengan algoritma PQC seperti Kyber-512) untuk mematuhi standar modern sembari menjaga kompatibilitas ke belakang (*backward compatibility*).
+3. **Implementasi**: Menukar implementasi yang rentan dengan pustaka yang mendukung PQC (misalnya, OQS - Open Quantum Safe, atau *wrapper webcrypto* modern yang mendukung Kyber).
+4. **Validasi**: Memastikan ukuran kunci dan ukuran *signature* algoritma PQC yang lebih besar tidak merusak skema database atau melampaui batas header HTTP.
+
+## Integrasi Orkestrasi
+- Menegakkan standar keamanan ekstrem berdampingan dengan `authentication-identity-expert`.
+- Memperkeras enkripsi *payload* `doku-payment-gateway` dan `saas-billing` ke standar PQC kelas perbankan.
+- Terintegrasi dengan `database-orm-expert` untuk memperbarui panjang skema kolom database (karena ukuran kunci PQC jauh lebih besar dari RSA).

package/skills/prd-architect/SKILL.md

@@ -1,191 +1,201 @@
----
-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.
+---
+name: prd-architect
+description: "Mandatory guardrail skill that enforces creating a comprehensive Product Requirements Document (PRD), ERD, and Documentation before generating code for new projects / Skill khusus untuk memaksa pembuatan Product Requirements Document (PRD), ERD, dan Dokumentasi secara otomatis 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), Entity Relationship Diagram (ERD), and general Documentation 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, ERD, Docs & Roadmap**: Automatically create a pre-filled PRD draft (`PRD.md`), an Entity Relationship Diagram (`ERD.md`), general Documentation (`DOKUMENTASI.md`), and a Roadmap document (`ROADMAP.md` or `PROGRESS.md`) based on the user's description.
+4. **Review**: Present to user for approval/edits.
+5. **Confirm**: Once the PRD, ERD, Documentation, and Roadmap are approved, proceed to `zero-to-prod-orchestrator` Phase 1.
+6. **Reference**: Cite the PRD, ERD, Documentation, and Roadmap in all subsequent code generation decisions.
+
+---
+
+<a name="bahasa-indonesia"></a>
+## Bahasa Indonesia
+
+### Deskripsi
+Guardrail wajib yang memaksa pembuatan secara otomatis Product Requirements Document (PRD) komprehensif, Entity Relationship Diagram (ERD), dan Dokumentasi 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, ERD, Dokumentasi & Roadmap**: Secara otomatis buat draf PRD (`PRD.md`), Entity Relationship Diagram (`ERD.md`), Dokumentasi umum (`DOKUMENTASI.md`), dan dokumen Roadmap (`ROADMAP.md` atau `PROGRESS.md`) yang sudah diisi berdasarkan deskripsi pengguna.
+4. **Tinjau**: Sajikan kepada pengguna untuk persetujuan/edit.
+5. **Konfirmasi**: Setelah PRD, ERD, Dokumentasi, dan Roadmap disetujui, lanjut ke `zero-to-prod-orchestrator` Fase 1.
+6. **Referensi**: Kutip PRD, ERD, Dokumentasi, dan Roadmap dalam semua keputusan pembuatan kode selanjutnya.
+
+---
+### 🎨 Automatic Visual Assets Generation Mandate (CRITICAL)
+**MANDATORY**: Whenever you are building a new application, scaffolding a project, or finalizing the initial UI/UX, you MUST automatically use the `generate_image` tool to create a custom logo that perfectly matches the application's core concept and aesthetic. 
+This generated image MUST be explicitly used as:
+1. The primary application logo (e.g., in the header/navbar).
+2. The website favicon (`favicon.ico` or equivalent).
+3. The Open Graph (OG) image for SEO metadata (`og:image`).
+
+Do not use placeholders for these assets. Generate and integrate them automatically.

package/skills/proactive-background-watcher/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: proactive-background-watcher
+description: "Grants the AI the ability to act proactively using native cron/timer scheduling. The agent can monitor systems, poll APIs, or watch logs in the background and self-trigger without waiting for user prompts."
+author: "Roedy Rustam"
+---
+
+# Proactive Background Watcher (Sentinel Agent)
+
+[English](#english) | [Bahasa Indonesia](#bahasa-indonesia)
+
+---
+
+<a name="english"></a>
+## English
+
+### Description
+Standard LLM chat interfaces (like Claude or ChatGPT) are purely reactive—they do nothing until the user types a prompt. This skill gives Antigravity the "superpower" of proactivity. By utilizing the native `schedule` tool, the agent can set up background cron jobs or timers to monitor logs, poll APIs, or check CI/CD pipelines. If an anomaly is detected, the agent wakes up autonomously and alerts the user or fixes the issue.
+
+### Trigger Conditions
+Activate this skill when:
+- The user says "let me know when the deployment finishes."
+- The user asks to "monitor the server for errors."
+- The user wants a daily summary of new GitHub issues.
+
+### Core Concepts
+
+#### 1. The Sentinel Loop
+1. **Schedule:** Use the `schedule` tool. Set either a `DurationSeconds` (e.g., check again in 5 minutes) or a `CronExpression` (e.g., run every hour `0 * * * *`). Set `IsDaemon=true` if it's a long-running background watcher.
+2. **Sleep:** End your turn. The system will automatically wake you up when the timer/cron fires.
+3. **Execute:** When woken up by the timer prompt, execute your checks (e.g., read a log file, curl an API).
+4. **Evaluate:** If everything is normal, go back to sleep (or set a new timer). If an anomaly is found, notify the user immediately with an alert.
+
+#### 2. Agent Constraints
+- **Do not spam the user.** If a background check passes normally, do not write a message to the user. Only alert the user if action is required or a long-running task finally completes.
+- **Always provide a clear Prompt in the schedule tool:** e.g., "Timer fired: Check Vercel deployment status now."
+
+---
+
+### Integration with Other Skills (MANDATORY)
+- `cron-scheduler-expert` — Provides the code-level knowledge for building app-level crons, while this skill is for the *agent's own* native scheduling.
+- `ci-cd-devops-architect` — Useful when the agent needs to watch GitHub Actions or Vercel pipelines.
+
+### Referenced By Orchestrators (MANDATORY)
+- `brainstorming` — Add to "Discovery & Audit".
+- `zero-to-prod-orchestrator` — Phase 7 (Deployment & Monitoring).
+
+---
+
+<a name="bahasa-indonesia"></a>
+## Bahasa Indonesia
+
+### Deskripsi
+LLM biasa (seperti Claude) sepenuhnya reaktif—diam sampai pengguna mengetik. Skill ini memberi Anda "kekuatan super" proaktif (Sentinel). Menggunakan tool `schedule`, Anda dapat menjadwalkan tugas *background* untuk memantau log, mengecek status *deployment*, atau mengawasi API secara berkala. Anda bisa "bangun sendiri" tanpa disuruh jika menemukan error.
+
+### Kondisi Pemicu
+- Saat pengguna berkata "tolong kabari saya kalau *build*-nya sudah selesai."
+- Saat pengguna meminta Anda mengawasi log error produksi.
+
+### Panduan Singkat
+- **Gunakan Tool `schedule`:** Anda bisa mengatur waktu tunggu (`DurationSeconds`) atau jadwal rutin (`CronExpression`).
+- **Tidur & Bangun Otomatis:** Setelah mengatur jadwal, hentikan pemanggilan tool. Sistem akan membangunkan Anda secara otomatis saat waktunya tiba.
+- **Jangan Cerewet (No Spam):** Jika Anda terbangun karena alarm dan mengecek log ternyata tidak ada error, **jangan** beri tahu pengguna. Biarkan pengguna bekerja dengan tenang. Hanya lapor jika ada error atau tugas besar telah selesai.

package/skills/production-ready-hardener/PRODUCTION_READINESS_REPORT.md

@@ -0,0 +1,67 @@
+# Production Readiness Report
+**Target:** `C:\Users\roedy\.gemini\config\plugins\vibes-plug\skills\production-ready-hardener`  
+**Date Check:** Current Date  
+**Overall Score:** `85/100` (`B+`)  
+**Status:** ⚠️ NEEDS MINOR FIXES
+
+## Executive Summary
+This report lists potential security vulnerabilities, code architecture errors, test coverage status, and build checks before release. Critical errors must be addressed immediately.
+## Phase Breakdown
+
+| Phase | Score | Critical | Warnings |
+|:---|:---:|:---:|:---:|
+| Architecture & Code Quality | `80/100` | 0 | 4 |
+| Frontend Hardening | `95/100` | 0 | 1 |
+| Backend Hardening | `90/100` | 0 | 2 |
+| Security Hardening | `80/100` | 1 | 0 |
+| Testing & Quality Assurance | `82/100` | 0 | 4 |
+| Performance & SEO | `87/100` | 0 | 4 |
+| DevOps & Deployment | `83/100` | 0 | 4 |
+
+## Detailed Checklist Items
+
+### Architecture & Code Quality
+- **Has organized source directory (src/ or app/)**: ❌ Failed (WARNING)
+- **TypeScript strict mode enabled**: ✅ Passed
+- **package.json exists**: ❌ Failed (WARNING)
+- **No TypeScript `any` types found**: ✅ Passed
+- **.env.example/env.example documents required config variables**: ❌ Failed (WARNING)
+- **Input validation library used (Zod/Joi/Yup)**: ❌ Failed (WARNING)
+- **TypeScript compiles without errors (0 errors)**: ✅ Passed
+
+### Frontend Hardening
+- **Frontend framework detected**: ❌ Failed (WARNING)
+
+### Backend Hardening
+- **Database migrations directory setup**: ❌ Failed (WARNING)
+- **Public routing endpoints ready**: ❌ Failed (WARNING)
+
+### Security Hardening
+- **.env included in .gitignore**: ❌ Failed (CRITICAL)
+- **No hardcoded private API keys/secrets in project files**: ✅ Passed
+- **No vulnerable string-interpolated SQL queries found**: ✅ Passed
+- **No unrestricted CORS wildcard access allowed in source**: ✅ Passed
+
+### Testing & Quality Assurance
+- **Unit test suite configured (Vitest/Jest)**: ❌ Failed (WARNING)
+- **E2E test suite configured (Playwright)**: ❌ Failed (WARNING)
+- **Linter configuration exists (eslint.config.js)**: ❌ Failed (WARNING)
+- **Git hooks config present**: ❌ Failed (WARNING)
+
+### Performance & SEO
+- **Sitemap exists or generated**: ❌ Failed (WARNING)
+- **robots.txt exists in public directory**: ❌ Failed (WARNING)
+- **User speed & web vitals tracking integrated**: ❌ Failed (WARNING)
+- **Progressive Web App (PWA) configuration present**: ❌ Failed (WARNING)
+
+### DevOps & Deployment
+- **GitHub Actions CI/CD workflows setup**: ❌ Failed (WARNING)
+- **Deployment configuration file exists**: ❌ Failed (WARNING)
+- **README.md contains instructions**: ❌ Failed (WARNING)
+- **CHANGELOG.md updated for release**: ❌ Failed (WARNING)
+- **Vite/Compiler build executes successfully (No build_errors.txt)**: ✅ Passed
+
+## 🚀 Quick Remediation Checklist
+Below are instructions to address the most urgent failures detected:
+
+- No immediate high-priority remediation templates needed. Fix individual warnings listed above.