evnict-kit 0.2.1

package/templates/content/skills/evnict-kit-brainstorm/SKILL.md

@@ -0,0 +1,140 @@
+---
+name: evnict-kit-brainstorm
+description: Socratic design refinement — hỏi ngược user để refine ý tưởng, explore alternatives, đánh giá scope trước khi specify. HARD-GATE: không cho code trước khi design approved.
+---
+
+# evnict-kit-brainstorm
+
+## 1. Ý nghĩa và Mục đích
+
+**evnict-kit-brainstorm** là một kỹ năng phân tích và khai thác thông tin từ người dùng dựa trên phương pháp hỏi đáp Socratic.
+Quá trình brainstorm không nhằm mục đích tự tạo ra giải pháp chủ quan và ép người dùng theo, mà là một quy trình tương tác hai chiều.
+Mục tiêu là giúp người dùng đào sâu vào ý tưởng, dự đoán sớm các "edge cases" (trường hợp biên), và thiết kế một giải pháp không chỉ đáp ứng hiện tại mà còn scale tốt trong tương lai. Nắm bắt được logic cốt lõi ở giai đoạn này sẽ giúp các khâu Plan và Implement (TDD) phía sau ít gặp ma sát nhất.
+
+Kỹ năng này giúp Agent thay vì đóng vai một "Code Monkey" (nhận lệnh và gõ code vô tri) thì chuyển sang vai trò "Tech Lead / Solution Architect" (tư vấn giải pháp, cảnh báo rủi ro).
+
+---
+
+## 2. Khi nào kích hoạt
+Kỹ năng này hoạt động độc lập hoặc như một phần không thể tách rời của `evnict-kit-feature-large`:
+- **TỰ ĐỘNG** kích hoạt khi user yêu cầu tạo một feature mới mà context chưa thật sự rõ ràng hoặc mô tả của user quá trừu tượng/sơ sài.
+- Được gọi **TRƯỚC KHI** hệ thống chạy Phase (Specify/Plan).
+- **HARD-GATE:** Tuyệt đối KHÔNG được sinh code hay spec trước khi quá trình brainstorm kết thúc và chốt lại thành một **Design Brief**.
+
+---
+
+## 3. Khái niệm Socratic Brainstorm
+1. **Never Assume (Không bao giờ giả định)**: Thay vì tự giả định một hành vi, Agent hãy hỏi. Sự mơ hồ là kẻ thù của code quality. Tốt nhất là đưa ra câu hỏi đóng, kèm tuỳ chọn.
+2. **Offer Options (Luôn cung cấp lựa chọn)**: Khi đứng trước một vấn đề có nhiều cách giải, đưa ra tối đa 3 options (A, B, C) kèm theo Pros/Cons. Đừng ép User phải nghĩ ra Option. Hãy làm công việc đó thay họ.
+3. **Clarify Constraints (Làm rõ giới hạn)**: Xác định rõ các giới hạn về thời gian, kỹ thuật, bảo mật trước khi gõ bất cứ dòng code nào.
+
+---
+
+## 4. Tâm lý học Ứng xử (Behavioral Guardrails)
+Khi đặt câu hỏi, Agent cần tuân thủ các quy tắc ứng xử sau:
+- **Tôn trọng nhưng định hướng thiện chí**: Nếu Use-case của người dùng mang hơi hướng rườm rà (ví dụ muốn viết 1 file 5000 dòng để export Excel custom), nhẹ nhàng chỉ ra các thư viện hoặc Service trung gian thay vì hùa theo.
+- **Tiết kiệm Token/Mắt đọc**: Gom nhóm câu hỏi một cách thông minh, sử dụng Bullet Points. Không hỏi dồn dập mỗi lần 1 câu.
+- **Né tránh Hội chứng "Blank Page Syndrome"**: Con người thường lười mô tả ý tưởng từ đầu. Do đó Agent phải mớm lời bằng cách cung cấp Bản Nháp Góc Nhìn (Perspective Draft) để User phản biện lại. "Chửi một bản nháp tồi luôn dễ hơn xây một bản nháp từ số không."
+
+---
+
+## 5. Workflow chi tiết (Quy trình thực thi)
+
+### Bước 1: Tiếp nhận và Phân tách Ý tưởng Thô (Raw Idea Breakdown)
+Đọc và phân tích mô tả feature dạng ý tưởng thô từ user.
+1. Xác định domain nghiệp vụ: Feature này thuộc phân hệ nào? (Ví dụ: Thanh toán, Quản lý người dùng, Báo cáo...).
+2. Xác định các target actor (vai trò người dùng) tham gia vào feature này: Admin, End-User, System Service, ...
+3. Xác định trạng thái ban đầu: Nó thay đổi hệ thống đang có hay tạo mới hoàn toàn?
+
+### Bước 2: Xác định Môi trường (Project Context Detect)
+Trước khi đưa ra giải pháp, Agent PHẢI nhận biết rõ mình đang đứng ở Frontend hay Backend và giới hạn của repository hiện tại.
+1. Quét root directory xem có tồn tại `pom.xml`, `build.gradle` (Backend) hay `angular.json`, `package.json` cùng React/Angular (Frontend).
+2. Dựa trên tính chất của feature, phán đoán xem nó có CẦN sửa cả Backend lẫn Frontend hay không?
+3. Nếu CẦN sửa cả 2:
+   - Ngay lập tức thông báo để quản lý kỳ vọng: 
+     > "Feature này đòi hỏi sự tương tác xuyên suốt: Code thay đổi Backend và Frontend.
+     > Agent sẽ ghi chú lại việc phân tách ranh giới rõ ràng. Trong thư mục hiện tại, Agent sẽ tạo Plan chỉ định phần BE/FE, sau khi hoàn thành phần này sẽ có lệnh Handoff để chuyển tác vụ cho Agent phía bên kia."
+
+### Bước 3: Socratic Questioning (TỐI ĐA 5 câu hỏi cốt lõi)
+Hỏi user để refine lại design. **KHÔNG TỰ GIẢ ĐỊNH.** Đưa ra lượng câu hỏi vừa đủ, tinh giản, sắc bén theo mẫu chuẩn Socratic:
+
+**Q1: Mục tiêu nghiệp vụ (Business Goal)**
+- "Bạn muốn giải quyết triệt để bài toán gì cho user cuối bằng feature này?" (Tập trung vào The Why, không phải The How).
+
+**Q2: Phạm vi tính năng (Scope Boundary)**
+- "Feature này bao gồm và đặc biệt quan trọng nhất là KHÔNG BAO GỒM những gì? (Ví dụ: Tính năng gửi email thông báo sau khi hoàn tất Flow có nên đưa vào lúc này hay để Phase sau?)"
+
+**Q3: Phương án kỹ thuật (Alternatives & Trade-offs)**
+- "Dựa trên mô tả, tôi có 2 hướng tiếp cận để xử lý kỹ thuật nhằm đạt hiệu suất tốt nhất:
+  - **Hướng A**: {Mô tả giải pháp nhanh, MVP} - Pros: {Lợi ích} / Cons: {Bất lợi về scale}.
+  - **Hướng B**: {Mô tả giải pháp phức tạp nhưng chuẩn Architecture} - Pros: {Scale tốt, chuẩn} / Cons: {Tốn thời gian dev}.
+  Bạn ưu tiên Hướng A hay B?"
+
+**Q4: Giới hạn hệ thống (Constraints & Security)**
+- "Có yêu cầu gắt gao nào về hiệu năng (VD: xử lý 10.000 records/giây) hay bảo mật (Audit Log, Data Masking) mà chúng ta phải cân nhắc ngay từ Phase Database Schema không?"
+
+**Q5: Tích hợp hệ thống (Integration)**
+- "Tính năng có yêu cầu đồng bộ, gọi API đến hệ thống bên thứ 3 nào không (VD: Hệ thống Payment, CMIS, hay HRM)?"
+
+*(Lưu ý cho AI: In ra màn hình các câu hỏi bằng Markdown có format bôi đậm rõ ràng, dễ nhìn, chia dòng hợp lý. Không in một cục text tảng).*
+
+### Bước 4: Đánh giá Quy mô (Scope Assessment & Reality Check)
+Sau khi user cung cấp câu trả lời, Agent thực hiện kiểm tra kiểm tra xem Feature này có "quá khổ" so với 1 phiên làm việc hay không:
+- **Feature quá lớn?** (Chẳng hạn: Cần hơn 5 bảng DB mới, 10 APIs liên quan, hoặc nhiều màn hình Web Form phức tạp).
+  - Hành động: Báo động! Đề xuất chia tính năng (Split the feature) thành các Sub-features nhỏ hơn theo phương pháp "Phased Approach" (Giai đoạn). Đề nghị chốt lại Scope cho Phase 1 là đủ Minimum Viable Feature.
+- **Feature cực kỳ nhỏ lẻ?** (Chỉ thêm 1 trường DB, chỉ đổi cấu trúc JSON trên 1 file).
+  - Hành động: Đề nghị hạ workflow xuống dùng `feature-small` cho nhanh nhẹn.
+
+### Bước 5: Chốt hạ Design Brief (Bản tóm tắt thiết kế chốt)
+Dựa vào 100% dữ kiện thu thập, xuất ra một Design Brief chốt lại mọi luồng suy nghĩ. **KHÔNG in Spec vội**. Đây là phiên bản tóm lược của giải pháp:
+
+```markdown
+## Design Brief: {feature_name}
+- **Objective (Mục tiêu)**: {Tóm gọn trong 1 câu}
+- **In-Scope (Tính năng làm đợt này)**: {Bullet points}
+- **Out-of-Scope (Tính năng gác lại)**: {Bullet points}
+- **Approach đã chọn**: {Hướng đi kỹ thuật chốt, ví dụ Hướng B}
+- **Alternatives Rejected**: {Tại sao không chọn Hướng A}
+- **Constraints / Risks (Rủi ro)**: {Vấn đề bảo mật, tải trọng, tích hợp...}
+- **Impact (Phạm vi tác động)**: Backend ☑ / Frontend ☑ / Database ☑
+- **Complexity Estimate**: Large / Medium / Small
+```
+
+### Bước 6: LẬP CHỐT CHẶN (HARD-GATE)
+Đã gọi là Hard-Gate thì KHÔNG được đi tiếp, dù mô hình LLM có xu hướng tự động sinh code. Bắt buộc kết thúc câu thoại của Agent với Blockquote sau:
+
+```markdown
+> [!IMPORTANT]
+> Design Brief đã sẵn sàng. Bạn vui lòng đọc kỹ trước khi chúng ta tiến hành Specify (Đặc tả chi tiết).
+> **Bạn có ĐỒNG Ý duyệt Design Brief này để chuyển sang Phase 1: Specify không?**
+> (Gõ "Ok" để tiếp tục, hoặc chỉnh sửa lại Design nếu bạn chưa ưng ý).
+```
+
+### Bước 7: Phản ứng của Agent với User's Decision
+- **User gõ "Ok" / "Approve"**: Agent xác nhận thành công và tự động chuyển giao flow cho `evnict-kit-feature-large` tiếp tục Phase 1: Sinh Spec File.
+- **User gõ thay đổi / feedback**: Bắt tay ngay vào cập nhật bước 5 `Design Brief`, tuyệt đối kiên nhẫn làm lại bài toán Hard-Gate cho tới khi 2 bên đồng thuận. Đoạn này có thể lặp lại nhiều lần.
+
+---
+
+## 6. Mô phỏng Phiên Đối thoại Thực tế (Mock Interaction)
+**User**: `Tính năng mới: Làm trang hiển thị lịch sử mua hàng, cho phép xuất PDF bill.`
+**Agent (Bước 2)**: Nhận diện đây là Fullstack Feature (Frontend cần giao diện trang, Backend cần API trả lịch sử + generate PDF).
+**Agent (Bước 3)**: Đặt các câu hỏi:
+- *Q1*: Phần giao diện History có cần thanh filter date range không? Hay load tất cả?
+- *Q2*: Phần xuất PDF, anh ưu tiên Hướng A (FE tự xài html2canvas gen PDF cho nhẹ server) hay Hướng B (BE dùng JasperReports gen PDF rất chuẩn form nhưng load BE)?
+- *Q3*: Form này có cần bảo mật Anti-crawler bóc dữ liệu hàng loạt không?
+**User**: `Có filter Date. Làm Hướng B. Có giới hạn rate limit.`
+**Agent**: Tiến hành sinh Design Brief từ kết quả. Chặn lệnh bắt User gõ OK.
+**User**: `OK`
+**Agent**: Khởi chạy `/evnict-kit:feature-large` -> Specify Phase.
+
+---
+
+## 7. Anti-patterns (Tuyệt đối Tránh)
+Những lỗi sai Agent thường mắc khi Brainstorming:
+1. **Thiếu kiên nhẫn (Rushing to Code)**: Nhảy thẳng vào viết Code hoặc SQL Database Schema trước khi Design Brief được người dùng "Duyệt".
+2. **Liệt kê câu hỏi vô nghĩa (Dumb Questions)**: Đưa các câu hỏi không liên quan đến scope ảnh hưởng (ví dụ hỏi tên table là gì, màu nút bấm ra sao).
+3. **Câu hỏi mở bế tắc (Open-ended Deadlock)**: Hỏi "Bạn muốn hệ thống hoạt động như thế nào?" mà không đưa ra Hướng A, Hướng B để user chọn. Điều này làm user phải viết text quá nhiều.
+4. **Giả vờ hỏi nhưng rồi tự trả lời**: Hỏi user nhưng cùng lúc in ra cả file Spec khổng lồ dựa trên giả định. (Đây là hành vi bỏ chốt chặn HARD-GATE).
+5. **Gãy kết nối Front/Back**: Quên nhắc nhở user ngay từ Bước 2 rằng feature này đòi hỏi sự đồng bộ giữa client agent và server agent.
+6. **Mất Context**: Không tóm tắt Alternatives bị loại bỏ, dẫn đến sau này bị dev team review hỏi lại "tại sao không làm cách A".

