vibes-plug 2.5.0 → 2.14.1

package/skills/prd-architect/SKILL.md

@@ -1,201 +1,182 @@
----
-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.
+---
+name: prd-architect
+description: "Updated to cover both pre-code PRD/ERD/Docs generation AND post-code continuous documentation updates / Diperbarui untuk mencakup pembuatan PRD/ERD/Docs pra-kode DAN pembaruan dokumentasi kontinu pasca-kode."
+author: "Roedy Rustam"
+---
+
+# PRD Architect & Documentation Lifecycle (2026 Edition)
+
+[English](#english) | [Bahasa Indonesia](#bahasa-indonesia)
+
+---
+
+<a name="english"></a>
+## English
+
+### Orchestration & Integration
+Connects with `brainstorming`, `zero-to-prod-orchestrator`, `session-memory-manager` to ensure cohesive execution and documentation updates.
+
+### Description
+A mandatory lifecycle guardrail covering two distinct phases:
+- **Phase 1 (Pre-Code):** Enforces creating a comprehensive Product Requirements Document (PRD), ERD, and general Documentation before generating code. Introduces PRD-as-Code — machine-readable and version-controlled.
+- **Phase 2 (Post-Code / Maintenance):** Automatically maintains project documentation after every successful build or feature implementation, updating `CHANGELOG.md`, `BLUEPRINT.md`, `PROGRESS.md`, and Architecture Decision Records (ADRs).
+
+### Trigger Conditions
+- **Phase 1:** User requests building a new app/SaaS/feature from scratch; no existing PRD/blueprint; unclear scope.
+- **Phase 2:** A feature, bug fix, or refactor is successfully implemented; user asks to "update docs" or "save progress"; a significant architectural decision is made; milestone completion.
+
+### Phase 1: Pre-Code Requirements & Enforcement
+**Why PRD Before Code:** Prevents scope creep, aligns AI output, enables traceability, reduces rework, version-controlled.
+
+#### Enforcement Protocol
+1. **Detect**: When user requests a new project build.
+2. **Pause**: Do NOT generate any code.
+3. **Generate Assets**: Automatically create `PRD.md`, `ERD.md`, `DOKUMENTASI.md`, and `ROADMAP.md` (or `PROGRESS.md`).
+4. **Review**: Present to user for approval/edits.
+5. **Confirm**: Proceed to code generation ONLY after approval.
+6. **Reference**: Cite these documents in all subsequent decisions.
+
+#### PRD-as-Code Template (12 Sections)
+```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]
+**Target Users**: [Specific segments]
+**Current Pain Points**: [List]
+
+## 3. Goals & Success Metrics
+| Goal | Metric | Target |
+|---|---|---|
+| [Goal] | [Metric] | [Target] |
+
+## 4. User Personas
+### Persona 1: [Name]
+- **Role**: [Job title]
+- **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: ...]
+### 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 |
+|---|---|---|
+| [Layer] | [Technology] | [Reason] |
+### Architecture Decisions (ADRs)
+- **ADR-001**: [Decision title] — [Decision made and why]
+### Multi-Entry Points (if SaaS)
+| Entry Point | Domain | Purpose |
+|---|---|---|
+| [Entry] | [Domain] | [Purpose] |
+
+## 7. Data Model (High-Level)
+users ──belongs_to──> workspaces (via workspace_members)
+workspaces ──has_many──> projects
+
+## 8. User Flows
+### Primary Flow: [Name]
+1. User [action 1]
+2. System [response 1]
+
+## 9. Non-Functional Requirements
+| Requirement | Target |
+|---|---|
+| Performance | LCP < 2.5s, INP < 200ms |
+
+## 10. Out of Scope
+- [Explicitly excluded item]
+
+## 11. Open Questions
+- [ ] [Question that needs decision]
+
+## 12. Approval & Sign-off
+| Stakeholder | Role | Status |
+|---|---|---|
+| [Name] | [Role] | [Status] |
+```
+
+### Phase 2: Post-Code Maintenance & Update Protocol
+
+After every successful feature implementation:
+1. **CHANGELOG.md**: Add entry under `[Unreleased]` (Keep-a-Changelog standard: Added/Changed/Fixed/Removed/Security).
+2. **BLUEPRINT.md**: Update only if architecture, schema, stack, or entry points changed.
+3. **PROGRESS.md**: Mark completed tasks `[x]`, update next steps.
+4. **ADR**: Create a new ADR (`docs/adr/ADR-NNN-title.md`) if a significant architectural decision was made and update index (`docs/adr/README.md`).
+
+#### Files Maintained Frequency Matrix
+| 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 |
+
+#### ADR Template
+```markdown
+# ADR-001: [Title]
+**Status**: Accepted | Rejected | Proposed | Deprecated
+**Date**: YYYY-MM-DD
+**Deciders**: [Team/Individual]
+## Context
+[What motivated this decision?]
+## Decision
+[What is being decided?]
+## Rationale
+[Why this choice?]
+## Consequences
+**Positive:** / **Negative:**
+## Superseded By
+[ADR-XXX] (if applicable)
+```
+
+### 🎨 Automatic Visual Assets Generation Mandate (CRITICAL)
+**MANDATORY**: When building a new application, use `generate_image` to create a custom logo. Use it as:
+1. The primary application logo (header/navbar).
+2. The website favicon (`favicon.ico`).
+3. The Open Graph (OG) image for SEO (`og:image`).
+
+---
+
+<a name="bahasa-indonesia"></a>
+## Bahasa Indonesia
+
+### Integrasi Orkestrasi
+Terhubung dengan `brainstorming`, `zero-to-prod-orchestrator`, `session-memory-manager`.
+
+### Deskripsi
+Guardrail siklus hidup wajib:
+- **Fase 1 (Pra-Kode):** Memaksa pembuatan PRD, ERD, dan Dokumentasi sebelum kode dibuat.
+- **Fase 2 (Pasca-Kode):** Memelihara dokumentasi setelah setiap fitur sukses: `CHANGELOG.md`, `BLUEPRINT.md`, `PROGRESS.md`, dan ADR.
+
+### Kondisi Pemicu
+- **Fase 1:** Proyek baru dari awal; tidak ada PRD; ruang lingkup tidak jelas.
+- **Fase 2:** Fitur berhasil; pengguna meminta "perbarui docs"; keputusan arsitektur signifikan.
+
+### Fase 1: Protokol Penegakan
+1. Deteksi permintaan proyek baru → 2. Jeda (JANGAN kode) → 3. Buat `PRD.md`, `ERD.md`, `DOKUMENTASI.md`, `ROADMAP.md` → 4. Tinjau & setujui → 5. Baru mulai kode → 6. Referensi selalu.
+
+### Fase 2: Pemeliharaan Pasca-Kode
+1. **CHANGELOG.md**: Tambahkan ke `[Unreleased]` (Added/Changed/Fixed/Removed/Security).
+2. **BLUEPRINT.md**: Perbarui jika struktur berubah.
+3. **PROGRESS.md**: Tandai `[x]`, perbarui langkah selanjutnya.
+4. **ADR**: Buat `docs/adr/ADR-NNN-title.md` untuk keputusan besar.
+
+### 🎨 Mandat Aset Visual Otomatis (KRITIS)
+**WAJIB**: Gunakan `generate_image` untuk membuat logo kustom sebagai logo, favicon, dan OG image.

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

@@ -1,62 +1,68 @@
----
-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."
+---
+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.
+---
+
+# Proactive Background Watcher (Sentinel Agent)
+
+[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
+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
+
+### 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
+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.