Domain 3: Claude Code Configuration & Workflows — Ôn thi CCA-F

#Task 3.1: Cấu hình CLAUDE.md đúng hierarchy, scope và tổ chức module

#Knowledge of (Kiến thức về)

• Phân cấp (Hierarchy): Phân cấp cấu hình CLAUDE.md: user-level (~/.claude/CLAUDE.md), project-level (.claude/CLAUDE.md hoặc CLAUDE.md ở root), và directory-level (CLAUDE.md trong thư mục con).
• Scope cá nhân: Cấu hình user-level chỉ áp cho user đó — chỉ dẫn trong ~/.claude/CLAUDE.md không được chia sẻ cho teammate qua Git.
• Cú pháp @import: Dùng @import để tham chiếu file ngoài, giữ CLAUDE.md module hoá (VD: import file chuẩn riêng cho từng package).
• Quy chuẩn theo chủ đề: Thư mục .claude/rules/ để tổ chức file rule theo chủ đề, thay cho một CLAUDE.md khổng lồ.

#Skills in (Kỹ năng về)

• Chẩn đoán lỗi phân cấp: Chẩn đoán lỗi hierarchy (VD: thành viên mới không nhận được chỉ dẫn vì nó nằm ở user-level thay vì project-level).
• Sử dụng @import: Dùng @import chọn lọc file chuẩn phù hợp vào CLAUDE.md của từng package.
• Tổ chức rule dự án: Tách CLAUDE.md lớn thành các file chủ đề trong .claude/rules/ (VD: testing.md, api-conventions.md, deployment.md).
• Lệnh /memory: Dùng lệnh /memory kiểm tra memory file nào đang được load, chẩn đoán hành vi bất nhất giữa các session.

#🧠 Phân tích & Thực tế từ Delivery Manager:

Từ góc nhìn quản lý, việc để dev tự viết các convention cá nhân vào ~/.claude/CLAUDE.md mà không đồng bộ là một thảm họa kiểm soát chất lượng. Tôi luôn yêu cầu tất cả các rule viết code, cách chạy test, và lệnh build phải được đưa vào project-level CLAUDE.md và commit lên Git. Dùng lệnh /memory là cách nhanh nhất để kiểm tra xem một quy định mới đã thực sự được nạp vào bộ nhớ của Claude Code chưa khi dev báo cáo agent làm việc không như ý.

#Task 3.2: Tạo và cấu hình custom slash command và skill

#Knowledge of (Kiến thức về)

• Command scope: Command project-scope trong .claude/commands/ (chia sẻ qua Git) vs user-scope trong ~/.claude/commands/ (cá nhân).
• Skill cấu hình: Skill trong .claude/skills/ với file SKILL.md hỗ trợ frontmatter: context: fork, allowed-tools, argument-hint.
• Bảo vệ context (context: fork): Chạy skill trong context sub-agent cô lập, tránh output của skill làm bẩn/phình hội thoại chính.
• Skill cá nhân: Tạo bản riêng trong ~/.claude/skills/ với tên khác để không ảnh hưởng teammate.

#Skills in (Kỹ năng về)

• Slash command dùng chung: Tạo slash command project-scope trong .claude/commands/ để cả team dùng qua Git.
• Cô lập tác vụ nặng: Dùng context: fork cô lập skill có output dài dòng (VD: phân tích codebase) hoặc context khám phá (VD: brainstorm phương án) khỏi session chính.
• Giới hạn quyền hạn: Cấu hình allowed-tools trong frontmatter giới hạn tool khi skill chạy (VD: chỉ cho thao tác ghi file, chặn hành động phá hoại hệ thống).
• Nhắc nhở đối số: Dùng argument-hint nhắc developer nhập tham số bắt buộc khi gọi skill không kèm argument.
• Đánh giá thiết kế: Chọn giữa skill (gọi theo nhu cầu, cho workflow theo task) và CLAUDE.md (luôn được load, cho chuẩn phổ quát).

# Ví dụ cấu hình Skill — .claude/skills/analyze-module/SKILL.md
---
context: fork                         # Chạy cô lập tránh làm bẩn context chính
allowed-tools: ["Read", "Grep", "Glob"] # Chỉ cho phép đọc, cấm chỉnh sửa code
argument-hint: "<tên_module_cần_phân_tích>"
---
Phân tích cấu trúc thư mục và dependencies của module được chỉ định.

#🧠 Phân tích & Thực tế từ Delivery Manager:

Tôi khuyến khích việc sử dụng context: fork khi viết các skill phân tích log hoặc check nợ kỹ thuật. Khi chạy một lệnh như kiểm tra lỗ hổng bảo mật trên toàn bộ codebase, kết quả trả về hàng ngàn dòng text. Nếu không dùng context: fork, toàn bộ nội dung thô này sẽ chui vào context window của session chính, làm Claude bị mất trí nhớ tạm thời (attention degradation) đối với các file code đang viết dở.

#Task 3.3: Áp dụng rule theo path để load convention có điều kiện

#Knowledge of (Kiến thức về)

