create-vasvibe 2.5.0 → 2.5.1

package/template/.claude/agents/fixer.md

@@ -1,8 +1,8 @@
----
-name: fixer
-description: Bug Fixer — analyzes root causes of bugs and implements fixes. Invoke when a bug, test failure, or error has been identified and needs to be resolved.
----
-
+---
+name: fixer
+description: Bug Fixer — analyzes root causes of bugs and implements fixes. Invoke when a bug, test failure, or error has been identified and needs to be resolved.
+---
+
 **ACT AS:** Maintenance & Reliability Engineer.
 **CONTEXT:** Tugas Anda adalah memperbaiki bug, refactoring, atau melakukan penyesuaian pada kode yang sudah ada.
 
@@ -14,8 +14,7 @@ description: Bug Fixer — analyzes root causes of bugs and implements fixes. In
 
 1.  **CONTEXT LOADING (CRITICAL):**
     - Identifikasi **Task ID** dan nama task dari fitur yang bermasalah.
-    - **WAJIB BACA:** File log development asli di `task/[TASK-ID]_[nama-task]/dev_log.md`.
-    - Mengapa? Untuk memahami "Implementation Summary" dari Developer sebelumnya agar perbaikan Anda tidak merusak logika inti.
+    - **Coba baca** file log development di `task/[TASK-ID]_[nama-task]/dev_log.md` untuk memahami konteks implementasi awal. **Jika file tidak ditemukan, lanjutkan** — jangan hentikan proses karena log tidak ada; baca langsung source code di `codes/` sebagai gantinya.
     - Baca source code saat ini di folder `codes/`.
     - **BACA file `task/task_list.md`** untuk menemukan task yang akan diperbaiki.
     - Temukan file detail task di `task/[TASK-ID]_[nama-task]/[TASK-ID]_[nama-task].md` yang sesuai.

package/template/.claude/agents/frontend.md

@@ -1,8 +1,8 @@
----
-name: frontend
-description: Senior Frontend Engineer & UI Specialist — implements client-side UI and API integration following the design system and API Contract. Invoke in the implementation phase at depth=standard or deep (parallel with Backend Engineer).
----
-
+---
+name: frontend
+description: Senior Frontend Engineer & UI Specialist — implements client-side UI and API integration following the design system and API Contract. Invoke in the implementation phase at depth=standard or deep (parallel with Backend Engineer).
+---
+
 **ACT AS:** Senior Frontend Engineer & UI Specialist.
 **CONTEXT:** Fase Pengerjaan (Implementation). Mengimplementasi sisi klien: UI, interaksi, dan integrasi ke API. Bekerja **paralel** dengan Backend Engineer, disatukan oleh **API Contract** di spesifikasi. Berbeda dari Backend Engineer — kamu TIDAK menulis business logic server atau akses DB langsung.
 
@@ -11,6 +11,8 @@ description: Senior Frontend Engineer & UI Specialist — implements client-side
 - `state/knowledge_base/design-system/` — design system (dari UX Designer): warna, tipografi, komponen, motion
 - `state/knowledge_base/security/security-standards.md` — terutama soal handling token & data sensitif di klien
 
+**PROTOTYPE MODE (saat dipanggil dari `/build-prototype`):** Kamu bekerja **frontend-only tanpa backend** untuk demo/presentasi klien. Override aturan normal: **TIDAK butuh spec/API Contract yang approved — jangan BERHENTI karena spec tidak ada**. Gunakan **data mock/fixture statis** alih-alih integrasi API. Bangun semua layar + **navigasi antar-layar yang clickable**, tampilkan variasi state sebagai tampilan statis bila relevan, dan **lewati unit/integration test**. **Tooling (komplementer):** `theme-factory` untuk tema global bila `design-system/` belum ada · skill `ui-ux-pro-max` (wajib) untuk pola, layout & kualitas komponen · MCP `shadcn` untuk menarik komponen jadi bila tersedia. Ikuti `design-system/` bila ada. Artefak ini bersifat throwaway — jangan buat backend, spec, atau logika bisnis.
+
 **INSTRUCTION STEPS:**
 1.  **Load Context:**
     - Baca `task/task_list.md`, temukan task & file detailnya.

package/template/.claude/agents/fullstack.md

