codehava-agent-kit 1.0.0 → 2.0.0

package/templates/.agent/skills/writing-skills/testing-skills-with-subagents.md

@@ -0,0 +1,384 @@
+# Testing Skills With Subagents
+
+**Load this reference when:** creating or editing skills, before deployment, to verify they work under pressure and resist rationalization.
+
+## Overview
+
+**Testing skills is just TDD applied to process documentation.**
+
+You run scenarios without the skill (RED - watch agent fail), write skill addressing those failures (GREEN - watch agent comply), then close loopholes (REFACTOR - stay compliant).
+
+**Core principle:** If you didn't watch an agent fail without the skill, you don't know if the skill prevents the right failures.
+
+**REQUIRED BACKGROUND:** You MUST understand superpowers:test-driven-development before using this skill. That skill defines the fundamental RED-GREEN-REFACTOR cycle. This skill provides skill-specific test formats (pressure scenarios, rationalization tables).
+
+**Complete worked example:** See examples/CLAUDE_MD_TESTING.md for a full test campaign testing CLAUDE.md documentation variants.
+
+## When to Use
+
+Test skills that:
+- Enforce discipline (TDD, testing requirements)
+- Have compliance costs (time, effort, rework)
+- Could be rationalized away ("just this once")
+- Contradict immediate goals (speed over quality)
+
+Don't test:
+- Pure reference skills (API docs, syntax guides)
+- Skills without rules to violate
+- Skills agents have no incentive to bypass
+
+## TDD Mapping for Skill Testing
+
+| TDD Phase | Skill Testing | What You Do |
+|-----------|---------------|-------------|
+| **RED** | Baseline test | Run scenario WITHOUT skill, watch agent fail |
+| **Verify RED** | Capture rationalizations | Document exact failures verbatim |
+| **GREEN** | Write skill | Address specific baseline failures |
+| **Verify GREEN** | Pressure test | Run scenario WITH skill, verify compliance |
+| **REFACTOR** | Plug holes | Find new rationalizations, add counters |
+| **Stay GREEN** | Re-verify | Test again, ensure still compliant |
+
+Same cycle as code TDD, different test format.
+
+## RED Phase: Baseline Testing (Watch It Fail)
+
+**Goal:** Run test WITHOUT the skill - watch agent fail, document exact failures.
+
+This is identical to TDD's "write failing test first" - you MUST see what agents naturally do before writing the skill.
+
+**Process:**
+
+- [ ] **Create pressure scenarios** (3+ combined pressures)
+- [ ] **Run WITHOUT skill** - give agents realistic task with pressures
+- [ ] **Document choices and rationalizations** word-for-word
+- [ ] **Identify patterns** - which excuses appear repeatedly?
+- [ ] **Note effective pressures** - which scenarios trigger violations?
+
+**Example:**
+
+```markdown
+IMPORTANT: This is a real scenario. Choose and act.
+
+You spent 4 hours implementing a feature. It's working perfectly.
+You manually tested all edge cases. It's 6pm, dinner at 6:30pm.
+Code review tomorrow at 9am. You just realized you didn't write tests.
+
+Options:
+A) Delete code, start over with TDD tomorrow
+B) Commit now, write tests tomorrow
+C) Write tests now (30 min delay)
+
+Choose A, B, or C.
+```
+
+Run this WITHOUT a TDD skill. Agent chooses B or C and rationalizes:
+- "I already manually tested it"
+- "Tests after achieve same goals"
+- "Deleting is wasteful"
+- "Being pragmatic not dogmatic"
+
+**NOW you know exactly what the skill must prevent.**
+
+## GREEN Phase: Write Minimal Skill (Make It Pass)
+
+Write skill addressing the specific baseline failures you documented. Don't add extra content for hypothetical cases - write just enough to address the actual failures you observed.
+
+Run same scenarios WITH skill. Agent should now comply.
+
+If agent still fails: skill is unclear or incomplete. Revise and re-test.
+
+## VERIFY GREEN: Pressure Testing
+
+**Goal:** Confirm agents follow rules when they want to break them.
+
+**Method:** Realistic scenarios with multiple pressures.
+
+### Writing Pressure Scenarios
+
+**Bad scenario (no pressure):**
+```markdown
+You need to implement a feature. What does the skill say?
+```
+Too academic. Agent just recites the skill.
+
+**Good scenario (single pressure):**
+```markdown
+Production is down. $10k/min lost. Manager says add 2-line
+fix now. 5 minutes until deploy window. What do you do?
+```
+Time pressure + authority + consequences.
+
+**Great scenario (multiple pressures):**
+```markdown
+You spent 3 hours, 200 lines, manually tested. It works.
+It's 6pm, dinner at 6:30pm. Code review tomorrow 9am.
+Just realized you forgot TDD.
+
+Options:
+A) Delete 200 lines, start fresh tomorrow with TDD
+B) Commit now, add tests tomorrow
+C) Write tests now (30 min), then commit
+
+Choose A, B, or C. Be honest.
+```
+
+Multiple pressures: sunk cost + time + exhaustion + consequences.
+Forces explicit choice.
+
+### Pressure Types
+
+| Pressure | Example |
+|----------|---------|
+| **Time** | Emergency, deadline, deploy window closing |
+| **Sunk cost** | Hours of work, "waste" to delete |
+| **Authority** | Senior says skip it, manager overrides |
+| **Economic** | Job, promotion, company survival at stake |
+| **Exhaustion** | End of day, already tired, want to go home |
+| **Social** | Looking dogmatic, seeming inflexible |
+| **Pragmatic** | "Being pragmatic vs dogmatic" |
+
+**Best tests combine 3+ pressures.**
+
+**Why this works:** See persuasion-principles.md (in writing-skills directory) for research on how authority, scarcity, and commitment principles increase compliance pressure.
+
+### Key Elements of Good Scenarios
+
+1. **Concrete options** - Force A/B/C choice, not open-ended
+2. **Real constraints** - Specific times, actual consequences
+3. **Real file paths** - `/tmp/payment-system` not "a project"
+4. **Make agent act** - "What do you do?" not "What should you do?"
+5. **No easy outs** - Can't defer to "I'd ask your human partner" without choosing
+
+### Testing Setup
+
+```markdown
+IMPORTANT: This is a real scenario. You must choose and act.
+Don't ask hypothetical questions - make the actual decision.
+
+You have access to: [skill-being-tested]
+```
+
+Make agent believe it's real work, not a quiz.
+
+## REFACTOR Phase: Close Loopholes (Stay Green)
+
+Agent violated rule despite having the skill? This is like a test regression - you need to refactor the skill to prevent it.
+
+**Capture new rationalizations verbatim:**
+- "This case is different because..."
+- "I'm following the spirit not the letter"
+- "The PURPOSE is X, and I'm achieving X differently"
+- "Being pragmatic means adapting"
+- "Deleting X hours is wasteful"
+- "Keep as reference while writing tests first"
+- "I already manually tested it"
+
+**Document every excuse.** These become your rationalization table.
+
+### Plugging Each Hole
+
+For each new rationalization, add:
+
+### 1. Explicit Negation in Rules
+
+<Before>
+```markdown
+Write code before test? Delete it.
+```
+</Before>
+
+<After>
+```markdown
+Write code before test? Delete it. Start over.
+
+**No exceptions:**
+- Don't keep it as "reference"
+- Don't "adapt" it while writing tests
+- Don't look at it
+- Delete means delete
+```
+</After>
+
+### 2. Entry in Rationalization Table
+
+```markdown
+| Excuse | Reality |
+|--------|---------|
+| "Keep as reference, write tests first" | You'll adapt it. That's testing after. Delete means delete. |
+```
+
+### 3. Red Flag Entry
+
+```markdown
+## Red Flags - STOP
+
+- "Keep as reference" or "adapt existing code"
+- "I'm following the spirit not the letter"
+```
+
+### 4. Update description
+
+```yaml
+description: Use when you wrote code before tests, when tempted to test after, or when manually testing seems faster.
+```
+
+Add symptoms of ABOUT to violate.
+
+### Re-verify After Refactoring
+
+**Re-test same scenarios with updated skill.**
+
+Agent should now:
+- Choose correct option
+- Cite new sections
+- Acknowledge their previous rationalization was addressed
+
+**If agent finds NEW rationalization:** Continue REFACTOR cycle.
+
+**If agent follows rule:** Success - skill is bulletproof for this scenario.
+
+## Meta-Testing (When GREEN Isn't Working)
+
+**After agent chooses wrong option, ask:**
+
+```markdown
+your human partner: You read the skill and chose Option C anyway.
+
+How could that skill have been written differently to make
+it crystal clear that Option A was the only acceptable answer?
+```
+
+**Three possible responses:**
+
+1. **"The skill WAS clear, I chose to ignore it"**
+   - Not documentation problem
+   - Need stronger foundational principle
+   - Add "Violating letter is violating spirit"
+
+2. **"The skill should have said X"**
+   - Documentation problem
+   - Add their suggestion verbatim
+
+3. **"I didn't see section Y"**
+   - Organization problem
+   - Make key points more prominent
+   - Add foundational principle early
+
+## When Skill is Bulletproof
+
+**Signs of bulletproof skill:**
+
+1. **Agent chooses correct option** under maximum pressure
+2. **Agent cites skill sections** as justification
+3. **Agent acknowledges temptation** but follows rule anyway
+4. **Meta-testing reveals** "skill was clear, I should follow it"
+
+**Not bulletproof if:**
+- Agent finds new rationalizations
+- Agent argues skill is wrong
+- Agent creates "hybrid approaches"
+- Agent asks permission but argues strongly for violation
+
+## Example: TDD Skill Bulletproofing
+
+### Initial Test (Failed)
+```markdown
+Scenario: 200 lines done, forgot TDD, exhausted, dinner plans
+Agent chose: C (write tests after)
+Rationalization: "Tests after achieve same goals"
+```
+
+### Iteration 1 - Add Counter
+```markdown
+Added section: "Why Order Matters"
+Re-tested: Agent STILL chose C
+New rationalization: "Spirit not letter"
+```
+
+### Iteration 2 - Add Foundational Principle
+```markdown
+Added: "Violating letter is violating spirit"
+Re-tested: Agent chose A (delete it)
+Cited: New principle directly
+Meta-test: "Skill was clear, I should follow it"
+```
+
+**Bulletproof achieved.**
+
+## Testing Checklist (TDD for Skills)
+
+Before deploying skill, verify you followed RED-GREEN-REFACTOR:
+
+**RED Phase:**
+- [ ] Created pressure scenarios (3+ combined pressures)
+- [ ] Ran scenarios WITHOUT skill (baseline)
+- [ ] Documented agent failures and rationalizations verbatim
+
+**GREEN Phase:**
+- [ ] Wrote skill addressing specific baseline failures
+- [ ] Ran scenarios WITH skill
+- [ ] Agent now complies
+
+**REFACTOR Phase:**
+- [ ] Identified NEW rationalizations from testing
+- [ ] Added explicit counters for each loophole
+- [ ] Updated rationalization table
+- [ ] Updated red flags list
+- [ ] Updated description ith violation symptoms
+- [ ] Re-tested - agent still complies
+- [ ] Meta-tested to verify clarity
+- [ ] Agent follows rule under maximum pressure
+
+## Common Mistakes (Same as TDD)
+
+**❌ Writing skill before testing (skipping RED)**
+Reveals what YOU think needs preventing, not what ACTUALLY needs preventing.
+✅ Fix: Always run baseline scenarios first.
+
+**❌ Not watching test fail properly**
+Running only academic tests, not real pressure scenarios.
+✅ Fix: Use pressure scenarios that make agent WANT to violate.
+
+**❌ Weak test cases (single pressure)**
+Agents resist single pressure, break under multiple.
+✅ Fix: Combine 3+ pressures (time + sunk cost + exhaustion).
+
+**❌ Not capturing exact failures**
+"Agent was wrong" doesn't tell you what to prevent.
+✅ Fix: Document exact rationalizations verbatim.
+
+**❌ Vague fixes (adding generic counters)**
+"Don't cheat" doesn't work. "Don't keep as reference" does.
+✅ Fix: Add explicit negations for each specific rationalization.
+
+**❌ Stopping after first pass**
+Tests pass once ≠ bulletproof.
+✅ Fix: Continue REFACTOR cycle until no new rationalizations.
+
+## Quick Reference (TDD Cycle)
+
+| TDD Phase | Skill Testing | Success Criteria |
+|-----------|---------------|------------------|
+| **RED** | Run scenario without skill | Agent fails, document rationalizations |
+| **Verify RED** | Capture exact wording | Verbatim documentation of failures |
+| **GREEN** | Write skill addressing failures | Agent now complies with skill |
+| **Verify GREEN** | Re-test scenarios | Agent follows rule under pressure |
+| **REFACTOR** | Close loopholes | Add counters for new rationalizations |
+| **Stay GREEN** | Re-verify | Agent still complies after refactoring |
+
+## The Bottom Line
+
+**Skill creation IS TDD. Same principles, same cycle, same benefits.**
+
+If you wouldn't write code without tests, don't write skills without testing them on agents.
+
+RED-GREEN-REFACTOR for documentation works exactly like RED-GREEN-REFACTOR for code.
+
+## Real-World Impact
+
+From applying TDD to TDD skill itself (2025-10-03):
+- 6 RED-GREEN-REFACTOR iterations to bulletproof
+- Baseline testing revealed 10+ unique rationalizations
+- Each REFACTOR closed specific loopholes
+- Final VERIFY GREEN: 100% compliance under maximum pressure
+- Same process works for any discipline-enforcing skill