• Conditional loading: File trong .claude/rules/ với YAML frontmatter chứa trường paths (glob pattern) để kích hoạt rule có điều kiện.
• Tiết kiệm token: Rule scope theo path chỉ load khi sửa file khớp pattern → giảm context thừa và token tiêu thụ.
• Glob vs Subdirectory: Ưu thế của rule glob-pattern so với CLAUDE.md theo thư mục khi convention trải rộng nhiều thư mục (VD: file test rải khắp codebase).

#Skills in (Kỹ năng về)

• Rule theo path: Tạo file .claude/rules/ với path scope trong frontmatter (VD: paths: ["terraform/**/*"]) để rule chỉ load khi sửa file khớp.
• Quy chuẩn theo loại file: Dùng glob pattern áp convention theo loại file bất kể thư mục (VD: **/*.test.tsx cho mọi file test).
• Lựa chọn cấu trúc rule phù hợp: Ưu tiên chọn rules có cấu hình path-specific trong .claude/rules/ thay vì đặt nhiều file CLAUDE.md rải rác ở các thư mục con khi các quy tắc cần được áp dụng nhất quán cho các loại file trải rộng khắp toàn bộ codebase (VD: quy ước viết unit test nằm rải rác ở hàng chục sub-folders).

# Ví dụ Rule theo Path — .claude/rules/testing.md
---
paths: ["**/*.test.tsx", "**/*.test.ts"]
---
- Luôn sử dụng thư viện React Testing Library, không dùng snapshot testing.
- Mock API bằng msw, không mock trực tiếp global fetch.

#🧠 Phân tích & Thực tế từ Delivery Manager:

Việc duy trì hàng chục file CLAUDE.md trong từng thư mục con là một cơn ác mộng bảo trì đối với một tech lead. Nếu dự án có sự thay đổi về thư viện test, việc đi cập nhật từng file CLAUDE.md rất dễ gây sót. Tôi luôn yêu cầu dev quy về một mối: dùng file rule tập trung trong .claude/rules/ kèm glob path. Sạch sẽ, nhất quán và tiết kiệm token tối đa.

#Task 3.4: Quyết định khi nào dùng plan mode vs thực thi trực tiếp

#Knowledge of (Kiến thức về)

• Plan mode: Dành cho task phức tạp: thay đổi quy mô lớn, nhiều hướng giải hợp lệ, quyết định kiến trúc, sửa nhiều file.
• Direct execution (Thực thi trực tiếp): Phù hợp thay đổi đơn giản, scope rõ (VD: thêm 1 validation check vào 1 hàm).
• An toàn kiến trúc: Plan mode cho phép khám phá codebase và thiết kế an toàn trước khi thực sự ghi đè code → tránh rework tốn kém.
• Explore subagent: Cô lập output khám phá dài dòng, trả về summary để bảo toàn context hội thoại chính.

#Skills in (Kỹ năng về)

• Đánh giá mức độ tác động: Chọn plan mode cho task có tính kiến trúc (VD: tái cấu trúc microservice, di chuyển thư viện ảnh hưởng 45+ file).
• Quy trình kết hợp: Kết hợp plan mode để điều tra + thực thi trực tiếp để triển khai (lên kế hoạch trước, làm sau).
• Chọn thực thi trực tiếp đúng lúc: Chủ động lựa chọn chế độ thực thi trực tiếp cho các thay đổi đã hiểu rõ yêu cầu và có phạm vi nhỏ gọn (VD: sửa bug trong một file đơn lẻ dựa trên stack trace rõ ràng, hoặc thêm một điều kiện validate ngày tháng đơn giản).
• Sử dụng Explore subagent tối ưu: Kích hoạt subagent chuyên trách khảo sát (Explore subagent) trong các pha nghiên cứu sâu và dài hơi để tránh làm cạn kiệt (exhaustion) context window của coordinator chính.

#🧠 Phân tích & Thực tế từ Delivery Manager:

Một lỗi kinh điển của lập trình viên là quá lạm dụng Plan mode cho mọi tác vụ nhỏ, gây lãng phí thời gian và tăng chi phí API không cần thiết. Là DM, tôi yêu cầu dev phân loại rõ: bug nhỏ có stack trace rõ ràng -> sửa trực tiếp ngay; di chuyển module hoặc thay đổi kiến trúc DB -> bắt buộc phải Plan mode.

#Task 3.5: Áp dụng kỹ thuật tinh chỉnh lặp (iterative refinement)

#Knowledge of (Kiến thức về)

• Ví dụ trực quan: Ví dụ input/output cụ thể là cách hiệu quả nhất truyền đạt phép biến đổi kỳ vọng khi mô tả bằng văn xuôi bị hiểu bất nhất.
• Test-driven iteration: Viết bộ test trước, rồi lặp bằng cách chia sẻ test failure để dẫn hướng cải thiện code của Claude.
• Interview pattern: Để Claude đặt câu hỏi nhằm lộ ra các cân nhắc thiết kế mà dev chưa lường trước, trước khi triển khai.
• Gom lỗi tương tác vs Sửa lỗi tuần tự: Kỹ thuật gom tất cả các lỗi có tính tương tác chéo (interacting problems) vào một message duy nhất để mô hình xử lý tổng thể, trái ngược với việc sửa tuần tự (sequential) từng lỗi nhỏ đối với các vấn đề hoàn toàn độc lập (independent problems).

#Skills in (Kỹ năng về)

• Cung cấp ví dụ mẫu: Cung cấp 2-3 ví dụ input/output cụ thể để làm rõ yêu cầu biến đổi dữ liệu.
• Chất vấn kiến trúc: Sử dụng interview pattern để làm rõ các chiến lược cache invalidation, failure mode trước khi triển khai trong hệ thống lạ.
• Thực hiện test-driven loop: Viết bộ test suite bao quát các hành vi kỳ vọng, edge cases và hiệu năng trước khi bắt đầu code; sau đó tiến hành lặp lại (iterate) bằng cách nạp trực tiếp kết quả chạy test thất bại (test failure logs) cho Claude sửa code.
• Cung cấp test case cho edge cases cụ thể: Cung cấp các test case cụ thể với đầu vào mẫu và đầu ra mong muốn để xử lý các edge cases phức tạp (VD: xử lý giá trị null trong scripts di chuyển cơ sở dữ liệu).
• Điều phối sửa lỗi theo tính chất liên đới: Đưa nhiều lỗi có tính chất liên đới (interacting issues) vào cùng một chỉ dẫn chi tiết để Claude có cái nhìn toàn cục; chỉ tách ra sửa tuần tự khi các lỗi đó độc lập hoàn toàn để tránh làm rối suy luận của mô hình.

[INTERVIEW PATTERN]
"Trước khi bắt tay vào triển khai lớp Cache Layer này, 
hãy đặt cho tôi 3 câu hỏi cốt lõi về cơ chế invalidation, 
TTL, và failure mode mà tôi có thể chưa nghĩ tới."

#🧠 Phân tích & Thực tế từ Delivery Manager:

Trong quy trình CI/CD, tôi luôn khuyến khích dev thực hiện viết test trước (TDD) khi làm việc với AI. AI rất giỏi trong việc sửa lỗi dựa trên log biên dịch hoặc log test cụ thể. Thay vì mô tả bằng lời: "hàm này chạy sai logic rồi", hãy ném trực tiếp test failure log cho nó. Kết quả sửa lỗi sẽ nhanh và chính xác hơn gấp nhiều lần.

#Task 3.6: Tích hợp Claude Code vào pipeline CI/CD

#Knowledge of (Kiến thức về)

• Chạy headless: Flag -p (hoặc --print) để chạy Claude Code chế độ non-interactive trong pipeline tự động.
• Structured output: Flag CLI --output-format json và --json-schema để ép cấu trúc JSON mong muốn trong CI.
• Bảo vệ ngữ cảnh: CLAUDE.md là cơ chế cung cấp context dự án (chuẩn test, quy ước fixture) cho Claude Code chạy trong CI.
• Cô lập vai trò: Cùng một session Claude vừa sinh code sẽ review chính code đó kém hiệu quả hơn một instance review độc lập.

#Skills in (Kỹ năng về)

• Chạy CI không treo: Chạy Claude Code trong CI với flag -p để tránh treo chờ input tương tác.
• Gửi PR comments tự động: Dùng --output-format json tạo structured findings máy đọc được, tự động parse rồi post làm inline PR comment.
• Ngăn chặn trùng lặp: Đưa kết quả review trước đó vào context khi review lại; chỉ dẫn Claude chỉ báo issue mới hoặc chưa xử lý để tránh spam trùng.
• Tránh sinh test trùng lặp (de-duplication): Cung cấp các file test hiện có vào ngữ cảnh (context) trước khi yêu cầu Claude sinh test mới để tránh việc mô hình đề xuất các kịch bản kiểm thử đã được bao phủ (duplicate scenarios).
• Tối ưu hóa tài nguyên kiểm thử qua CLAUDE.md: Ghi nhận đầy đủ tiêu chuẩn kiểm thử, tiêu chí test chất lượng cao và các mock fixtures sẵn có trực tiếp vào file CLAUDE.md để nâng cao độ chính xác của mã test sinh ra, giảm thiểu các kết quả test rác hoặc có giá trị thấp.

# Chạy Claude Code trong CI để xuất kết quả JSON sạch
claude -p "Review diff của PR này theo tiêu chuẩn ghi trong CLAUDE.md" \
  --output-format json \
  --json-schema review-schema.json

#🧠 Phân tích & Thực tế từ Delivery Manager:

Việc tích hợp Claude Code vào pipeline tự động cần phải được tính toán kỹ về mặt chi phí. Nếu không cung cấp sẵn các file test cũ và ghi rõ tiêu chuẩn test trong CLAUDE.md, AI sẽ sinh ra hàng loạt test trùng lặp hoặc viết sai style mock API của dự án. Điều này vừa làm phình thời gian chạy CI, vừa tốn token vô ích.

Quay lại Trang Hub ôn thi CCA-F.