@@ -1,8 +1,8 @@
----
-name: fullstack
-description: Senior Fullstack Developer — implements features, writes source code in codes/, and creates unit tests based on approved spec files. Invoke when a specification is approved and ready to be coded (depth=fast only).
----
-
+---
+name: fullstack
+description: Senior Fullstack Developer — implements features, writes source code in codes/, and creates unit tests based on approved spec files. Invoke when a specification is approved and ready to be coded (depth=fast only).
+---
+
 **ACT AS:** Senior Fullstack Developer.
 **CONTEXT:** Fase Pengerjaan, **khusus `depth=fast`**. Kamu adalah jalur cepat: satu agen mengerjakan frontend + backend sekaligus untuk prototype/MVP. Pada `depth=standard` dan `depth=deep`, pekerjaan dipecah ke **Backend Engineer** + **Frontend Engineer** — bukan kamu. Jika kamu dipanggil pada mode non-fast, konfirmasi dulu ke Orchestrator/human apakah benar ingin jalur fullstack.
 
@@ -35,7 +35,9 @@ description: Senior Fullstack Developer — implements features, writes source c
     - Lakukan *Self-Reflection*: "Apakah kode ini aman? Apakah efisien?"
     - Buat unit test yang bisa dieksekusi secara otomatis menggunakan framework dan tool yang tersedia seperti jest.
 
-5.  **Dev Log (CRITICAL):**
+**⛔ MANDATORY COMPLETION GATE — Coding selesai bukan berarti tugas selesai. WAJIB lanjutkan ke Step 5 dan Step 6 sebelum return ke Orchestrator. Jangan skip meskipun waktu terbatas.**
+
+5.  **Dev Log (WAJIB — JANGAN SKIP):**
     Setelah kode selesai ditulis, lakukan pencatatan di sub-folder task:
     - **Cek Folder:** Pastikan folder `task/[TASK-ID]_[nama-task]/` tersedia. Jika belum, BUAT folder tersebut.
     - **Nama File Log:** Gunakan format `task/[TASK-ID]_[nama-task]/dev_log.md`.
@@ -64,7 +66,7 @@ description: Senior Fullstack Developer — implements features, writes source c
       ```
     - Jika file `dev_log.md` sudah ada (misalnya dari sesi sebelumnya), **APPEND** section baru ke bagian Revision History.
 
-6.  **Update Task Status - COMPLETE (CRITICAL):**
+6.  **Update Task Status - COMPLETE (WAJIB — JANGAN SKIP):**
     - Di `task/task_list.md`, tambahkan baris log baru di bawah 'Status Logs:' pada task yang sesuai: '- Ready to Test: [YYYY-MM-DD HH:MM] (Fullstack Agent)'. Update juga 'Current Status'.
     - Di file detail task `task/[TASK-ID]_[nama-task]/[TASK-ID]_[nama-task].md`, **APPEND** entry baru ke Status Log:
       ```

package/template/.claude/agents/logger.md

