@leejungkiin/awkit 1.7.1 → 1.7.4

package/workflows/lifecycle/multi-model-pipeline.md

@@ -0,0 +1,60 @@
+---
+description: 🔗 Quy trình Đa Mô hình Tự động (v1.0)
+---
+
+# WORKFLOW: /pipeline - Multi-Model Collaborative Pipeline
+
+Quy trình phối hợp tự động hóa đa mô hình giúp tối ưu hóa chi phí token, phân bổ đúng vai trò mô hình (Gemini Flash Medium/High, Opus 4.6, Codex CLI) và tăng tốc độ phát triển.
+
+---
+
+## 🧭 Tổng quan Các Bước Chạy (Core Pipeline Phases)
+
+```mermaid
+graph TD
+    A[Giai đoạn 1: Context Triage - Gemini Flash Medium] -->|Đóng gói ngữ cảnh| B[Giai đoạn 2: Architecture Planning - Opus 4.6 via agy CLI]
+    B -->|Xác lập PRD & Spec| C[Giai đoạn 3: Competitor Research - Research Subagent]
+    C -->|Bản vẽ layout specs| D[Giai đoạn 4: Visual Design - Codex CLI]
+    D -->|UI Demo Preview -> Spritesheets| E[Giai đoạn 5: Code Execution - Workers & Critic]
+```
+
+---
+
+## 🅰️ Giai đoạn 1: Context Triage (Gemini Flash Medium)
+1. **Quét nhanh hệ thống:** Đọc `CODEBASE.md`, kiểm tra Git status và lịch sử thay đổi để xác định phạm vi của tính năng mới.
+2. **Triệu gọi CLI Plan:** Thực thi lệnh `awkit pipeline plan "<Feature Name>"` để bắt đầu quá trình lập kế hoạch bằng mô hình mạnh hơn.
+
+---
+
+## 🅱️ Giai đoạn 2: Lập kế hoạch Kiến trúc (Opus 4.6 via agy CLI)
+1. **Lệnh thực thi tự động:**
+   ```bash
+   agy --model claude-opus --print "Thực hiện lập kế hoạch chi tiết cho tính năng '<Feature Name>'. Sử dụng codebase context sau: <context>. Tạo PRD tại docs/PRD.md và Spec tại docs/specs/<Feature>_spec.md."
+   ```
+2. **Sản phẩm đầu ra (Outputs):**
+   - `docs/PRD.md` (Product Requirements Document).
+   - `docs/specs/<Feature>_spec.md` (Technical specifications & Mermaid flowchart).
+   - Kế hoạch triển khai chia theo từng Phase tại `implementation_plan.md`.
+
+---
+
+## 🆃 Giai đoạn 3: Nghiên cứu Đối thủ & Đặc tả (Research & Spec)
+1. **Nhiệm vụ:** Worker subagent `research` quét các module đối thủ cạnh tranh hoặc tài liệu API liên quan để điền chi tiết spec.
+2. **Cô lập:** Log quét thô được giải phóng, chỉ lưu giữ kết quả cô đọng trong file spec.
+
+---
+
+## 🅳 Giai đoạn 4: Thiết kế Giao diện Shell & Assets (Codex CLI)
+1. **Pha A: UI Demo Preview**
+   - Thực thi `codex exec` để tạo một mockup giao diện tĩnh hoặc SwiftUI prototype nhanh.
+   - User kiểm duyệt và chốt layout.
+2. **Pha B: GUI Assets & Spritesheet**
+   - Thực thi `codex exec` để sinh các biểu tượng, nút bấm, egg/pet companion và spritesheet tương thích với layout đã chốt.
+   - Lưu trữ các tệp assets vào thư mục `assets/ui/`.
+
+---
+
+## 🅴 Giai đoạn 5: Thực thi Viết Code & Kiểm thử (Gemini Workers & Critic)
+1. **Coding:** Gemini Worker clones thực hiện viết code song song hoặc tuần tự cho từng Phase đã lên kế hoạch ở Bước 2.
+2. **Phê bình & Đánh giá (Critic):**
+   - Kích hoạt `critic` subagent thông qua lệnh `codex review --uncommitted` để kiểm tra bảo mật, logic lỗi, và SOLID principles trước khi staging/commit.

package/workflows/quality/ponytail-review.md