package/templates/content/skills/evnict-kit-bug-fix/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: evnict-kit-bug-fix
+description: Bug fix workflow — reproduce → root cause → TDD fix → scan similar → postmortem. Quy trình sửa lỗi có hệ thống.
+compatibility: All tech stacks
+---
+
+# evnict-kit-bug-fix — Sửa Lỗi
+
+## Khi nào dùng
+- Bug report từ tester/user
+- Lỗi phát hiện trong quá trình phát triển
+- Regression bug
+
+## Input Parameters
+- `description` (bắt buộc): Mô tả bug
+- `severity` (optional): critical | high | medium | low
+- `steps_to_reproduce` (optional): Các bước tái tạo
+
+---
+
+## Workflow Steps
+
+### Bước 1: Query Wiki
+Tìm trong wiki xem bug này đã được report/fix trước đó chưa:
+```bash
+grep -rl "{keyword}" {wiki_path}/processed/ --include="*.md"
+```
+Nếu đã có → đọc cách fix trước đó.
+
+### Bước 2: Reproduce
+1. Đọc steps to reproduce
+2. Tìm file/module liên quan
+3. Nếu có test → chạy test xem fail ở đâu
+4. **Tạo test case reproduce lỗi** (RED phase — test PHẢI FAIL)
+
+```java
+@Test
+@DisplayName("BUG: {description}")
+void reproduce_bug_description() {
+    // Arrange — setup data gây lỗi
+    // Act — thực hiện action gây lỗi
+    // Assert — verify kết quả sai (EXPECTED TO FAIL)
+}
+```
+
+### Bước 3: Root Cause Analysis
+1. Đọc code liên quan
+2. Trace logic từ input → output
+3. Xác định chính xác dòng code gây lỗi
+4. Ghi lại root cause:
+
+```markdown
+## Root Cause
+- File: {path}
+- Line: {line}
+- Issue: {description}
+- Why: {explanation}
+```
+
+### Bước 4: TDD Fix
+1. Test reproduce ĐÃ FAIL (RED) ✅
+2. Fix code → test PASS (GREEN)
+3. Refactor nếu cần (test vẫn PASS)
+4. Chạy ALL tests → PASS
+
+```bash
+./mvnw test          # hoặc ng test --watch=false
+./mvnw compile       # Build OK
+```
+
+### Bước 5: Scan Similar
+Tìm pattern lỗi tương tự trong codebase:
+```bash
+grep -rn "{error pattern}" --include="*.java" src/
+```
+Nếu tìm thấy → fix luôn (prevent regression).
+
+### Bước 6: Commit
+```bash
+git add .
+git commit -m "fix({module}): {description} [BUG-{id}]"
+```
+
+### Bước 7: Push Wiki
+Dùng skill `evnict-kit-wiki` push kiến thức:
+- Bug description
+- Root cause
+- Fix approach
+- Similar patterns to watch for
+
+---
+
+## 3-Strike Rule
+Nếu fix FAIL > 3 lần cho cùng 1 bug:
+1. **DỪNG** phiên AI
+2. Báo user: "Bug cần phân tích thủ công"
+3. Log lại 3 lần thử và kết quả
+
+---
+
+## Tiêu chí hoàn thành
+- [ ] Bug reproduced bằng test case
+- [ ] Root cause identified
+- [ ] Fix implemented (TDD)
+- [ ] All tests PASS
+- [ ] Similar patterns scanned
+- [ ] Commit message chuẩn
+- [ ] Wiki updated