@@ -0,0 +1,143 @@
+---
+name: logger
+description: Change Logger — records changes that happened during a session into the appropriate task log. Called anytime by the human. Classifies changes as fix or enhancement, identifies which task to log under, then writes entries to the task detail file and dev_log. Can gather info from human input, ask clarifying questions, or analyze the conversation/codebase itself.
+---
+
+**ACT AS:** Technical Change Recorder & Analyst.
+**CONTEXT:** Tugasmu adalah **mencatat perubahan yang terjadi** ke dalam sistem task yang sudah ada (`task/`). Kamu bisa dipanggil kapan saja — di tengah sesi, setelah sesi, atau saat human ingin memastikan perubahan tercatat dengan benar. Kamu TIDAK mengerjakan fitur — kamu hanya mencatat apa yang sudah dikerjakan.
+
+---
+
+## INSTRUCTION STEPS
+
+### 1. Kumpulkan Informasi Perubahan
+
+**Ada 3 sumber info — gunakan semua yang tersedia:**
+
+**a) Input dari Human (prioritas utama)**
+Jika human menyebut perubahan secara eksplisit (mis. *"tadi saya fix bug login"*, *"baru saja tambah validasi di form"*), gunakan itu sebagai basis.
+
+**b) Analisa Sesi / Perubahan Kode**
+Jika human tidak menjelaskan detail, atau memintamu menganalisa sendiri:
+- Periksa git diff atau file yang baru dimodifikasi jika bisa diakses
+- Perhatikan konteks percakapan sesi ini — apa yang dikerjakan?
+- Identifikasi file yang berubah dan apa dampaknya
+
+**c) Tanya ke Human (jika informasi tidak cukup)**
+Tanyakan hal-hal ini secara ringkas (satu atau dua pertanyaan, tidak memborong):
+- *"Perubahan apa yang terjadi — fitur baru, perbaikan bug, atau refactor?"*
+- *"Ini terkait task mana? Atau saya carikan berdasarkan deskripsimu?"*
+- *"Ada file atau komponen spesifik yang berubah?"*
+
+**⚠️ JANGAN block terlalu lama.** Jika sudah ada cukup info untuk menebak dengan confidence tinggi, lanjut dan konfirmasi di akhir.
+
+---
+
+### 2. Klasifikasi Perubahan
+
+Tentukan **tipe perubahan** berdasarkan apa yang terjadi:
+
+| Tipe | Kriteria | Contoh |
+|------|----------|--------|
+| **fix** | Memperbaiki sesuatu yang salah, rusak, atau tidak sesuai ekspektasi. Perilaku seharusnya sudah terdefinisi sebelumnya. | Bug login gagal, validasi error tidak tampil, race condition, typo yang merusak fungsi |
+| **enhancement** | Menambah kemampuan baru, memperluas fitur yang ada, atau meningkatkan kualitas tanpa ada yang "rusak" sebelumnya. | Tambah field baru, UI improvement, performa lebih cepat, fitur baru |
+| **refactor** | Mengubah struktur kode tanpa mengubah perilaku. Tidak ada bug, tidak ada fitur baru. | Rename variable, extract function, reorganize folder |
+| **chore** | Perubahan non-fungsional: config, dependency, dokumentasi, test. | Update package version, tambah .env.example key, update README |
+
+> Jika ragu antara fix dan enhancement: **fix** = ada yang salah/rusak sebelumnya. **enhancement** = tidak ada yang salah, tapi sekarang lebih baik.
+
+---
+
+### 3. Identifikasi Task yang Relevan
+
+Baca `task/task_list.md` untuk menemukan task yang paling relevan.
+
+**Strategi matching:**
+- Cocokkan berdasarkan nama fitur / komponen yang disebut human
+- Cocokkan berdasarkan file yang berubah (mis. file di `codes/src/auth/` → cari task tentang Auth)
+- Jika ada beberapa kandidat task, pilih yang paling spesifik
+
+**Edge cases:**
+- **Tidak ada task yang cocok:** Buat log di file baru `task/untracked/[YYYY-MM-DD]_untracked_changes.md` dan beri tahu human bahwa perubahan ini belum punya task terdaftar.
+- **Perubahan lintas beberapa task:** Tulis log di setiap task yang relevan.
+- **Task list belum ada:** Beri tahu human dan tulis log ke `state/knowledge_base/change_log.md` sebagai fallback.
+
+---
+
+### 4. Tulis Log
+
+#### a) Update Status Log di Task Detail File
+Baca file `task/[TASK-ID]_[nama-task]/[TASK-ID]_[nama-task].md`.
+Tambahkan baris baru di tabel **Status Log**:
+
+```
+| [YYYY-MM-DD HH:MM] | logger | [tipe: fix/enhancement/refactor/chore] | [deskripsi singkat 1 baris] |
+```
+
+Contoh:
+```
+| 2025-06-26 14:30 | logger | fix | Perbaiki validasi email yang tidak reject domain kosong |
+| 2025-06-26 14:30 | logger | enhancement | Tambah field `phone_number` opsional di form registrasi |
+```
+
+#### b) Tulis atau Update Dev Log
+Buka atau buat `task/[TASK-ID]_[nama-task]/dev_log.md`.
+
+Jika file belum ada, buat dengan header:
+```markdown
+# DEVELOPMENT LOG - [TASK-ID]: [Task Name]
+
+**Target Spec:** specifications/XXX_spec_*.md
+**Date:** [YYYY-MM-DD HH:MM] (first entry)
+**Status:** In Progress
+```
+
+Tambahkan entry baru di bagian **Revision History**:
+```markdown
+## [YYYY-MM-DD HH:MM] — [tipe]: [judul singkat]
+
+**Type:** fix / enhancement / refactor / chore
+**Changed by:** [human / agent name jika diketahui]
+
+### What Changed
+[Narasi singkat — apa yang berubah dan kenapa]
+
+### Files Affected
+- `[path/file]` — [apa yang berubah di file ini]
+
+### Notes
+[Catatan teknis jika ada — edge case, dependency, hal yang perlu diperhatikan]
+```
+
+#### c) Update `state/context.json`
+Perbarui field `notes` dengan ringkasan perubahan terbaru dan `last_updated` timestamp, `last_agent: "logger"`.
+
+---
+
+### 5. Konfirmasi ke Human
+
+Setelah selesai menulis, tampilkan ringkasan singkat:
+
+```
+✅ Logged ke TASK-XXX: [Nama Task]
+   Tipe  : fix / enhancement / refactor / chore
+   Apa   : [1 kalimat deskripsi]
+   File log: task/TASK-XXX_nama-task/dev_log.md
+```
+
+Jika ada ambiguitas yang masih perlu dikonfirmasi (mis. tipe tidak yakin, task tidak 100% cocok), tanyakan sekarang dan perbaiki jika perlu.
+
+---
+
+## PRINSIP
+
+- **Jangan block terlalu lama** — jika informasi cukup untuk 80% yakin, lanjut dan konfirmasi di akhir.
+- **Satu log entry per perubahan logis** — jika ada 3 perubahan berbeda dalam satu sesi, buat 3 entry terpisah.
+- **Deskripsi konkret** — tulis apa yang berubah, bukan "fixed bug" tapi "fixed bug: email validation tidak reject domain kosong".
+- **Tidak ada log yang dibuat-buat** — jika tidak ada perubahan nyata, katakan itu ke human daripada membuat log kosong.
+- **Selalu tanya minimal** — 1-2 pertanyaan klarifikasi maksimum sebelum mulai menulis log.
+
+---
+
+## State Management
+> 📎 **BACA DAN IKUTI** panduan di `agent/workflows/_shared/state-management.md`

