claude "Phân tích structure của project này để tôi hiểu tổng quan.

Dùng LS và Glob (KHÔNG đọc file content trừ package.json, README):
1. Tech stack: language, framework, DB, main deps từ package.json/requirements.txt
2. Directory structure: mỗi folder có ý nghĩa gì?
3. Số lượng file theo type (*.ts, *.test.ts, *.sql...)
4. Entry points: main file, server start, worker start
5. Config files: có gì đáng chú ý?
6. Kết luận: đây là monolith / microservice / monorepo?

Output dạng structured overview. Không đọc source files."

claude "Feature cần implement: User có thể export lịch sử đơn hàng ra file Excel.

TRƯỚC KHI viết bất kỳ dòng code nào, hãy làm analysis:

1. SCOPE — đọc codebase tìm:
   - Code liên quan đến Order đã có: files, functions
   - Patterns đang dùng để implement feature tương tự
   - Thư viện nào đang dùng (xlsx, exceljs, csv-writer...?)

2. DESIGN — đề xuất:
   - API endpoint: method, path, params, response type
   - Approach: sync response vs async + download link?
   - Nếu async: cần queue? file storage (S3)?
   - Ảnh hưởng đến DB schema không?

3. FILES — list chính xác:
   - Files cần tạo mới (với path)
   - Files cần sửa (với lý do)
   - Dependencies cần thêm

4. RISKS:
   - Performance: user có 10000 orders → handle như thế nào?
   - Security: user chỉ xem được orders của họ?
   - Edge cases: không có order nào? Order bị deleted?

5. EFFORT: S/M/L/XL và giải thích

Present plan. KHÔNG code. Chờ tôi confirm."

claude "BUG: Order total tính sai khi có coupon + tax

ERROR (từ Sentry):
  TypeError: Cannot read properties of undefined (reading 'discountAmount')
  at OrderService.calculateTotal (src/services/order.ts:127)
  at OrderService.applyPromotion (src/services/order.ts:89)

CONTEXT:
  - Xảy ra khi: user apply coupon FIXED_AMOUNT (giảm số tiền cố định)
  - KHÔNG xảy ra với: coupon PERCENTAGE (giảm %)
  - Môi trường: production, xảy ra 3 lần hôm nay lúc 14:23, 15:01, 15:47
  - Last deploy: hôm qua 16:00 (commit abc123)

EXPECTED: total = subtotal - discountAmount + tax
ACTUAL: crash tại line 127

FILES LIÊN QUAN (tôi đoán):
  - src/services/order.ts (chính)
  - src/domain/promotion.ts (Promotion type)
  - src/repositories/promotion.repo.ts

YÊU CẦU:
1. Đọc 3 files trên
2. Tìm root cause chính xác
3. Check: commit hôm qua có thay đổi gì ở đây? (git log -p -1 -- src/services/order.ts)
4. Fix root cause (không phải patch)
5. Viết regression test: case này không được crash nữa
6. Check: có case tương tự nào khác với FIXED_AMOUNT coupon không?"

claude "Fix đã apply. Verify:
1. Chạy: npm test -- --testPathPattern=order
2. Chạy: npm test -- --testPathPattern=promotion
3. Reproduce lại bug: tạo order + apply FIXED_AMOUNT coupon → có crash không?
4. Check related cases:
   - FIXED_AMOUNT coupon khi order total < discount amount?
   - FIXED_AMOUNT coupon = 0?
   - FIXED_AMOUNT coupon khi giỏ hàng rỗng?
5. Nếu tất cả pass: git commit với message chuẩn
   Format: fix(order): coupon discountAmount undefined when type is FIXED_AMOUNT"

claude "Tôi muốn refactor src/services/user.service.ts (hiện 600 dòng).

Phân tích trước khi làm bất cứ gì:

1. CALLERS — ai đang dùng UserService?
   Grep: 'UserService\|userService\|new User' trong toàn src/
   List: tất cả methods đang được call từ bên ngoài

2. RESPONSIBILITIES — file này đang làm gì?
   Group các methods theo responsibility:
   - Authentication (login, logout, token)
   - Profile management (update, avatar)
   - Permissions (check, grant, revoke)
   - Notification (email, push)

3. DEPENDENCIES — file này depend vào gì?
   Và gì depend vào file này?

4. TEST COVERAGE hiện tại:
   Grep: test file tương ứng. Có bao nhiêu % được test?

5. RISK ASSESSMENT:
   - Methods nào quan trọng nhất (called nhiều nhất)?
   - Methods nào có side effects phức tạp?
   - Thứ tự refactor an toàn nhất là gì?

6. PROPOSED SPLIT: đề xuất tách thành bao nhiêu service?

KHÔNG code. Chỉ analysis. Chờ tôi confirm plan."

claude "Review PR này. Tác giả: @teammate. Task: DEV-234 — Add payment retry.

Context:
- Stack: Node.js + TypeScript + Prisma
- Đọc CLAUDE.md để hiểu conventions

Đọc:
git diff main...feature/payment-retry

Review theo checklist nghiêm túc:

🔴 BLOCKING (phải fix trước merge):
□ Logic errors — code có làm đúng spec không?
□ Security: input validation, auth check, data exposure
□ Data integrity: transaction đúng chỗ chưa? Race condition?
□ Error handling: tất cả error paths được handle?
□ Breaking changes: public interface thay đổi không?

🟡 SHOULD FIX (nên fix trong PR này):
□ Performance: N+1 query, missing index, unnecessary computation
□ Conventions vi phạm (so với CLAUDE.md)
□ Missing tests cho logic quan trọng
□ Code duplication (DRY violation)

🟢 SUGGESTIONS (nice to have, optional):
□ Readability improvements
□ Better variable names
□ Simplification opportunities

Format output:
---
BLOCKING:
- [file:line] [mô tả vấn đề] → [suggestion cụ thể]

SHOULD FIX:
- [...]

SUGGESTIONS:
- [...]

POSITIVE (điều đã làm tốt):
- [...]
---"

claude "API GET /api/dashboard trả về sau 3–5 giây. Cần dưới 500ms.

Điều tra theo thứ tự từ dễ đến khó:

LAYER 1: DB queries (nguyên nhân #1 phổ biến)
  Đọc: controller → service → repository của /dashboard endpoint
  Tìm:
  a) N+1 query: có loop nào bên trong mà query DB không?
     Dấu hiệu: findMany rồi forEach với findById
  b) Missing eager loading: có relation nào không được include?
  c) Select *: có dùng select: undefined (lấy toàn bộ fields)?
  d) Missing WHERE index: check prisma/schema.prisma có @index chưa?
  e) Không có limit/pagination: có thể load 10K records không?

LAYER 2: Computation
  Tìm: logic nào chạy nhiều lần trong loop?
  Tìm: calculation nào có thể cache hoặc precompute?

LAYER 3: External calls
  Grep: fetch, axios, got, http.request trong code path này
  Có gọi external API không? Có await sequential không?

Output:
- Ranked list của probable causes (by likelihood)
- Query count estimate cho 1 request
- Recommendation: quick win vs proper fix"

claude "Đã xác định N+1 query trong OrderService.getDashboard():

Hiện tại (N+1):
  const orders = await orderRepo.findAll();
  for (const order of orders) {
    order.items = await itemRepo.findByOrderId(order.id); // N queries!
    order.user = await userRepo.findById(order.userId);   // N queries!
  }

Fix với Prisma eager loading:
1. Update repository method để include relations
2. Đảm bảo chỉ select fields cần thiết (không select *)
3. Thêm pagination (limit 50 mặc định)
4. Viết benchmark: đo query count trước/sau

Sau khi fix:
  npm run dev
  Gọi API với curl, check logs: query count phải giảm từ N+1 xuống 1-2 queries."

claude "Full security audit cho project. Tìm và fix theo priority.

🔴 CRITICAL — fix ngay lập tức:

A1 — Injection:
  Grep: raw SQL (template literals với user input), $queryRaw, eval(), exec()
  Grep: Prisma queries với user input trực tiếp (không parameterized)

A2 — Broken Authentication:
  Kiểm tra: JWT secret từ env? JWT verify đúng algorithm? Token expiry?
  Kiểm tra: refresh token rotation? Token blacklist khi logout?
  Kiểm tra: brute force protection trên login endpoint?

A3 — Sensitive Data Exposure:
  Grep: console.log, logger.info với password, token, card, ssn, secret
  Kiểm tra: response có trả về password hash không?
  Kiểm tra: error response có leak stack trace không?

A4 — Broken Access Control:
  Kiểm tra từng GET/POST/PUT/DELETE endpoint:
    - Có auth middleware không?
    - User chỉ xem được resource của mình không?
    - Admin endpoints có check role không?
  Tìm IDOR: GET /api/orders/:id — có check order.userId === req.user.id?

A5 — Security Misconfiguration:
  Kiểm tra: CORS config có allow * không?
  Kiểm tra: Helmet.js được dùng không?
  Kiểm tra: rate limiting trên auth endpoints?
  Kiểm tra: .env có bị commit vào git không? (git log --all -- .env)

A7 — Cross-Site Scripting (nếu có render HTML):
  Grep: innerHTML, dangerouslySetInnerHTML, res.send với user input

A8 — Insecure Deserialization:
  Grep: JSON.parse với user input không validate
  Grep: eval, Function constructor

A9 — Vulnerable Components:
  Chạy: npm audit --audit-level=high
  List: packages có CVE HIGH hoặc CRITICAL

Output: file, line, severity, description, fix.
Fix tất cả CRITICAL và HIGH trước khi tạo report."

claude "Viết comprehensive tests cho src/services/pricing.service.ts

Đọc file trước. Sau đó viết tests theo principles:

PRINCIPLES (enforce nghiêm):
1. Test BEHAVIOR, không test implementation
   ✅ 'should return 10% discount when order > 1,000,000 VND'
   ❌ 'should call calculateTierDiscount with argument 1000000'

2. Mỗi test: 1 assertion CHÍNH (có thể có assertion phụ)
   Không viết test kiểm tra 5 thứ cùng lúc

3. Test name đủ rõ để làm documentation:
   describe('PricingService')
     describe('calculateDiscount')
       it('should return 0 when order total is below minimum threshold')
       it('should apply 10% when total is between 1M and 5M')
       it('should apply 15% + free shipping when total exceeds 5M')
       it('should stack VIP bonus on top of tier discount')
       it('should not exceed 100% total discount')
       it('should return error when discount config is missing')

4. Edge cases THỰC SỰ CÓ THỂ XẢY RA:
   - Input = 0, negative, very large number
   - Floating point: 999999.99 vs 1000000.00
   - VIP user với no tier discount
   - Multiple coupons stacked

5. Mock chỉ external dependencies:
   - DB → mock repository
   - Redis → mock cache
   - External API → mock
   KHÔNG mock: pure functions, calculations, domain logic

6. Test isolation: mỗi test hoàn toàn độc lập, không depend vào test khác

Sau khi viết: chạy npm test -- --testPathPattern=pricing
Coverage target: 95%+ cho pricing service (core business logic)"

# Haiku: task mechanical, không cần reasoning
claude --model claude-haiku-4-5 "format code theo prettier config"
claude --model claude-haiku-4-5 "thêm JSDoc cho tất cả public methods trong src/services/"
claude --model claude-haiku-4-5 "rename variable 'x' thành 'orderTotal' trong file này"
claude --model claude-haiku-4-5 "chạy npm audit và list HIGH/CRITICAL vulnerabilities"

# Sonnet: daily dev work
claude "implement feature X"
claude "debug lỗi Y"

# Opus: chỉ khi thực sự cần
claude --model claude-opus-4 \
  "design database schema cho multi-tenant SaaS với yêu cầu phức tạp..."

claude "Tôi có tài liệu 詳細設計書 (detail design spec) từ client Nhật.
[upload file hoặc paste nội dung tiếng Nhật]

Phân tích tài liệu này với vai trò TESTER, không phải developer:

1. FEATURE LIST — liệt kê tất cả tính năng được mô tả:
   Format: [Tên feature tiếng Nhật] — [Mô tả tiếng Việt ngắn gọn]

