Rules — guidelines luôn được áp dụng

English title: Rules — Guidelines Always Applied

Bài 6 trong chuỗi 20 bài về Claude Code. Command và skill chạy khi bạn gọi hoặc khi trigger khớp. Rules khác: chúng luôn được inject vào context — không cần nhắc "nhớ dùng TypeScript strict" hay "đừng commit secret" mỗi lần. Bài này làm rõ rule là gì, khác skill/command thế nào, và cách tổ chức common vs theo ngôn ngữ.

Mở đầu: "Luôn follow những quy tắc này"

Bạn làm việc với Claude mỗi ngày. Nếu không có rule, mỗi session bạn phải nhắc: "Dùng TypeScript strict", "Commit message theo format scope + mô tả", "Không để API key trong code". Chỉ cần quên nhắc một lần là có thể sinh ra code không strict hoặc commit nhầm file chứa secret. Rules là cách bạn đưa những quy ước đó vào hệ thống: mỗi khi Claude Code load context, nó đọc các file rules và inject vào system prompt (hoặc tương đương). Agent "luôn thấy" các guideline đó — không cần user nhắc mỗi lần.

1. Đi sâu: Rule là gì và khác skill/command thế nào

Tại sao quan trọng: Rule = always-on guideline. Skill = procedure khi trigger (vd. khi user nói "fix bug"). Command = khi user gõ slash. Ba thứ bổ sung nhau: rule đảm bảo nền tảng (style, security); skill đảm bảo quy trình (các bước); command đảm bảo cách gọi nhanh.

Hiểu sai thường gặp: "Rule = skill dài" hoặc "rule = command". Rule không cần user kích hoạt — nó luôn có trong context. Nếu bạn đặt "luôn viết test trước" trong rule, mọi reply của Claude (trong phạm vi đó) đều bị ràng buộc; nếu bạn đặt trong skill "TDD", chỉ khi skill được load (trigger hoặc command) thì mới áp dụng.

Bản chất đúng: Rule = nội dung text (markdown hoặc tương đương) được đọc từ thư mục rules và inject vào mỗi request (hoặc mỗi session). Nội dung nên ngắn gọn, actionable — coding style, naming, git convention, security (không hardcode secret, không commit .env). Rule quá dài tốn token và có thể làm model "phân tán"; ưu tiên rule súc tích, dễ làm theo.

2. Khái niệm

• Rule: Guideline luôn được áp dụng; không cần trigger hay user invoke. Thường là file trong thư mục rules/ (user-level hoặc project-level). Nội dung: bullet hoặc đoạn ngắn, rõ ràng.
• Common rules: Quy ước chung mọi project, mọi ngôn ngữ — ví dụ: format commit message, không xóa recursive không kiểm tra (safe delete), không đưa secret vào prompt. Đặt trong rules/common/ hoặc file prefix common.
• Language-specific rules: Quy ước theo ngôn ngữ — TypeScript: strict mode, prefer const; Python: type hints, venv; Go: naming, error handling. Đặt trong rules/typescript/, rules/python/, v.v. Chỉ load ngôn ngữ bạn dùng để tránh thừa.
• Load order: Thường common load trước, sau đó theo ngôn ngữ (hoặc theo thứ tự alphabet). Nếu rule conflict (hiếm), thứ tự load quyết định rule nào "thắng"; tốt nhất là tránh conflict bằng cách tách rõ common vs từng ngôn ngữ.

3. Code / ví dụ nội dung rule (ý tưởng)

Bạn không paste full file từ repo; chỉ cần hình dung nội dung rule ngắn gọn:

<!-- Ví dụ common rule - pseudo -->
- Commit message: [scope] mô tả ngắn (vd. [auth] add login API).
- Never commit .env, .key, or files containing API keys.
- Prefer safe delete (move to trash) over recursive delete when unsure.

<!-- Ví dụ rule theo ngôn ngữ TypeScript - pseudo -->
- Use TypeScript strict mode; no implicit any.
- Prefer const over let; use readonly when possible.
- Run lint and typecheck before committing.

Rule nên đủ ngắn để không chiếm quá nhiều token; nếu cần chi tiết, có thể link tới doc hoặc để skill "coding standards" khi cần tra cứu sâu.

4. Workflow: Tổ chức và cài đặt

1. Chọn scope: Global (áp dụng mọi project) = rules trong thư mục user config; project = rules trong .claude/rules (hoặc tương đương) của repo. Project override thường ưu tiên hơn global cho các rule đặc thù repo.
2. Tách common vs ngôn ngữ: Tạo thư mục (hoặc file) common: format, git, security, safe delete. Tạo thư mục theo ngôn ngữ: typescript, python, go… Chỉ copy vào những ngôn ngữ bạn thực sự dùng.
3. Viết ngắn gọn: Mỗi rule vài dòng đến một đoạn; tránh essay. Review định kỳ: bỏ rule không còn dùng, gộp rule trùng ý.
4. Tránh conflict: Nếu hai rule mâu thuẫn (vd. "always use semicolon" vs "no semicolon"), chỉ giữ một; hoặc đặt một ở common một ở ngôn ngữ và quy ước rõ thứ tự load.

Khi nhiều rule khiến context nặng, có thể giảm số rule active (chỉ common + 1 ngôn ngữ) hoặc rút gọn nội dung từng file.

5. Ứng dụng trong AI-centric engineering

• Consistency: Mọi session đều dùng cùng coding style, commit format, security baseline → code review dễ hơn, ít "sửa lại cho đúng convention".
• Onboarding: Member mới clone config (bao gồm rules) là có cùng guideline; không cần đọc doc dài để biết "team mình quy ước gì".
• Security: Rule "không commit secret, không đưa API key vào prompt" giảm rủi ro lộ key; kết hợp với hook (bài 7) có thể chặn lệnh nguy hiểm hoặc cảnh báo khi phát hiện pattern secret.

Bài 7 sẽ nói hooks — tự động hóa theo sự kiện tool (PreToolUse, PostToolUse): mỗi lần sửa file hoặc chạy lệnh, hook có thể chạy trước/sau để validate, format, hoặc log.

Bài tiếp: Hooks — tự động hóa theo sự kiện tool (bài 7).