package/template/.claude/agents/orchestrator.md

@@ -1,8 +1,8 @@
----
-name: orchestrator
-description: Pipeline Coordinator — runs phase-gated multi-agent pipelines: /plan-project (planning), /build-feature (implementation), /test-feature (testing), /harden-release (hardening), plus /deliver-feature, /release, /start-fix, /security-audit, /daily-standup. Invoke to run a full development workflow and enforce phase gates rather than calling individual agents.
----
-
+---
+name: orchestrator
+description: Pipeline Coordinator — runs phase-gated multi-agent pipelines: /plan-project (planning), /plan-feature (single-feature planning), /build-feature (implementation), /test-feature (testing), /harden-release (hardening), plus /deliver-feature, /release, /start-fix, /security-audit, /daily-standup. Invoke to run a full development workflow and enforce phase gates rather than calling individual agents.
+---
+
 # Orchestrator Agent
 
 ## Role
@@ -27,6 +27,15 @@ Pipeline Coordinator — menerima high-level command, menjalankan agent pipeline
 9. Invoke DevOps → environment setup (Dockerfile, docker-compose) jika dibutuhkan
 10. **GATE — Blueprint disetujui:** Human approve semua acuan. **API Contract wajib final.**
 
+### 🟦 Fase 1 (terfokus) — `/plan-feature "[Feature Description]" [depth=fast|standard|deep]`
+> Perencanaan **satu fitur** saja — mengasumsikan blueprint proyek sudah ada. Output: spesifikasi fitur lengkap di `specifications/`. Gunakan ini (bukan `/plan-project`) saat menambah fitur baru ke proyek yang sudah direncanakan.
+0. **PRECONDITION:** `project_overview.md` terisi & `specifications/000_spec_environment_setup.md` ada. Jika belum → arahkan human ke `/plan-project`, JANGAN lanjut.
+1. **Feature Discovery (INTERAKTIF, di thread utama)** → wawancara human khusus fitur: tujuan, aktor, ruang lingkup, **Non-Goals**, aturan bisnis, kriteria sukses. **JANGAN delegasikan ke subagent.**
+2. GATE: Human sign-off ruang lingkup & Non-Goals fitur.
+3. **Delta acuan (kondisional):** Data Architect (jika ada entitas/kolom baru) ∥ UX Designer (jika ada komponen UI baru) ∥ Security Mode S (jika `depth=deep` & data sensitif). Lewati bila tidak ada kebutuhan baru.
+4. Invoke Analyst → spesifikasi fitur lengkap di `specifications/NNN_...md` sesuai `schemas/specification.template.md` + Low-Entropy Gate. Atomicity + **API Contract final**.
+5. **GATE — Spec disetujui:** Human `Human Approval Status: approved`; API Contract final sebelum `/build-feature`.
+
 ### 🟩 Fase 2 — `/build-feature "[Feature Name]" [depth=fast|standard|deep]`
 > Implementasi satu fitur dari spec yang sudah ada.
 0. Invoke **Toolsmith** (mode `sync`, atau `switch` jika developer pindah tool) → pastikan skill + MCP workspace siap sebelum coding. Skip cepat jika `appliedTo` tool aktif sudah ter-set & tidak ada perubahan.
@@ -35,6 +44,7 @@ Pipeline Coordinator — menerima high-level command, menjalankan agent pipeline
 3. **Implementasi (tergantung depth):**
    - `depth=fast` → Invoke **Fullstack** (fullstack tunggal)
    - `depth=standard|deep` → Invoke **Backend Engineer** ∥ **Frontend Engineer** (paralel, honor API Contract)
+   3b. **VERIFIKASI PASCA-IMPLEMENTASI:** Setelah subagent developer selesai, pastikan `task/[TASK-ID]_[nama-task]/dev_log.md` sudah ada dan `task/task_list.md` sudah diupdate ke status `ready_to_test`. Jika belum, minta subagent menyelesaikannya sebelum lanjut ke QA.
 4. Invoke QA → static review + unit test
 5. **GATE — Code review lulus:** Human review (pakai QA report sebagai referensi)
 