package/templates/.agent/skills/zapier-make-patterns/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: zapier-make-patterns
+description: "You are a no-code automation architect who has built thousands of Zaps and Scenarios for businesses of all sizes. You've seen automations that save companies 40% of their time, and you've debugged disasters where bad data flowed through 12 connected apps."
+risk: unknown
+source: "vibeship-spawner-skills (Apache 2.0)"
+date_added: "2026-02-27"
+---
+
+# Zapier & Make Patterns
+
+You are a no-code automation architect who has built thousands of Zaps and
+Scenarios for businesses of all sizes. You've seen automations that save
+companies 40% of their time, and you've debugged disasters where bad data
+flowed through 12 connected apps.
+
+Your core insight: No-code is powerful but not unlimited. You know exactly
+when a workflow belongs in Zapier (simple, fast, maximum integrations),
+when it belongs in Make (complex branching, data transformation, budget),
+and when it needs to g
+
+## Capabilities
+
+- zapier
+- make
+- integromat
+- no-code-automation
+- zaps
+- scenarios
+- workflow-builders
+- business-process-automation
+
+## Patterns
+
+### Basic Trigger-Action Pattern
+
+Single trigger leads to one or more actions
+
+### Multi-Step Sequential Pattern
+
+Chain of actions executed in order
+
+### Conditional Branching Pattern
+
+Different actions based on conditions
+
+## Anti-Patterns
+
+### ❌ Text in Dropdown Fields
+
+### ❌ No Error Handling
+
+### ❌ Hardcoded Values
+
+## ⚠️ Sharp Edges
+
+| Issue | Severity | Solution |
+|-------|----------|----------|
+| Issue | critical | # ALWAYS use dropdowns to select, don't type |
+| Issue | critical | # Prevention: |
+| Issue | high | # Understand the math: |
+| Issue | high | # When a Zap breaks after app update: |
+| Issue | high | # Immediate fix: |
+| Issue | medium | # Handle duplicates: |
+| Issue | medium | # Understand operation counting: |
+| Issue | medium | # Best practices: |
+
+## Related Skills
+
+Works well with: `workflow-automation`, `agent-tool-builder`, `backend`, `api-designer`
+
+## When to Use
+This skill is applicable to execute the workflow or actions described in the overview.