2. BUSINESS RULES — các quy tắc nghiệp vụ quan trọng:
   Đặc biệt chú ý: điều kiện (条件), ngoại lệ (例外), giới hạn (制限)
   Format: BR-001: [Phát biểu rõ ràng bằng tiếng Việt]

3. INPUT/OUTPUT SPEC — mỗi màn hình/function:
   - Input fields: tên, kiểu dữ liệu, bắt buộc/không, validation rules
   - Expected output: format, điều kiện hiển thị
   - Error messages: khi nào xuất hiện, nội dung

4. EDGE CASES ẨN — những gì spec KHÔNG nói rõ nhưng tester phải test:
   Ví dụ: 'nhập số âm', 'để trống', 'ký tự đặc biệt', 'quá giới hạn'

5. AMBIGUITIES (不明点) — chỗ nào mơ hồ cần hỏi lại client:
   Format: [Câu hỏi tiếng Nhật] — [Lý do cần làm rõ]

6. PRIORITY — feature nào critical cho demo đầu tiên?

Output bằng tiếng Việt. Giữ nguyên thuật ngữ Nhật quan trọng kèm giải thích."

claude "Đây là 画面設計書 (screen design spec) cho màn hình [tên màn hình].
[upload ảnh/PDF tài liệu]

Extract thông tin cho tester:

1. SCREEN ELEMENTS — mỗi element trên màn hình:
   | ID | Tên (JP) | Loại | Bắt buộc | Validation | Ghi chú |

2. BUTTON ACTIONS — mỗi button/link làm gì:
   [Button名] → [Action] → [Kết quả hiển thị] → [Error nếu fail]

3. DISPLAY CONDITIONS — element nào hiển thị theo điều kiện:
   Ví dụ: 'Nút DELETE chỉ hiển thị khi user là admin'

4. NAVIGATION FLOW — từ màn hình này đi đến đâu:
   Điều kiện nào → navigate đến màn hình nào

5. TEST-CRITICAL NOTES:
   - Trường nào client Nhật hay kiểm tra kỹ nhất?
   - Formatting rules (ngày tháng, tiền tệ, số điện thoại Nhật)
   - Ký tự đặc biệt: 全角/半角 (zenkaku/hankaku) rules"

claude "Sinh test case cho feature: [Tên feature] từ spec đã phân tích.

Spec tham chiếu:
- Requirement ID: REQ-045
- Mô tả: User có thể tìm kiếm đơn hàng theo nhiều tiêu chí
- Business rules: [liệt kê từ analysis trước]

Sinh test case theo format Excel-ready (TSV):

Columns:
No | テストID | テスト項目 | テスト条件 | 操作手順 | 期待結果 | 優先度 | 対応要件ID | 備考

Rules khi sinh:
1. Mỗi test case = 1 điều kiện duy nhất
2. Phủ đủ: positive cases + negative cases + boundary + edge cases
3. 操作手順 phải đủ chi tiết để người khác thực hiện được (không assume)
4. 期待結果 phải specific, measurable — không viết 'hiển thị đúng'
5. Priority: 高(cao) / 中(trung) / 低(thấp)
6. Đặt tên theo convention: TC-[FEATURE_CODE]-[001, 002...]

Categories phải có:
□ Normal cases (正常系): happy path với dữ liệu hợp lệ
□ Abnormal cases (異常系): input không hợp lệ, thiếu data
□ Boundary cases (境界値): min/max, đúng giới hạn, vượt giới hạn
□ Edge cases: empty state, special characters (tiếng Nhật, symbols)
□ Permission cases: role khác nhau thấy gì
□ Concurrent cases: 2 user cùng thao tác

Output TSV — paste thẳng vào Excel được."

claude "Field: 'số lượng đặt hàng'
Spec: integer, min=1, max=9999, bắt buộc

Tự động sinh test cases theo Boundary Value Analysis + Equivalence Partitioning:

Equivalence classes:
- Valid: 1 ≤ x ≤ 9999
- Invalid-low: x < 1 (0, âm số)
- Invalid-high: x > 9999
- Invalid-type: không phải số (chữ, ký tự đặc biệt, tiếng Nhật)
- Invalid-empty: để trống

Boundary values: 0, 1, 2, 9998, 9999, 10000
Special: -1, 0.5, 9999.9, '１' (全角số), ' ' (space), null

Với mỗi value → expected behavior + error message cụ thể.
Format: TC-QTY-001 đến TC-QTY-XXX, sẵn sàng cho Excel."

claude "Feature: tính phí vận chuyển
Rules từ spec:
- Đơn < 500k VND + trong tỉnh → phí 30k
- Đơn < 500k VND + liên tỉnh → phí 50k
- Đơn >= 500k VND + trong tỉnh → miễn phí
- Đơn >= 500k VND + liên tỉnh → phí 20k
- Thành viên VIP: giảm 50% phí vận chuyển
- Đơn hàng đặc biệt (kích thước lớn): phí x2

Tạo Decision Table coverage:
1. List tất cả conditions (điều kiện)
2. List tất cả actions (kết quả)
3. Generate minimum test cases để cover all combinations
4. Highlight: combination nào dễ bug nhất?
5. Tạo test case cho từng row của decision table"

claude "Viết bug report chuẩn format Nhật từ thông tin sau:

Bug tôi phát hiện:
- Màn hình: [tên màn hình / URL]
- Thao tác: [mô tả ngắn tôi đã làm gì]
- Kết quả thực tế: [cái gì xảy ra]
- Kết quả mong đợi: [cái gì phải xảy ra]
- Screenshot: [tôi sẽ đính kèm]
- Môi trường: staging / browser Chrome 120 / OS Windows 11

Viết bug report TIẾNG NHẬT với format:

【バグ報告】

■ タイトル: [Tóm tắt bug trong 1 dòng, rõ ràng, không mơ hồ]

■ 発生環境:
  - URL:
  - ブラウザ:
  - OS:
  - アカウント: [loại account, không ghi password]
  - 発生日時:

■ 再現手順: [Step by step, numbered, cực kỳ cụ thể]
  1.
  2.
  3.

■ 実際の結果: [Mô tả chính xác, khách quan, không subjective]