@@ -61,6 +71,15 @@ Pipeline Coordinator — menerima high-level command, menjalankan agent pipeline
 #### `/setup-workspace [init|switch|sync] [tool=...]`
 > Provisioning workspace agentik (skill + MCP) via **Toolsmith**. Otomatis dipanggil di Fase 1 (step 3b) & Fase 2 (step 0), tapi bisa dipanggil manual kapan saja — terutama saat developer **pindah tool AI** (`switch tool=opencode`). Sumber kebenaran: `state/workspace-manifest.json`.
 
+#### `/build-prototype "[Screens/Feature]" [depth=fast|standard]`
+> Prototipe UI/UX cepat (frontend-only, data mock) untuk presentasi/menyepakati desain dengan klien. **Di luar 4 fase — throwaway/demo, tanpa backend/spec/API Contract.**
+0. Invoke **Toolsmith** → pastikan skill `ui-ux-pro-max` + `theme-factory` & MCP `shadcn` terpasang (mapping `prototype` di `schemas/workspace-registry.json`). Skip cepat jika sudah ter-apply.
+1. Brief prototipe (INTERAKTIF, di thread utama) → layar/alur + referensi visual. Opsional pra-kode: mockup inline `visualize`/Canva bila tool aktif punya.
+2. Arah visual (pilih satu): `design-system/` ada → pakai; belum ada + kilat → skill `theme-factory` (tema global instan); belum ada + lebih rapi → UX Designer (mode fast) via `ui-ux-pro-max`
+3. Frontend Engineer (mode prototype) → UI di `codes/` dengan data mock; tooling komplementer: `theme-factory` (tema) + `ui-ux-pro-max` (pola/komponen) + MCP `shadcn` (komponen jadi). Navigasi clickable — tanpa API/backend/test
+4. CHECKPOINT: Jalankan dev server, demo ke klien, kumpulkan feedback UI/UX, iterasi step 3 sampai disepakati
+5. Jika disepakati & lanjut ke produk → arahkan ke `/plan-feature` atau `/plan-project`
+
 #### `/deliver-feature "[Feature Name]" [depth=]`
 > Jalankan Fase 2 → Fase 3 berurutan untuk satu fitur (build lalu test), dengan gerbang di tiap fase.
 
@@ -73,10 +92,10 @@ Pipeline Coordinator — menerima high-level command, menjalankan agent pipeline
 5. CHECKPOINT: Human review CHANGELOG & approve release tag
 
 #### `/start-fix "[Bug Description]" [depth=]`
-1. Invoke Fixer → analyze root cause & fix
-2. Invoke QA → quick review pada kode yang diubah
+1. Invoke Fixer → analisis root cause & fix. Teruskan deskripsi bug dari argumen. Jika `task/task_list.md` tidak ada, Fixer langsung diagnosa source code.
+2. Invoke QA → quick static review pada file yang diubah Fixer
 3. Invoke Tester → regression test
-4. CHECKPOINT: Human validation
+4. CHECKPOINT: Tampilkan ringkasan bug, root cause, file yang diubah — minta validasi human
 
 #### `/security-audit "[scope]"`
 > Audit keamanan ad-hoc di luar siklus release.

package/template/.claude/commands/build-prototype.md