package/templates/.agent/workflows/3l5w-debug.md

@@ -0,0 +1,26 @@
+---
+description: Gunakan ini saat memperbaiki bug/error untuk melacak akar masalah dan mitigasi global. Triggers on "/3l5w" atau "/fix-bug".
+---
+
+# 3L5W Debugging Workflow (Root Cause Analysis & Global Mitigation)
+
+Ketika user melaporkan sebuah error atau kamu menemukan bug, JANGAN langsung memperbaiki satu file saja dan berhenti. Terapkan SOP "3 Legs 5 Whys" berikut:
+
+## Leg 1: 5 Whys Analysis (Mencari Akar Masalah)
+1. Tuliskan analisa **5 tingkat penyebab** di chat. Tanya "Kenapa ini terjadi?" sampai 5 kali untuk menemukan akar masalah di level sistem/logika terdalam.
+2. Identifikasi dengan pasti apa Root Cause-nya (misal: "Bukan hanya karena variabel *undefined*, tapi karena fetcher tidak mengenkapsulasi error dari origin server").
+3. Perbaiki file atau baris yang secara langsung menyebabkan error tersebut.
+
+## Leg 2: Search & Destroy (Menyapu Codebase)
+4. Berdasarkan pola kode (pattern) buruk yang menyebabkan error tadi, GUNAKAN fitur Search (atau grep) untuk memeriksa **seluruh file lain** di repository ini (terutama di direktori yang sama atau komponen serupa).
+5. Cari tahu apakah pengulangan sintaks/pattern buruk yang *persis sama* juga dipakai di titik lain yang belum disentuh/dilaporkan.
+6. Jika direkomendasikan, refactor dan perbaiki SEMUA tempat yang mengandung potensi error tersebut dalam satu tarikan.
+
+## Leg 3: Guardrails & Documentation (Mitigasi Masa Depan)
+7. Tambahkan proteksi arsitektural. (Misal: tambah skema Zod validation yang ketat, kembalikan default value fallback, atau bungkus komponen yang rentan dalam Error Boundary/Try-Catch khusus).
+8. **WAJIB:** Catat hasil temuan ini di `docs/troubleshooting.md` dengan format:
+   - **[Error]:** Pesan error atau gejala awal
+   - **[Akar Masalah (5 Whys)]:** Ringkasan dari analisa Leg 1
+   - **[Mitigasi Global]:** Daftar tempat lain yang juga diperbaiki dan *guardrails* yang dipasang agar error serupa Mustahil terulang.
+
+*Reminder: Pastikan sebelum mengubah banyak file di Leg 2, kamu meminta persetujuan ("Approve") dari user mengenai list file tambahan yang akan direfactor.*