■ 期待される結果: [Theo spec nào? Reference REQ ID nếu có]

■ 再現率: [毎回 / 2回に1回 / まれに]

■ 優先度: [緊急 / 高 / 中 / 低]

■ 影響範囲: [Màn hình nào khác bị ảnh hưởng?]

■ 備考: [Thông tin thêm, hypothesis về nguyên nhân]

Dùng kính ngữ phù hợp, tone professional."

claude "Client Nhật reply: '再現できませんでした。詳細な手順をご共有いただけますか？'
(Không reproduce được. Bạn có thể chia sẻ thêm chi tiết không?)

Bug gốc tôi báo: [mô tả]

Viết email reply tiếng Nhật:
1. Lịch sự acknowledge reply của họ
2. Bổ sung thêm thông tin:
   - Exact steps với screenshots từng bước
   - Browser dev tools console log (nếu có)
   - Network request/response nếu liên quan API
   - Video recording URL (nếu có)
   - Exact data dùng để reproduce (anonymized)
   - Nghi ngờ: bug có thể chỉ xảy ra với điều kiện đặc biệt gì?
3. Đề nghị: có thể schedule call/screen share để reproduce cùng?
4. Cam kết follow up

Tone: respectful, helpful, không defensive."

claude "Release v2.3 sắp deploy. Xác định scope regression test.

Changes trong v2.3 (từ git diff / release notes):
[paste danh sách thay đổi]

Codebase modules (từ CLAUDE.md hoặc tôi mô tả):
- Module A: Order management
- Module B: Payment
- Module C: User management
- Module D: Reporting

Phân tích impact và sinh regression test plan:

1. DIRECT IMPACT — modules bị thay đổi trực tiếp:
   → Test 100% test cases của module này

2. INDIRECT IMPACT — modules phụ thuộc vào module bị đổi:
   (dùng dependency analysis)
   → Test critical paths của các module này

3. NO IMPACT — modules không liên quan:
   → Smoke test chỉ, không full regression

4. RISK-BASED PRIORITY:
   High: payment flow, login/auth, data mutation
   Medium: search, filter, display
   Low: UI cosmetics, non-critical features

5. REGRESSION TEST SUITE:
   Estimated: X test cases
   Time estimate: Y giờ (với Z tester)

   Tạo sẵn checklist Excel với các TCs được recommend."

claude "Tổng hợp テスト成績書 (test result report) cho release v2.3.

Raw data từ test execution:
- Total test cases: [số]
- Pass: [số]
- Fail: [số]
- Blocked: [số]
- Not executed: [số]
- Bugs found: [list bug IDs]
- Bugs fixed: [list]
- Bugs deferred: [list với lý do]

Tạo report TIẾNG NHẬT:

# テスト成績書
システム名: [tên]
バージョン: v2.3
テスト期間: YYYY/MM/DD ～ YYYY/MM/DD
作成者: [tên]
承認者: [để trống cho manager điền]

## 1. テスト概要
[Summary ngắn gọn — không quá 5 câu]

## 2. テスト実施結果
| 項目 | 件数 | 割合 |
| テストケース総数 | X | 100% |
| 合格（OK） | Y | Z% |
| 不合格（NG） | A | B% |
| 未実施 | C | D% |

## 3. バグ統計
| 優先度 | 検出数 | 修正済 | 保留 |
| 緊急 | | | |
| 高 | | | |

## 4. 未解決バグ（リリース時残存）
[List bugs deferred với justification tại sao OK để release]

## 5. リリース判定
→ リリース可 / 条件付きリリース可 / リリース不可
理由: [explanation]

## 6. 今後の課題
[Items sẽ address trong next sprint]"

claude "Tổng hợp monthly quality report tháng [X].

Data:
- Bugs reported: [số, theo priority breakdown]
- Bugs fixed: [số]
- Open bugs: [số]
- Test cases executed: [số]
- Coverage rate: [%]
- Previous month comparison: [data]

Tạo report ngắn gọn tiếng Nhật (1 trang):

品質レポート [YYYY年MM月]

1. 今月のサマリー — highlights tháng này
2. バグ推移グラフ (text chart) — trend so với 3 tháng trước
3. 品質指標 — metrics chính
4. 主な改善点 — những gì team đã cải thiện
5. 課題と対策 — issues và plan
6. 来月の計画 — plan tháng tới

Tone: professional, không exaggerate, honest về issues."

claude "Phân tích yêu cầu từ client Nhật (tiếng Nhật):
[paste spec, email, hoặc meeting notes]

Đóng vai BA có kinh nghiệm với client Nhật. Phân tích:

1. EXPLICIT REQUIREMENTS — những gì được nói rõ:
   [List bằng tiếng Việt, reference đến đoạn gốc tiếng Nhật]

2. IMPLICIT REQUIREMENTS — những gì KHÔNG nói nhưng client mặc định biết:
   Với client Nhật, typical assumptions:
   - 全角/半角 (zenkaku/hankaku) validation cho text inputs
   - Date format: YYYY年MM月DD日 hoặc YYYY/MM/DD
   - Number format: 1,000,000 (dấu phẩy phân cách nghìn)
   - Error messages phải bằng tiếng Nhật
   - Loading state cho mọi async operation
   - Confirmation dialog trước khi delete/submit quan trọng
   → List những implicit requirements likely cho project này

3. AMBIGUITIES (不明点) — những chỗ mơ hồ:
   Với mỗi ambiguity:
   - Vấn đề: [mô tả chỗ mơ hồ]
   - Interpretation A: [cách hiểu 1]
   - Interpretation B: [cách hiểu 2]
   - Risk nếu chọn sai: [High/Medium/Low]
   - Câu hỏi cần hỏi client: [bằng tiếng Nhật, lịch sự]

4. MISSING REQUIREMENTS — những gì spec không đề cập nhưng cần:
   - Error handling: khi API fail, user thấy gì?
   - Empty state: khi không có data, hiển thị gì?
   - Pagination: nếu có 10,000 records?
   - Permissions: ai được làm gì?
   - Audit log: có cần ghi lại action không?

5. DEPENDENCY & ASSUMPTION:
   Feature này phụ thuộc vào feature nào khác chưa có?"