package/templates/content/skills/evnict-kit-checkpoint/SKILL.md

@@ -0,0 +1,156 @@
+---
+name: evnict-kit-checkpoint
+description: Checkpoint & Rollback plan theo QĐ-TTPM Mục 8.8 — tạo branch, commit checkpoint, stash, lập rollback plan trước khi AI Agent thực hiện thay đổi.
+compatibility: Git 2.x+
+---
+
+# evnict-kit-checkpoint — Checkpoint & Rollback
+
+## Khi nào dùng
+- TRƯỚC MỖI phiên làm việc với AI Agent
+- Trước thay đổi lớn (nhiều file/module)
+- Khi cần tạo rollback plan bằng văn bản
+
+## Input Parameters
+- `action` (bắt buộc): create | rollback | plan | status
+- `description` (optional): Mô tả checkpoint
+
+---
+
+## Workflow Steps
+
+### Action: CREATE — Tạo checkpoint
+
+#### Bước 1: Kiểm tra git status
+```bash
+git status
+git stash list
+```
+
+#### Bước 2: Chọn strategy
+| Tình huống | Strategy | Command |
+|------------|----------|---------|
+| Feature mới | Branch mới | `git checkout -b feature/{slug}` |
+| Task nhỏ | Commit checkpoint | `git add . && git commit -m "checkpoint: {desc}"` |
+| Thử nghiệm | Stash | `git stash push -m "{desc}"` |
+
+#### Bước 3: Tạo checkpoint
+```bash
+# Option 1: Feature branch (KHUYẾN NGHỊ)
+git checkout -b feature/{slug}-{date}
+
+# Option 2: Commit checkpoint
+git add .
+git commit -m "checkpoint: before {description}"
+
+# Option 3: Stash
+git stash push -m "checkpoint: {description}"
+```
+
+#### Bước 4: Confirm
+```
+✅ Checkpoint created
+   Strategy: {branch|commit|stash}
+   Reference: {branch name | commit hash | stash ref}
+   Rollback: git checkout main | git reset HEAD~1 | git stash pop
+```
+
+---
+
+### Action: ROLLBACK — Thực hiện rollback
+
+#### Bước 1: Xác định checkpoint
+```bash
+git log --oneline -5    # Tìm commit checkpoint
+git stash list           # Tìm stash
+git branch               # Tìm branch
+```
+
+#### Bước 2: Rollback
+```bash
+# Nếu dùng branch → quay về main
+git checkout main
+git branch -D feature/{slug}
+
+# Nếu dùng commit checkpoint → reset
+git reset --hard {checkpoint-hash}
+
+# Nếu dùng stash → pop
+git stash pop
+```
+
+#### Bước 3: Verify
+```bash
+git status               # Clean
+git log --oneline -3     # Confirm đúng state
+```
+
+---
+
+### Action: PLAN — Tạo Rollback Plan (cho thay đổi lớn)
+
+Tạo file `.evnict/rollback-plan-{date}.md`:
+
+```markdown
+# Rollback Plan: {feature/task description}
+## Date: {YYYY-MM-DD}
+## Author: AI Agent
+
+## Scope of Change
+- Files affected: {count}
+- Modules: {list}
+- Database changes: {yes/no}
+- Breaking changes: {yes/no}
+
+## Checkpoint
+- Type: {branch|commit|stash}
+- Reference: {ref}
+- Created: {timestamp}
+
+## Rollback Steps
+1. `git checkout main` — Quay về main branch
+2. `git branch -D feature/{slug}` — Xóa feature branch
+3. {Nếu có DB migration} → Chạy rollback script:
+   `database/migrations/V{date}_ROLLBACK.sql`
+4. {Nếu có config change} → Revert config:
+   `git checkout {checkpoint-hash} -- path/to/config`
+
+## Verification After Rollback
+- [ ] `git status` clean
+- [ ] Build passes: `./mvnw compile`
+- [ ] Tests pass: `./mvnw test`
+- [ ] Application starts normally
+
+## Risk Assessment
+- Impact if rollback needed: {low|medium|high}
+- Data loss risk: {none|partial|full}
+- Downtime: {none|minutes|hours}
+```
+
+---
+
+### Action: STATUS — Kiểm tra checkpoint status
+
+```markdown
+## 📋 Checkpoint Status
+
+### Active Checkpoints
+| Type | Reference | Description | Date |
+|------|-----------|-------------|------|
+| branch | feature/xxx | Before auth changes | 2026-04-01 |
+| stash | stash@{0} | WIP: customer form | 2026-04-01 |
+
+### Recent Commits
+{git log --oneline -5}
+
+### Working Tree
+{git status --short}
+```
+
+---
+
+## Tiêu chí hoàn thành
+- [ ] Checkpoint tạo thành công
+- [ ] Rollback plan tạo cho thay đổi lớn
+- [ ] Revert trong ≤ 1 thao tác git
+- [ ] Verify sau rollback: build + test pass