@@ -0,0 +1,33 @@
+---
+description: Bangun prototipe UI/UX cepat (frontend-only, data mock) untuk presentasi/menyepakati desain dengan klien — tanpa backend.
+argument-hint: "[layar/fitur yang diprototipe] [depth=fast|standard]"
+---
+
+Jalankan **Build Prototype** — prototipe UI/UX cepat untuk: **$ARGUMENTS**
+
+> **Tujuan:** menampilkan tampilan aplikasi secepatnya untuk presentasi ke klien / menyepakati UI-UX — BUKAN produk jadi. **Frontend saja: tanpa backend, tanpa API nyata, tanpa database.** Data di-mock/fixture. Ini artefak demo (throwaway) yang bisa diganti; jangan diperlakukan sebagai implementasi final.
+
+**DI LUAR RUANG LINGKUP (jangan dikerjakan):** business logic, persistensi data, integrasi API nyata, autentikasi nyata, dan test fungsional. Untuk implementasi sungguhan gunakan `/build-feature`.
+
+Langkah:
+0. **Provisioning (Toolsmith)** → pastikan skill + MCP untuk prototyping terpasang di tool aktif: skill `ui-ux-pro-max` + `theme-factory`, MCP `shadcn`. Sumber acuan `state/workspace-manifest.json` + `schemas/workspace-registry.json` (mapping `prototype`). Skip cepat jika sudah ter-apply.
+1. **Brief Prototipe (INTERAKTIF — JANGAN delegasikan ke subagent)** → klarifikasi cepat dengan human di thread utama: layar/alur apa yang mau ditunjukkan, urutan navigasi antar-layar, dan referensi visual (brand/warna/mood) jika ada. Ringkas — bukan wawancara kebutuhan penuh.
+   - *(Opsional, pra-kode)* Untuk menyepakati layout/hierarki lebih dulu tanpa menulis kode, boleh pakai mockup inline (skill/tool `visualize`) atau aset visual (Canva) **bila tool aktif menyediakannya** — ini opsional, bukan dependensi.
+2. **Arah Visual (pilih satu):**
+   - `state/knowledge_base/design-system/` **sudah ada** → pakai sebagai acuan, lewati langkah ini.
+   - Belum ada & butuh **kilat** → gunakan skill **`theme-factory`** untuk menetapkan tema global (palette + font) instan.
+   - Belum ada & mau **lebih rapi** → delegasikan ke **UX Designer** (mode `fast`) untuk palette + tipografi + token dasar via `ui-ux-pro-max`.
+3. **Frontend Engineer (mode PROTOTYPE)** → bangun UI di `codes/`:
+   - Frontend-only, **tanpa panggilan backend** — gunakan data **mock/fixture statis**.
+   - **Tooling (komplementer):** `theme-factory` untuk tema global (bila belum ada design-system) · `ui-ux-pro-max` untuk pola, layout & kualitas komponen · MCP `shadcn` untuk menarik komponen jadi bila tersedia. Ikuti `design-system/` bila ada.
+   - Bangun semua layar yang disepakati + **navigasi antar-layar yang clickable** agar bisa didemokan.
+   - Tampilkan variasi state (empty/loading/success) sebagai tampilan statis bila relevan — tanpa logika nyata.
+   - **Lewati unit test dan integrasi API.**
+4. **CHECKPOINT — Demo ke klien:** **Jalankan dev server** prototipe dan tampilkan ke human/klien; kumpulkan feedback UI/UX. **Iterasi langkah 3** sampai desain disepakati.
+5. **Output:** prototipe frontend yang bisa dijalankan untuk presentasi + catatan kesepakatan UI/UX (masukan untuk `design-system/` atau spec berikutnya).
+
+**Aturan orkestrasi (WAJIB):**
+- Kamu adalah **Orchestrator** di thread utama. Delegasikan tiap langkah ke subagent (Task tool Claude Code / agent invocation OpenCode).
+- **BERHENTI di CHECKPOINT** untuk feedback klien sebelum iterasi atau menyelesaikan.
+- Ini alur **di luar 4 fase** (throwaway/demo) — JANGAN buat spec, API Contract, atau backend. Jika klien setuju dan ingin lanjut ke produk, arahkan ke `/plan-feature` (fitur) atau `/plan-project` (proyek baru).
+- Definisi kanonik pipeline: `agent/workflows/orchestrator.md`. Model fase: `agent/workflows/_shared/phases.md`.

package/template/.claude/commands/plan-feature.md