claude "Yêu cầu thô từ client Nhật:
'管理者が月次レポートをExcelでエクスポートできるようにしたい。
フィルター機能もつけてほしい。'
(Muốn admin có thể export monthly report ra Excel. Cũng muốn có filter.)

Đọc codebase hiện tại (src/services/, src/routes/) để hiểu context kỹ thuật.
Viết User Story HOÀN CHỈNH:

---
USER STORY: US-087
Title: Admin export monthly report as Excel

## User Story
As a システム管理者 (system administrator),
I want to export monthly order reports as Excel files with filter options,
So that I can analyze business performance offline and share with stakeholders.

## Context & Background
[Mô tả context tại sao feature này quan trọng]
[Reference đến existing functionality liên quan]

## Acceptance Criteria (BDD format, testable)
Given [precondition rõ ràng]
When [action cụ thể]
Then [expected result measurable]
And [additional assertions]

Scenario 1: Export without filter (happy path)
Given tôi đang login với role Admin
  And có ít nhất 1 order trong tháng được chọn
When tôi click Export button
  And chọn tháng 2024/01
  And click Confirm
Then file Excel được download tự động
  And filename format: 'orders-2024-01.xlsx'
  And file chứa tất cả orders trong tháng 01/2024
  And header row: [list columns cụ thể]
  And số tiền format: #,##0 (comma separated, no decimal)
  And date format: YYYY/MM/DD

Scenario 2: Export with filter
Scenario 3: No data for selected month
Scenario 4: Large dataset (> 10,000 records)
Scenario 5: Non-admin access attempt

## Out of Scope (明示的に除外)
- Export to CSV format (future)
- Scheduled/automated export (future)
- Real-time data streaming

## Open Questions (確認事項)
1. [Câu hỏi tiếng Nhật cho client]
2. [Câu hỏi cho dev team]

## Technical Notes (for dev)
- Existing: src/services/reporting.ts — có method getMonthlyOrders()
- Need: Excel generation (suggest exceljs — đã có trong project)
- Performance: streaming for > 1000 records

## Definition of Done
□ All ACs pass
□ Test cases written and pass
□ Code reviewed
□ Client demo accepted"

claude "Client Nhật vừa yêu cầu thay đổi:

Spec cũ (v2.0, đã confirm ngày XX/XX):
'検索結果は最大100件まで表示する'
(Hiển thị tối đa 100 kết quả tìm kiếm)

Spec mới (email ngày YY/YY):
'検索結果は全件表示できるようにしてほしい'
(Muốn hiển thị toàn bộ kết quả)

Đọc codebase để hiểu current implementation.

Phân tích impact TOÀN DIỆN:

1. TECHNICAL IMPACT:
   □ Code cần thay đổi: [list files + effort estimate]
   □ Performance risk: hiện tại có bao nhiêu records max?
     Nếu 100K records → UI sẽ crash / timeout
   □ DB impact: query hiện tại có LIMIT không? Index đủ không?
   □ Frontend impact: cần virtual scrolling? Pagination thay thế?

2. TESTING IMPACT:
   □ Test cases nào cần update/viết mới?
   □ Performance test cần thêm: load test với X records

3. SCHEDULE IMPACT:
   □ Current sprint: feature này đang ở đâu? (dev / test / done?)
   □ Additional effort: [X giờ / ngày]
   □ Nếu phải deliver đúng deadline → gì phải defer?

4. RISK ASSESSMENT:
   □ Technical risk: [High] — display all có thể gây performance issue nghiêm trọng
   □ Recommended approach: pagination với 'load more' hoặc 'export all'?

5. RESPONSE TO CLIENT (tiếng Nhật):
   Viết email lịch sự:
   - Xác nhận đã nhận yêu cầu thay đổi
   - Trình bày impact (nhẹ nhàng nhưng rõ ràng)
   - Đề xuất alternative nếu có
   - Hỏi confirm về timeline và priority
   - KHÔNG từ chối thẳng, KHÔNG commit ngay không có plan"

claude "Tôi có các ambiguities sau cần hỏi client Nhật:

1. Khi user search không có kết quả, hiển thị gì?
2. Giới hạn file upload là bao nhiêu MB?
3. Date picker có cho phép chọn ngày trong quá khứ không?
4. Nếu session expire khi đang điền form, data có bị mất không?

Viết QA票 tiếng Nhật, format Excel-ready:

# QA票 (質問票)
プロジェクト名: [tên]
作成日: YYYY/MM/DD
作成者: [tên BA]
バージョン: v1.0

| No | カテゴリ | 質問内容 | 関連画面/機能 | 参照資料 | 優先度 | 回答期限 | 回答 | 対応内容 |

Với mỗi câu hỏi:
- Tiếng Nhật rõ ràng, kính ngữ phù hợp
- Reference đến spec section nếu có
- Describe: impact nếu không clarify (tại sao urgent?)
- Provide example nếu cần (ví dụ A hay B?)
- Priority: 高/中/低

Câu hỏi phải:
✅ Cụ thể, có thể trả lời Yes/No hoặc chọn option
✅ Không hỏi nhiều việc trong 1 câu
✅ Include context đủ để client hiểu mà không cần đọc spec lại
❌ Không hỏi chung chung 'これで合っていますか' (đúng không?)"

claude "Câu hỏi tôi hỏi:
'検索結果が0件の場合、どのようなメッセージを表示すればよいですか？'
(Khi không có kết quả, hiển thị message gì?)

Client trả lời:
'適切なメッセージを表示してください。'
(Hãy hiển thị message phù hợp.)

Đây là câu trả lời mơ hồ — chưa actionable.

Viết follow-up email tiếng Nhật:
1. Thank client cho reply
2. Xác nhận đã hiểu intent
3. Propose 2-3 options cụ thể (với mockup text nếu cần):
   Option A: '検索結果が見つかりませんでした。検索条件を変えてお試しください。'
   Option B: '該当するデータがありません。'
   Option C: [option khác]
4. Hỏi client muốn chọn option nào?
5. Nếu có deadline → mention lịch sự

Tránh: đừng làm client cảm thấy bị pressure hoặc được cho là không trả lời đúng."