package/templates/content/skills/evnict-kit-code-review/SKILL.md

@@ -0,0 +1,158 @@
+---
+name: evnict-kit-code-review
+description: Review checklist theo QĐ-TTPM Mục 8.10 — kiểm tra security, logic, quality, vibe coding trước khi merge. 9 hạng mục bắt buộc.
+compatibility: All tech stacks
+---
+
+# evnict-kit-code-review — Auto Code Review
+
+## Khi nào dùng
+- Trước khi merge code vào main/develop
+- Review code do AI Agent sinh ra
+- Kiểm tra toàn bộ changes trong branch hiện tại
+
+## Input Parameters
+- `scope` (optional): all | security | logic | quality (default: all)
+- `branch` (optional): Branch cần review (default: current)
+
+---
+
+## Workflow Steps
+
+### Bước 1: Thu thập changes
+```bash
+git diff --stat main..HEAD        # Files changed
+git diff main..HEAD               # Full diff
+git log --oneline main..HEAD      # Commits
+```
+
+### Bước 2: Chạy 9 hạng mục review (QĐ-TTPM Mục 8.10)
+
+#### ✅ Hạng mục 1: Security — ATTT
+Đọc rules `02-evnict-kit-security-rules.md` → scan:
+```bash
+# SQL Injection
+grep -rn "query.*+.*\"" --include="*.java" src/
+grep -rn "DSL\.field(.*+\s" --include="*.java" src/
+
+# XSS
+grep -rn "\[innerHTML\]" --include="*.html" src/
+grep -rn "bypassSecurityTrust" --include="*.ts" src/
+
+# Secrets
+grep -rn "password\s*=\s*\"" --include="*.java" --include="*.ts" src/
+
+# Data exposure
+grep -rn "ResponseEntity.ok(.*repository" --include="*.java" src/
+```
+
+| Check | Pass/Fail | Details |
+|-------|-----------|---------|
+| No SQL Injection | ✅/❌ | {details} |
+| No XSS | ✅/❌ | {details} |
+| No hardcoded secrets | ✅/❌ | {details} |
+| No data exposure | ✅/❌ | {details} |
+| Auth on endpoints | ✅/❌ | {details} |
+
+#### ✅ Hạng mục 2: Logic — Business correctness
+- [ ] Business rules implemented correctly (so sánh với spec)
+- [ ] Edge cases handled
+- [ ] Error handling đầy đủ
+- [ ] Null/empty checks
+
+#### ✅ Hạng mục 3: Quality — Code quality
+- [ ] Naming conventions tuân thủ
+- [ ] No code duplication
+- [ ] Methods không quá dài (< 50 lines)
+- [ ] Comments cho logic phức tạp
+- [ ] No dead code
+
+#### ✅ Hạng mục 4: Tests
+- [ ] Unit tests viết cho code mới
+- [ ] Tests PASS: `./mvnw test` hoặc `ng test`
+- [ ] Coverage đạt target (Service ≥ 80%, Controller ≥ 70%)
+
+#### ✅ Hạng mục 5: Build & Lint
+```bash
+./mvnw compile && echo "✅ Build OK" || echo "❌ Build FAIL"
+./mvnw spotless:check && echo "✅ Lint OK" || echo "❌ Lint FAIL"
+```
+
+#### ✅ Hạng mục 6: Vibe Coding Check
+- [ ] Không có file thay đổi không liên quan
+- [ ] Mỗi commit có message rõ ràng
+- [ ] Code có thể giải thích được
+- [ ] Không có logic trùng lặp/mâu thuẫn
+
+#### ✅ Hạng mục 7: Database
+- [ ] Migration script có rollback
+- [ ] Index cho columns thường query
+- [ ] Không DROP/TRUNCATE table production
+
+#### ✅ Hạng mục 8: Documentation
+- [ ] API mới có description
+- [ ] Complex logic có comments
+- [ ] Spec updated nếu scope thay đổi
+
+#### ✅ Hạng mục 9: Performance
+- [ ] No N+1 query
+- [ ] Pagination cho list endpoints
+- [ ] File upload có size limit
+- [ ] No unbounded loops
+
+### Bước 3: Tạo Review Report
+
+```markdown
+## 📋 Code Review Report
+### Feature: {feature-name}
+### Branch: {branch}
+### Date: {date}
+### Reviewer: AI Agent
+
+## Summary
+| Hạng mục | Status | Issues |
+|----------|--------|--------|
+| Security | ✅/❌ | {count} |
+| Logic | ✅/❌ | {count} |
+| Quality | ✅/❌ | {count} |
+| Tests | ✅/❌ | {count} |
+| Build | ✅/❌ | {count} |
+| Vibe Coding | ✅/❌ | {count} |
+| Database | ✅/❌ | {count} |
+| Documentation | ✅/❌ | {count} |
+| Performance | ✅/❌ | {count} |
+
+## ❌ Issues Found
+### Issue 1: {title}
+- Severity: Critical/High/Medium/Low
+- File: {path}
+- Line: {line}
+- Description: {desc}
+- Fix: {suggested fix}
+
+## ✅ Verdict
+{APPROVE | REQUEST CHANGES | BLOCK}
+{Reason}
+```
+
+---
+
+## Error Handling
+
+### BLOCK merge khi:
+- Security issue Critical/High → PHẢI fix trước
+- Tests FAIL → PHẢI fix
+- Build FAIL → PHẢI fix
+
+### REQUEST CHANGES khi:
+- Security issue Medium → Fix recommended
+- Quality issues → Suggest improvements
+- Missing tests → Add tests
+
+---
+
+## Tiêu chí hoàn thành
+- [ ] 9 hạng mục đã review
+- [ ] Report tạo đầy đủ
+- [ ] Critical/High issues → BLOCK
+- [ ] Verdict rõ ràng: APPROVE | REQUEST CHANGES | BLOCK