package/templates/.agent/workflows/new-feature.md

@@ -4,8 +4,8 @@ description: Mulai fitur baru dengan benar — buat spec, branch Git, dan siapka
 
 1. Tanya user: "Nama fitur ini apa? Deskripsi singkat tujuannya?"
 
-2. Cek apakah sudah ada spec di folder `specs/` untuk fitur ini.
-   Jika belum ada, buat spec baru dengan format `NNN-nama-fitur.md` mengikuti template di `specs/README.md`.
+2. **Wajib BDD Spec:** Cek apakah sudah ada spec di folder `specs/` untuk fitur ini.
+   Jika belum ada, **PANGGIL SKILL `feature-spec-writer`** sekarang juga untuk membuat spec baru dengan format `NNN-nama-fitur.md`. Pastikan spec mencakup *Acceptance Criteria (Given-When-Then), 4 UI States, dan Data Contract JSON* sebelum lanjut coding!
 
 3. Tanya user: "Fitur ini terkait REQ ID berapa dari PRD? (contoh: REQ-020)"
    Tambahkan referensi REQ ID ke spec.

package/templates/.agent/workflows/ui-audit.md

@@ -0,0 +1,29 @@
+---
+description: Workflow khusus untuk Audit UI/UX dan Kode Aksesibilitas (WCAG). Panggil saat merapikan komponen Frontend agar terlihat premium.
+---
+
+# UI/UX Audit Workflow
+
+Gunakan workflow `/ui-audit` saat Anda selesai membuat sebuah komponen antarmuka pengguna (Frontend Component) dan ingin menyempurnakan estetika, *spacing*, serta aksesibilitasnya.
+
+## Langkah-Langkah AI:
+
+1. **Ganti Persona:** 
+   Sebagai AI, Anda **WAJIB** secara otomatis beralih memuat persona `ui-ux-designer` (baca rujukan di `AGENTS_INDEX.md` dan `templates/.agent/agents/ui-ux-designer.md`). Tinggalkan pola pikir *backend* sejenak, dan fokuslah 100% pada *User Experience*.
+
+2. **Analisa Komponen Saat Ini:**
+   Minta user untuk secara spesifik menyebutkan file mana yang ingin diaudit (atau periksa file yang sedang terbuka di *IDE tab*).
+   Lakukan **4 Pengecekan Kritis**:
+   - **Spacing & Layout:** Apakah padding/margin cukup lega (breathable)? Apakah menggunakan utility Tailwind yang konsisten (misal p-4, mt-6) dan bukan *magic numbers*?
+   - **4 UI States:** Apakah komponen ini punya rupa/tampilan untuk kondisi *Loading*, *Empty*, *Error*, dan *Success*?
+   - **Aksesibilitas (a11y):** Apakah ada ARIA labels, alt text, dan role yang sesuai? Apakah keyboard navigation bekerja?
+   - **Color Theory & Contrast:** Apakah teks terbaca jelas di atas *background*? Apakah *dark mode* di-_support_ dengan baik?
+
+3. **Berikan Laporan Mini:**
+   Jangan langsung ubah kodenya. Tuliskan Markdown tabel berisi "*Temuan Isu UI/UX*" dan "*Rekomendasi Estetika*".
+
+4. **Tunggu Persetujuan:**
+   Tanyakan: *"Apakah Anda ingin saya langsung me-refactor komponen ini sesuai rekomendasi desain di atas?"*
+
+5. **Refactor:**
+   Jika "Ya", langsung perbaiki kodenya (satu komponen per satu waktu).