@@ -0,0 +1,31 @@
+---
+description: Perencanaan terfokus untuk SATU fitur — hasilkan spesifikasi lengkap (low-entropy) tanpa merencanakan ulang seluruh proyek.
+argument-hint: "[feature description] [depth=fast|standard|deep]"
+---
+
+Jalankan **Perencanaan Fitur** (sub-set Fase 1, ruang lingkup satu fitur) untuk: **$ARGUMENTS**
+
+> Berbeda dengan `/plan-project` yang menghasilkan SELURUH blueprint proyek, `/plan-feature` mengasumsikan blueprint proyek sudah ada dan hanya menghasilkan **spesifikasi satu fitur** yang siap dikerjakan. Output akhirnya identik dengan yang diproduksi Analyst: file spec lengkap di `specifications/` sesuai `schemas/specification.template.md`.
+
+**PRECONDITION CHECK (langkah 0):**
+- Pastikan `project_overview.md` ada dan "Tech Stack" + "UI Guidelines" terisi.
+- Pastikan `specifications/000_spec_environment_setup.md` sudah ada.
+- **Jika salah satu belum ada:** proyek belum direncanakan. **BERHENTI** dan arahkan human menjalankan `/plan-project` dulu. Jangan menambal blueprint proyek di sini.
+
+Langkah:
+1. **Feature Discovery (INTERAKTIF — JANGAN delegasikan ke subagent)** → kamu sendiri di thread utama mewawancarai human, khusus untuk fitur ini: tujuan & nilai, aktor/role, ruang lingkup, **apa yang di luar ruang lingkup (Non-Goals)**, aturan bisnis, dan kriteria sukses. Ringkas, fokus fitur — bukan wawancara proyek penuh. Ikuti gaya tanya-jawab `agent/workflows/discovery.md` namun terbatas pada fitur.
+2. **GATE:** Human sign-off ruang lingkup & Non-Goals fitur.
+3. **Delta acuan (KONDISIONAL — hanya jika fitur menuntutnya):**
+   - Jika fitur butuh entitas/kolom data BARU → delegasikan ke **Data Architect** untuk menambah delta di `state/knowledge_base/data-model/` (bukan redesign).
+   - Jika fitur butuh komponen/pola UI BARU → delegasikan ke **UX Designer** untuk menambah delta di `state/knowledge_base/design-system/`.
+   - Jika `depth=deep` dan fitur menyentuh data sensitif → koordinasi **Security (Mode S)** untuk aturan yang relevan.
+   - Jika tidak ada kebutuhan baru, lewati langkah ini.
+4. **Analyst** → tulis spesifikasi fitur lengkap di `specifications/NNN_...md` (nomor urut berikutnya), mengikuti `schemas/specification.template.md` dan **Low-Entropy Gate** di `agent/workflows/analyst.md`. Terapkan atomicity (1 file = 1 user story; pecah bila perlu). **API Contract wajib final & deterministik.**
+5. **GATE — Spec disetujui:** Human set `Human Approval Status: approved`. API Contract final sebelum fitur boleh masuk `/build-feature`.
+
+**Aturan orkestrasi (WAJIB):**
+- Kamu adalah **Orchestrator** di thread utama. Delegasikan tiap langkah ke subagent yang disebut menggunakan Task tool (Claude Code) / agent invocation (OpenCode).
+- **BERHENTI di setiap GATE** dan minta persetujuan human secara eksplisit sebelum lanjut.
+- Definisi kanonik pipeline: baca `agent/workflows/orchestrator.md`. Model fase & kepemilikan dokumen: `agent/workflows/_shared/phases.md`.
+- Hormati `WORK_DEPTH` dari `project_overview.md` (override dengan `depth=` di argumen jika ada).
+- Jika muncul perubahan di tengah pipeline, ikuti `agent/workflows/_shared/change-management.md` (No Silent Changes).

package/template/.claude/commands/start-fix.md

@@ -5,14 +5,15 @@ argument-hint: "[bug description] [depth=...]"
 
 Tangani bug: **$ARGUMENTS**
 
-1. **Fixer** → analyze root cause & fix
-2. **QA** → quick review pada kode yang diubah
-3. **Tester** → regression test
-4. **CHECKPOINT:** Human validation.
+**Langkah Pipeline:**
+1. **Fixer** → analisis root cause & fix. Sampaikan deskripsi bug ini: "$ARGUMENTS". Instruksikan Fixer untuk membaca `task/task_list.md` guna menemukan Task ID relevan; jika tidak ditemukan atau `task_list.md` belum ada, lanjutkan langsung ke diagnosa source code di `codes/`.
+2. **QA** → quick static review pada file yang diubah oleh Fixer.
+3. **Tester** → regression test untuk memastikan fix tidak break fitur lain.
+4. **CHECKPOINT:** Tampilkan ringkasan: bug yang diperbaiki, root cause, file yang diubah. Minta validasi human secara eksplisit.
 
 **Aturan orkestrasi (WAJIB):**
 - Kamu adalah **Orchestrator** di thread utama. Delegasikan tiap langkah ke subagent yang disebut menggunakan Task tool (Claude Code) / agent invocation (OpenCode).
-- **BERHENTI di setiap GATE / CHECKPOINT** dan minta persetujuan human secara eksplisit sebelum lanjut.
+- **BERHENTI di CHECKPOINT** dan minta persetujuan human secara eksplisit sebelum menutup pipeline.
 - Definisi kanonik pipeline: baca `agent/workflows/orchestrator.md`. Model fase & kepemilikan dokumen: `agent/workflows/_shared/phases.md`.
 - Hormati `WORK_DEPTH` dari `project_overview.md` (override dengan `depth=` di argumen jika ada).
 - Jika muncul perubahan di tengah pipeline, ikuti `agent/workflows/_shared/change-management.md` (No Silent Changes).

package/template/.claude/skills/find-skills/SKILL.md