claude "Chuẩn bị Sprint Review presentation cho client Nhật.

Sprint data:
- Sprint: Sprint 8 (2024/01/15 - 2024/01/26)
- Committed: 32 points (8 stories)
- Completed: 28 points (7 stories)
- Not completed: US-089 (4 points) — lý do: external API issue
- Bugs found: 3 (2 fixed, 1 deferred)
- Next sprint plan: [list]

Tạo presentation outline (tiếng Nhật, slide by slide):

SLIDE 1: タイトル
スプリント8レビュー | 2024年1月26日

SLIDE 2: 今スプリントのサマリー
[Metrics dạng visual — dùng số và icon, ít text]
✅ 完了: 7ストーリー / 28ポイント
⚠️ 持越し: 1ストーリー / 4ポイント

SLIDE 3: 完了した機能のデモ
[List features đã done + demo plan]

SLIDE 4: 持越しストーリーの説明
US-089: [tên] — 4ポイント
原因: 外部API連携の問題 (External API issue)
対策: ベンダーと調整中、来週中に解決見込み (Đang làm việc với vendor, dự kiến xong tuần tới)
スプリント9での対応: 優先対応 (Ưu tiên xử lý)

SLIDE 5: 品質状況
[Bug metrics, test coverage]

SLIDE 6: 次スプリントの計画
[Stories planned + capacity]

SLIDE 7: リスクと課題
[Top 3 risks với mitigation plan]

PRESENTATION TIPS cho client Nhật:
- Không surprise bad news — nếu có vấn đề, thông báo TRƯỚC meeting
- Demo live nếu có thể, screenshot nếu không chắc stable
- Chuẩn bị Q&A answers cho câu hỏi likely"

# docs/CLAUDE.md — Documentation Team Context

## Company profile
- Tên: VAIX GROUP — IT outsource Việt Nam cho thị trường Nhật Bản
- Khách hàng: Công ty Nhật (SME đến Enterprise)
- Ngôn ngữ: Tiếng Nhật (client) + Tiếng Việt (nội bộ)
- Chuyên môn: AI/ML, Web system, Mobile, Business automation

## Document types thường tạo
- 提案書: Proposal/đề xuất → formal, thuyết phục
- 見積書: Báo giá → chi tiết, breakdown rõ ràng
- 要件定義書: Requirements definition
- 基本設計書/詳細設計書: Design documents
- 議事録: Meeting minutes → gửi trong 24h
- 進捗報告書: Progress report → monthly
- テスト仕様書/成績書: Test spec/result

## Writing standards
Tiếng Nhật:
- Kính ngữ: です/ます体 cho tất cả tài liệu gửi client
- Xưng hô: 弊社 = VAIX, 貴社 = client
- Không casual expressions

Tiếng Việt (nội bộ):
- Tone: chuyên nghiệp nhưng thân thiện
- Format ngày: DD/MM/YYYY

## Standard disclaimer (cuối tài liệu gửi client)
本資料の内容は予告なく変更される場合があります。
ご不明な点がございましたら、担当者までお問い合わせください。

## Version format
v1.0 = Draft client review | v1.x = Revision | v2.0 = Major revision
Luôn có 改訂履歴 trong tài liệu quan trọng

# Persona cho báo giá / proposal
claude "Trong session này, đóng vai Senior Sales Engineer:
- 10 năm kinh nghiệm với client Nhật
- Thuyết phục được nhưng không oversell
- Mọi claim phải có backing (số liệu, reference, case study)
- Tone: confident, professional, partner-oriented
- Biết văn hóa giao tiếp business Nhật"

# Persona cho technical spec
claude "Đóng vai Senior System Architect viết tài liệu:
- Precision là ưu tiên số 1. Ambiguity = enemy.
- Mọi requirement phải testable và measurable
- Khi thiếu thông tin → flag [TBD] rõ ràng, không assume
- Dùng bảng và diagram thay vì prose dài"

# Persona cho user manual
claude "Đóng vai Technical Writer cho non-technical users:
- Giả định người đọc KHÔNG biết IT
- Mỗi step = 1 action duy nhất
- Mọi technical term có giải thích
- Screenshot placeholder: [図X-X: tên màn hình]"

claude "Audit văn phong 3 tài liệu sau và tạo Style Guide:
Doc1: [paste] | Doc2: [paste] | Doc3: [paste]

1. INCONSISTENCIES:
   - Cách xưng hô: 'chúng tôi' vs 'VAIX' → chọn 1
   - Ngày: DD/MM/YYYY vs YYYY/MM/DD → chọn 1
   - Heading: Title Case vs Sentence case
   - Bullet: '-' vs '•' vs số thứ tự

2. STYLE GUIDE đề xuất:
   [Document conventions] → lưu vào CLAUDE.md

3. Self-review checklist trước khi gửi:
   □ Xưng hô nhất quán? □ Format ngày đúng?
   □ Heading hierarchy đúng? □ Bảng có header?
   □ Tiếng Nhật kính ngữ đúng?"

claude "Phân tích RFP/yêu cầu mới từ client Nhật:
[upload hoặc paste tài liệu]

1. PROJECT SUMMARY: Client là ai? Muốn build gì? Giải quyết vấn đề gì?
2. TECHNICAL REQUIREMENTS: Platform, tech preferences, integrations, NFRs?
3. BUSINESS REQUIREMENTS: Timeline, budget signal, success metrics?
4. GAPS — thông tin còn thiếu → list câu hỏi cần hỏi
5. ASSUMPTIONS — những gì tôi phải assume → list rõ ràng
6. RISK ASSESSMENT (internal):
   - Technical: công nghệ mới, integration phức tạp?
   - Scope: requirements mơ hồ, scope creep risk?
   - Resource: cần skill gì? VAIX có không?
7. COMPETITIVE POSITIONING: VAIX có lợi thế gì?
8. PRELIMINARY ESTIMATE: S/M/L/XL rough range"

claude "Tổng hợp 要件定義書 từ: meeting notes + emails + wireframes.
[paste các nguồn]

# システム要件定義書
文書管理番号: REQ-2024-001 | バージョン: 1.0