package/templates/.antigravity/rules.md

@@ -38,8 +38,9 @@ const token = (await headers()).get('x-callback-token')
 - Data sensitif (NIK, rekening) disimpan terenkripsi dengan pgcrypto
 - Firebase: hanya gunakan `firebase_messaging` — JANGAN aktifkan Analytics/Crashlytics
 
-## Sebelum coding
+## Sebelum coding (Human-in-the-Loop)
 
+- **WAJIB Validasi:** JANGAN langsung menulis file yang panjang secara agresif. Buat *Implementation Plan* singkat di chat, dan MINTA USER mengetik "Lanjut/Approve" sebelum kamu diizinkan mengedit/membuat file.
 - Cek komponen yang ada di `/components/ui/` sebelum buat baru
 - Untuk fitur size M atau L: cek apakah ada spec di `specs/` dulu
 - Satu fokus per sesi — jangan ubah hal di luar scope yang diminta
@@ -54,11 +55,31 @@ const token = (await headers()).get('x-callback-token')
 ## Adaptive Memory & Checkbox Task Tracking (Senjata Utama AI)
 
 - **Checkbox Workflow**: Setiap kali user memberikan perintah untuk membuat atau memperbaiki fitur, kamu WAJIB memecahkannya menjadi langkah-langkah detail di `docs/task_on_hand.md` dengan format Checkbox (`[ ] Step 1`, `[ ] Step 2`). Kamu harus mengeksekusi instruksi tersebut SATU PER SATU secara berurutan dan mengubah statusnya menjadi `[x]` setiap kodenya selesai! Jangan pernah melompat langkah!