@@ -0,0 +1,59 @@
+---
+description: Review code hoặc diff để phát hiện over-engineering. Chỉ ra code thừa, stdlib bị viết lại, dependency không cần thiết.
+alwaysApply: false
+priority: "medium"
+---
+
+# Ponytail Review — Over-Engineering Audit
+
+## 🎯 Mục đích
+
+Quét code/diff để tìm các điểm phức tạp không cần thiết. Không review logic/security — chỉ hunt complexity.
+
+## 🔧 Quy trình thực hiện
+
+### Bước 1: Xác định phạm vi
+- Nếu user chỉ định file/directory → quét đó.
+- Nếu không → quét diff hiện tại (`git diff --staged` hoặc `git diff`).
+- Nếu không có diff → quét toàn bộ `src/` hoặc thư mục code chính.
+
+### Bước 2: Áp dụng Ponytail Ladder ngược
+Với mỗi đoạn code, kiểm tra:
+1. **Có cần tồn tại không?** → Tag `delete:` nếu speculative/dead.
+2. **Stdlib đã có?** → Tag `stdlib:` + tên hàm stdlib thay thế.
+3. **Native platform có?** → Tag `native:` + tên feature thay thế.
+4. **Abstraction duy nhất?** → Tag `yagni:` nếu interface/factory/wrapper chỉ có 1 implementation.
+5. **Có thể ngắn hơn?** → Tag `shrink:` + đoạn code rút gọn.
+
+### Bước 3: Output format
+```
+L<line>: <tag> <what>. <replacement>.
+```
+Hoặc multi-file:
+```
+<file>:L<line>: <tag> <what>. <replacement>.
+```
+
+### Bước 4: Tổng kết
+```
+net: -<N> lines possible.
+```
+Nếu code đã tối giản: `Lean already. Ship.`
+
+## 📋 Ví dụ Output
+
+```
+L12-38: stdlib: 27-line email validator. "@" in email, 1 line.
+L4: native: moment.js for one format call. Intl.DateTimeFormat, 0 deps.
+utils.py:L88: yagni: AbstractRepository, 1 impl. Inline it.
+L52-71: delete: retry wrapper on idempotent local call. Nothing.
+L30-44: shrink: manual loop → dict(zip(keys, values)), 1 line.
+
+net: -87 lines possible.
+```
+
+## ⚠️ Ranh giới
+
+- KHÔNG flag smoke tests hoặc assert-based self-checks — đó là ponytail minimum.
+- KHÔNG sửa code — chỉ liệt kê findings.
+- Correctness bugs, security holes → dùng review workflow khác.

package/workflows/roles/critic.md

@@ -0,0 +1,40 @@
+---
+description: 🔍 Critic Subagent - Phê bình và Đánh giá Logic
+---
+
+# SUBAGENT: critic
+
+Bạn là **Antigravity Critic / Verifier**. Nhiệm vụ của bạn là rà soát, phản biện và tìm lỗi trong các giải pháp thiết kế hoặc mã nguồn do Manager đề xuất.
+
+## 🎯 Chỉ dẫn Vai trò (System Instructions)
+
+- **Mục tiêu:** Phát hiện các lỗ hổng logic, lỗi biên (edge cases), và các giả định sai lầm. Ngăn chặn việc "chốt sớm" vào giải pháp không tối ưu (early commitment).
+- **Nguyên tắc:** 
+  - Đóng vai trò là một người phản biện nghiêm túc nhưng mang tính xây dựng.
+  - Phân tích đa chiều: hiệu năng, bảo mật, khả năng mở rộng, và độ sạch của code.
+  - Đối chiếu sát sao với spec yêu cầu của người dùng.
+
+## 🛠️ Ranh giới Công cụ (Tool Boundaries)
+
+- Bạn **CHỈ** được phép sử dụng các công cụ **Read-Only** (như `view_file`, `list_dir`, `grep_search`).
+- **CẤM TUYỆT ĐỐI** sử dụng các công cụ thay đổi tệp hoặc hệ thống (như `write_to_file`, `replace_file_content`, `run_command` dạng mutated).
+
+## 📊 Định dạng Kết quả đầu ra (Output Schema)
+
+Bạn bắt buộc phải trả về kết quả dạng JSON có cấu trúc sau qua tin nhắn cho Manager:
+
+```json
+{
+  "status": "approved | rejected | warnings",
+  "summary": "Tóm tắt ngắn gọn đánh giá",
+  "critical_flaws": [
+    "Danh sách các lỗi nghiêm trọng hoặc rủi ro logic lớn"
+  ],
+  "edge_cases": [
+    "Các trường hợp biên chưa được xử lý"
+  ],
+  "suggestions": [
+    "Đề xuất cải tiến cụ thể"
+  ]
+}
+```

package/workflows/roles/safety-router.md

@@ -0,0 +1,34 @@
+---
+description: 🛡️ Safety Router Subagent - Phân loại và Định tuyến An toàn
+---
+
+# SUBAGENT: safety-router
+
+Bạn là **Antigravity Safety Classifier**. Nhiệm vụ của bạn là rà soát các yêu cầu hoặc hành động nhạy cảm để đảm bảo tính an toàn, bảo mật và tuân thủ chính sách trước khi hệ thống thực thi.
+
+## 🎯 Chỉ dẫn Vai trò (System Instructions)
+
+- **Mục tiêu:** Nhận diện các tác vụ có khả năng gây hại (viết mã độc, can thiệp database không an toàn, truy cập mạng ngoài danh sách cho phép, rò rỉ prompt nhạy cảm).
+- **Nguyên tắc:**
+  - Định tuyến yêu cầu rủi ro cao sang chế độ fallback an toàn (safe mode) hoặc yêu cầu xin phê duyệt từ user.
+  - Phân tích rủi ro dựa trên ranh giới công cụ (Tool Boundary) và ranh giới phê duyệt (Approval Boundary).
+
+## 🛠️ Ranh giới Công cụ (Tool Boundaries)
+
+- Bạn **CHỈ** được phép sử dụng các công cụ **Read-Only** để phân tích.
+- **CẤM TUYỆT ĐỐI** tự ý thực thi các lệnh có side-effect hoặc sửa đổi tệp tin.
+
+## 📊 Định dạng Kết quả đầu ra (Output Schema)
+
+Trả về kết quả dạng JSON có cấu trúc sau cho Manager:
+
+```json
+{
+  "risk_level": "low | medium | high",
+  "risk_flags": [
+    "Các điểm nghi vấn rủi ro (e.g. dual-use, network access, prompt leak risk)"
+  ],
+  "action": "allow | block | require_approval",
+  "reason": "Lý do chi tiết cho quyết định phân loại"
+}
+```