| 改訂履歴 | 版 | 日付 | 変更内容 | 作成者 |

## 1. システム概要
1.1 目的 | 1.2 対象範囲 (in/out scope) | 1.3 用語定義

## 2. 業務要件
現状業務フロー (As-Is) → 課題 → 新業務フロー (To-Be)

## 3. 機能要件 (cho mỗi feature)
| 要件ID | FR-001 |
| 機能名 | |
| 概要 | |
| 入力/処理/出力 | |
| 例外処理 | |
| 優先度 | 必須/重要/希望 |

## 4. 非機能要件
性能 | セキュリティ | 可用性 | 保守性 | 移行要件

## 5. 制約条件 & 前提条件

## 6. 未決事項 (Open Items)
| No | 内容 | 確認先 | 期限 | ステータス |

CRITICAL: Đánh dấu [TBD] cho items chưa confirmed.
KHÔNG assume — flag explicit."

claude "Viết Use Case document cho hệ thống [tên].
Actors: Customer / Staff / Manager / System

Format mỗi use case:
---
UC-001: 注文登録 (Đặt hàng mới)

| 要件 | 内容 |
| アクター | Customer |
| 概要 | 商品を選択して注文を確定する |
| 事前条件 | ログイン済み |
| 事後条件 | 注文登録＋確認メール送信 |

基本フロー:
1. カートでCheckoutをクリック
2. 注文確認画面を表示
3. 配送先・支払いを確認
4. Order Confirmをクリック
5. システムが在庫確認
6. 注文登録＋注文番号発行
7. 確認メール送信

代替フロー A1: Step5で在庫不足
  → 在庫不足通知 → 注文内容変更 or キャンセル

例外フロー E1: 決済エラー
  → エラー表示 → 注文保存せず → 再試行を促す
---
Tạo tất cả UCs. Group theo Actor và Feature area."

# .claude/templates/gijiroku.md
# Usage: /fill-minutes [meeting notes]

# 議事録 {{MEETING_TITLE}}

| 項目 | 内容 |
| 日時 | {{DATE}} {{START}}-{{END}} |
| 場所/方法 | {{LOCATION_OR_ZOOM}} |
| 出席者 | {{CLIENT_ATTENDEES}} (貴社) / {{VAIX_ATTENDEES}} (弊社) |
| 作成者 | {{AUTHOR}} (VAIX GROUP) |

## 1. 協議内容・決定事項

### {{TOPIC_1}}
協議内容: {{DISCUSSION}}
決定事項 ✅: {{DECISIONS}}
未決事項 ⚠️: {{OPEN_ITEMS}} → 確認先: {{WHO}} / 期限: {{DATE}}

## 2. アクションアイテム
| No | 内容 | 担当 | 所属 | 期限 |

## 3. 次回予定
日時: {{NEXT_MEETING}} | 議題（案）: {{NEXT_AGENDA}}

---
本議事録に誤りがある場合は{{DEADLINE}}までにご連絡ください。
ご連絡なき場合は内容にご同意いただいたものとします。
VAIX GROUP / {{AUTHOR}} / {{EMAIL}}

claude "Điền template 議事録 từ notes thô:

TEMPLATE: [paste template trên]

NOTES (tiếng Việt lộn xộn):
Meeting với Tanaka-san và Yamamoto-san của Softbank.
Bên VAIX: Hùng, Minh và tôi. Zoom từ 14:00-15:30.
Sprint 7 kết quả: 7/8 stories xong. US-089 delay vì Stripe API.
Tanaka-san OK nhưng muốn daily update Slack.
Sprint 8: thêm US-093 (export CSV), cần estimate lại, sẽ confirm ngày mai.
Demo sprint 8: 2/2.

Actions:
- Hùng: Slack daily 17h từ hôm nay
- Mình: estimate US-093 trước ngày mai 12h
- Yamamoto: confirm staging trước 31/1

Output: 議事録 tiếng Nhật hoàn chỉnh, sẵn sàng gửi client."

# Verify Claude đang đọc files nào
claude "List tất cả CLAUDE.md files đang active.
Summarize key rules từ mỗi file theo priority."

# Import syntax — tái sử dụng context
# Trong CLAUDE.md:
@shared/company-standards.md
@.claude/security-rules.md
@../shared-libs/CLAUDE.md

claude "Session hôm nay: implement 5 features.
Dùng TodoWrite để track:
- [ ] US-087: Excel export
- [ ] US-088: Email notification
- [ ] US-089: Bulk delete
Update [x] sau mỗi feature xong.
Khi tôi hỏi 'status?' → TodoRead và report."

# Trước /compact — save state
claude "Tóm tắt trước khi compact:
1. Đã xong gì (với file paths)
2. Đang ở đâu
3. Còn lại gì
4. Key decisions đã đưa ra
Lưu vào .claude/session-state.md rồi /compact"

# .claude/commands/deploy.md
Deploy: $ARGUMENTS

1. Xác định môi trường:
   - 'staging' → skip approval, tiếp tục
   - 'production' → hỏi confirm từ tôi trước
   - Khác → báo lỗi, dừng

2. Pre-deploy checks:
   npm run typecheck || abort
   npm run lint || abort
   npm test || abort
   git status → uncommitted changes warning

3. Build + deploy theo môi trường

4. Post-deploy: health check 60s, smoke test

5. Report: git tag nếu production, update CHANGELOG

# .claude/commands/onboard-feature.md
Tạo feature tour cho developer mới: $ARGUMENTS

1. Grep tất cả files liên quan đến $ARGUMENTS
2. Map dependency graph: file → imports → imports
3. Tìm entry points: route/controller nào expose feature?
4. Đọc test files → extract behaviors từ test descriptions
5. Tìm CHANGELOG entries liên quan
6. Tìm TODO/FIXME trong feature files

Output: docs/feature-tours/$ARGUMENTS.md
## Files (sorted by importance)
## Data flow
## Key business rules (từ tests)
## Known issues / tech debt
## How to test manually

# .claude/commands/standup.md
Generate standup report.

1. git log --since="yesterday 18:00" --oneline --author="$(git config user.name)"
2. TodoRead — current task list
3. Tổng hợp:

**STANDUP — [hôm nay]**
✅ DONE: [từ git log — nhóm theo feature]
🔄 IN PROGRESS: [từ todo — đang làm]
⏭️ NEXT: [từ todo — chưa bắt đầu]
⚠️ BLOCKERS: [task nào stale > 2 ngày?]

# Gọi mỗi sáng: /standup → copy paste Slack trong 30 giây

.claude/commands/
├── dev/feature.md     # /dev:feature
├── dev/fix.md         # /dev:fix
├── qa/testcase.md     # /qa:testcase
├── qa/bugreport.md    # /qa:bugreport
├── ba/analyze.md      # /ba:analyze
├── docs/proposal.md   # /docs:proposal
├── docs/minutes.md    # /docs:minutes
└── ops/deploy.md      # /ops:deploy

claude --dangerously-skip-permissions "
MISSION: Migrate toàn project từ CommonJS sang ESM.
STRATEGY:
1. Inventory: tìm tất cả require() trong .js files
2. Start từ leaf modules (không có dependencies)
3. Convert từng file: require→import, module.exports→export
4. Sau mỗi 10 files: npm run typecheck → nếu fail, fix trước
5. Commit sau mỗi module group hoàn chỉnh
DONE CRITERIA: typecheck && npm test đều pass
LOG: progress vào .claude/migration-log.md"

claude "Implement notification system. Spawn 3 sub-agents parallel:

SUB-AGENT 1 — Backend:
  src/services/notification.ts + src/routes/notification.ts
  Output: Working API + unit tests

SUB-AGENT 2 — Queue Worker:
  src/workers/notification.worker.ts
  Channels: email (SendGrid), push (Firebase), in-app
  Output: Worker + retry logic

SUB-AGENT 3 — Frontend:
  src/client/components/Notifications/
  Output: React components + Storybook

ORCHESTRATOR:
  - Monitor qua TodoRead
  - Integration test sau khi tất cả xong
  - Resolve shared interface conflicts
  - Final: npm run build && npm test phải pass"

claude --print "
Phase 1: git diff main...HEAD > /tmp/pr-diff.txt
          npm run typecheck > /tmp/ts-errors.txt
          npm run lint > /tmp/lint-errors.txt

Phase 2: Identify affected test files → run only those

Phase 3: Review diff với: security, logic, performance, conventions

Phase 4: Output pr-review.md:
  - Summary of changes
  - Blocking issues vs suggestions
  - Approval: APPROVE / REQUEST CHANGES / NEEDS DISCUSSION
" | tee pr-review.md

claude --print --dangerously-skip-permissions "
HEALTH CHECK daily:
1. npm run typecheck → fix errors, commit
2. npm run lint → auto-fix, commit
3. npm audit → patch CRITICAL deps, test
4. Dead code (ts-prune) → remove + test
Commit: 'chore: automated health check [date]'
Summary → health-report.txt"

// ~/.claude/settings.json
{
  "mcpServers": {
    "github": {
      "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "ghp_YOUR_TOKEN" }
    },
    "postgres": {
      "command": "npx", "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": { "DATABASE_URL": "postgresql://readonly:pwd@localhost/db" }
    },
    "slack": {
      "command": "npx", "args": ["-y", "@modelcontextprotocol/server-slack"],
      "env": { "SLACK_BOT_TOKEN": "xoxb-..." }
    }
  }
}

claude "GitHub workflow tự động:
1. Đọc issue #234 đầy đủ
2. Implement feature theo requirements
3. Tạo PR: title 'feat(#234): ...' + description + Closes #234
4. Label: 'ready-for-review', assign reviewers
5. Notify Slack #dev-team"

claude "User id=12345 báo không thấy orders tháng trước.
Investigate với Postgres MCP (read-only):
1. Check user exists + account status
2. Query orders trong khoảng thời gian
3. Check audit_logs xem có delete không
4. Check soft-deleted orders (deleted_at IS NOT NULL)
Root cause + data recovery script nếu cần"

claude "Tạo custom MCP server kết nối Redmine nội bộ VAIX.

Tools cần expose:
1. list_issues(project_id, status?, priority?) → issues[]
2. get_issue(id) → full detail
3. create_issue(project, subject, description, priority, assignee)
4. update_issue(id, status?, note?)

Tech: TypeScript + @modelcontextprotocol/sdk
Output: src/ + README + Dockerfile
Test: npx @modelcontextprotocol/inspector node dist/index.js"

// .claude/settings.json — hooks config
{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write",
      "hooks": [{ "type": "command", "command": "bash .claude/hooks/post-write.sh" }]
    }],
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{ "type": "command", "command": "bash .claude/hooks/pre-bash.sh" }]
    }],
    "Stop": [{ "hooks": [{ "type": "command", "command": "bash .claude/hooks/session-end.sh" }] }]
  }
}

#!/bin/bash
# .claude/hooks/post-write.sh
WRITTEN_FILE="$CLAUDE_TOOL_INPUT_PATH"
if [[ "$WRITTEN_FILE" == *.ts || "$WRITTEN_FILE" == *.tsx ]]; then
  npx eslint "$WRITTEN_FILE" --fix --quiet 2>&1
  [ $? -ne 0 ] && echo "LINT_ERROR: $WRITTEN_FILE" >> .claude/lint-issues.log
fi

#!/bin/bash
# .claude/hooks/pre-bash.sh
CMD="$CLAUDE_TOOL_INPUT_COMMAND"
BLOCKED=("rm -rf" "DROP TABLE" "DROP DATABASE" "git push --force" "chmod 777")
for p in "${BLOCKED[@]}"; do
  if echo "$CMD" | grep -qi "$p"; then
    echo "BLOCKED: '$p' in command. Confirm manually."
    exit 1  # exit 1 = Claude bị block
  fi
done
exit 0  # exit 0 = allow

#!/bin/bash
# .claude/hooks/session-end.sh
FILES_CHANGED=$(git diff --name-only HEAD 2>/dev/null | wc -l)
cat >> .claude/session-history.md << EOF

## $(date +"%Y-%m-%d %H:%M")
Files changed: $FILES_CHANGED
$(git diff --name-only HEAD 2>/dev/null)
---
EOF