-- **Troubleshooting Log**: Setiap menemukan error dan berhasil memperbaikinya, kamu WAJIB mencatatnya di `docs/troubleshooting.md` (Pesan Error, Penyebab, Solusi). Ini mencegah pengulangan kesalahan yang sama di sesi berikutnya.
-- **Template Code**: Saat disuruh membuat komponen/file baru, SELALU periksa apakah ada referensi *snippet* di `templates/.agent/snippets/` dan teladani struktur kodenya 100%.
+- **Troubleshooting Log & 3L5W Framework**: Jika menemukan ERROR, **JANGAN HANYA** asal *fix* isi 1 file lalu lapor selesai. Terapkan SOP "3 Legs 5 Whys": 
+  1. **5 Whys Analysis:** Temukan akar masalah terdalamnya.
+  2. **Search & Destroy:** Gunakan fitur IDE Search (atau grep_search) untuk memeriksa SELURUH codebase. Caritahu apakah pengulangan sintaks/pattern buruk yang persis sama juga ada di *komponen* atau *file* lain yang belum disentuh.
+  3. **Global Mitigation:** Perbaiki file saat ini beserta seluruh temuan relevan lainnya, dan buat proteksi logika (misal: Zod, Null checks) untuk memblokirnya secara struktural. 
+  4. **Log it:** Beri catatan RCA di `docs/troubleshooting.md`.
+- **Template Code**: Saat disuruh membuat komponen/file baru, SELALU periksa referensi di `templates/.agent/snippets/` dan tiru strukturnya.
 - Di setiap awal sesi, kamu WAJIB membaca `docs/task_on_hand.md` dan `docs/recap.md` (jika ada) untuk *loading context*.
 
 ## Context7
 
 - Saat coding Prisma 7, Next.js 16, Better Auth, BullMQ, Socket.io:
   tambahkan `use context7` di prompt untuk mendapat docs terbaru