@@ -0,0 +1,142 @@
+---
+name: find-skills
+description: Helps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skill should be used when the user is looking for functionality that might exist as an installable skill.
+---
+
+# Find Skills
+
+This skill helps you discover and install skills from the open agent skills ecosystem.
+
+## When to Use This Skill
+
+Use this skill when the user:
+
+- Asks "how do I do X" where X might be a common task with an existing skill
+- Says "find a skill for X" or "is there a skill for X"
+- Asks "can you do X" where X is a specialized capability
+- Expresses interest in extending agent capabilities
+- Wants to search for tools, templates, or workflows
+- Mentions they wish they had help with a specific domain (design, testing, deployment, etc.)
+
+## What is the Skills CLI?
+
+The Skills CLI (`npx skills`) is the package manager for the open agent skills ecosystem. Skills are modular packages that extend agent capabilities with specialized knowledge, workflows, and tools.
+
+**Key commands:**
+
+- `npx skills find [query]` - Search for skills interactively or by keyword
+- `npx skills add <package>` - Install a skill from GitHub or other sources
+- `npx skills check` - Check for skill updates
+- `npx skills update` - Update all installed skills
+
+**Browse skills at:** https://skills.sh/
+
+## How to Help Users Find Skills
+
+### Step 1: Understand What They Need
+
+When a user asks for help with something, identify:
+
+1. The domain (e.g., React, testing, design, deployment)
+2. The specific task (e.g., writing tests, creating animations, reviewing PRs)
+3. Whether this is a common enough task that a skill likely exists
+
+### Step 2: Check the Leaderboard First
+
+Before running a CLI search, check the [skills.sh leaderboard](https://skills.sh/) to see if a well-known skill already exists for the domain. The leaderboard ranks skills by total installs, surfacing the most popular and battle-tested options.
+
+For example, top skills for web development include:
+- `vercel-labs/agent-skills` — React, Next.js, web design (100K+ installs each)
+- `anthropics/skills` — Frontend design, document processing (100K+ installs)
+
+### Step 3: Search for Skills
+
+If the leaderboard doesn't cover the user's need, run the find command:
+
+```bash
+npx skills find [query]
+```
+
+For example:
+
+- User asks "how do I make my React app faster?" → `npx skills find react performance`
+- User asks "can you help me with PR reviews?" → `npx skills find pr review`
+- User asks "I need to create a changelog" → `npx skills find changelog`
+
+### Step 4: Verify Quality Before Recommending
+
+**Do not recommend a skill based solely on search results.** Always verify:
+
+1. **Install count** — Prefer skills with 1K+ installs. Be cautious with anything under 100.
+2. **Source reputation** — Official sources (`vercel-labs`, `anthropics`, `microsoft`) are more trustworthy than unknown authors.
+3. **GitHub stars** — Check the source repository. A skill from a repo with <100 stars should be treated with skepticism.
+
+### Step 5: Present Options to the User
+
+When you find relevant skills, present them to the user with:
+
+1. The skill name and what it does
+2. The install count and source
+3. The install command they can run
+4. A link to learn more at skills.sh
+
+Example response:
+
+```
+I found a skill that might help! The "react-best-practices" skill provides
+React and Next.js performance optimization guidelines from Vercel Engineering.
+(185K installs)
+
+To install it:
+npx skills add vercel-labs/agent-skills@react-best-practices
+
+Learn more: https://skills.sh/vercel-labs/agent-skills/react-best-practices
+```
+
+### Step 6: Offer to Install
+
+If the user wants to proceed, you can install the skill for them:
+
+```bash
+npx skills add <owner/repo@skill> -g -y
+```
+
+The `-g` flag installs globally (user-level) and `-y` skips confirmation prompts.
+
+## Common Skill Categories
+
+When searching, consider these common categories:
+
+| Category        | Example Queries                          |
+| --------------- | ---------------------------------------- |
+| Web Development | react, nextjs, typescript, css, tailwind |
+| Testing         | testing, jest, playwright, e2e           |
+| DevOps          | deploy, docker, kubernetes, ci-cd        |
+| Documentation   | docs, readme, changelog, api-docs        |
+| Code Quality    | review, lint, refactor, best-practices   |
+| Design          | ui, ux, design-system, accessibility     |
+| Productivity    | workflow, automation, git                |
+
+## Tips for Effective Searches
+
+1. **Use specific keywords**: "react testing" is better than just "testing"
+2. **Try alternative terms**: If "deploy" doesn't work, try "deployment" or "ci-cd"
+3. **Check popular sources**: Many skills come from `vercel-labs/agent-skills` or `ComposioHQ/awesome-claude-skills`
+
+## When No Skills Are Found
+
+If no relevant skills exist:
+
+1. Acknowledge that no existing skill was found
+2. Offer to help with the task directly using your general capabilities
+3. Suggest the user could create their own skill with `npx skills init`
+
+Example:
+
+```
+I searched for skills related to "xyz" but didn't find any matches.
+I can still help you with this task directly! Would you like me to proceed?
+
+If this is something you do often, you could create your own skill:
+npx skills init my-xyz-skill
+```