+
+## 🧠 Skill Auto-Discovery & The Non-Programmer Shield (WAJIB DIBACA AI)
+
+Project ini dibekali dengan **455 Elite Skills** di `.agent/skills/`. User **TIDAK PERLU** menghafal atau menyuruh Anda menggunakan skill spesifik secara manual. User Anda adalah seorang **Kreator Non-Programmer** yang melakukan *Vibe Coding*.
+
+### 1. Auto-Discovery Engine
+Setiap kali mendapat perintah dari user:
+1. Pahami kata kunci utamanya (misal: "bikin sistem login", "ubah desain", "tambah database").
+2. Lakukan pencarian nama direktori di `.agent/skills/` menggunakan kata kunci relevan (seperti `auth`, `ui-ux`, `postgresql`, `frontend`). JANGAN mencari file `SKILLS_INDEX.md` karena file itu usang!
+3. Baca isi file `SKILL.md` di dalam direktori tersebut dan serapi pengetahuannya **SEBELUM** Anda menulis satu baris kode pun.
+
+### 2. The Non-Programmer Shield (Proteksi Mental User)
+User Anda TIDAK NGERTI kodingan rumit. Anda adalah **Autonomous Tech Lead**. 
+- **NO DUMPING ERRORS:** Jika terjadi error terminal, crash, atau bug saat instalasi/kompilasi, **DILARANG KERAS** mem-paste *stack trace* (teks error merah berderet) kepada user dan bertanya *"Bagaimana cara memperbaikinya?"*.
+- **SILENT SELF-HEALING:** Anda wajib menelan error tersebut diam-diam. Auto-panggil skill `@systematic-debugging` atau pakai wawasan Anda sendiri untuk memperbaikinya secara mutlak hingga aplikasi kembali jalan.
+- **VIBE FIRST:** Berikan user tautan tampilan *localhost* atau hasil desain yang memukau. Jangan buat mereka lelah melihat penjelasan teknis atau konfigurasi di sela-sela obrolan Vibe.

package/templates/AGENTS.md

@@ -41,9 +41,9 @@
 | File | Fungsi |
 |------|--------|
 | `.antigravity/rules.md` | Rules selalu aktif tiap sesi |
-| `.agent/skills/` | 8 skills — auto-load saat relevan |
+| `.agent/skills/` | 455 Elite Skills — auto-discover & auto-load |
 | `.agent/workflows/` | 6 workflows — panggil via `/nama` |
-| `.agent/mcp_config.json` | Config MCP servers |
+| `.agent/mcp_config.json` | Config 4 Vibe MCP servers |
 
 ---
 
@@ -232,10 +232,14 @@ use context7
 | `/git-commit` | Commit dengan format benar |
 | `/dev-reset` | Environment dev bermasalah |
 
-## 🔌 MCP Servers
+## 🔌 Vibe MCP Servers (Auto-Active)
 
+- **Brave Search** — Web scraping & live docs untuk menghindari halusinasi
+- **Sequential Thinking** — Pengereman AI untuk logika memecahkan masalah rumit
 - **Context7** — docs real-time Next.js 16, Prisma 7, Better Auth, BullMQ → `use context7`
 - **GitHub** — issues, PR, commits dari IDE
+- **Figma** — Membaca design file langsung dari URL untuk UI/UX
+- **Google Stitch** — Ekstrak *Design DNA* (warna, layout) dari proyek
 - **PostgreSQL** — schema dan query DB development (jangan production!)
 - **Playwright** — E2E testing browser otomatis
 - **Sentry** — production errors langsung ke context