Vì sao coding agent bỏ qua chỉ dẫn của bạn?

Vì sao coding agent bỏ qua chỉ dẫn của bạn

Coding agent bỏ qua chỉ dẫn của bạn vì 4 lý do, và không lý do nào là vì bạn quá lịch sự. Quy tắc chưa từng được đưa vào context window. Quy tắc quá mơ hồ nên không thể đối chiếu với một hành động. Có nội dung khác trong context mâu thuẫn với quy tắc đó, thường là chính đoạn code mà agent vừa đọc. Hoặc quy tắc vẫn được nạp nhưng nằm quá xa phía trước so với turn hiện tại, nên agent chỉ dựa vào những gì đang ở gần.

Mỗi nguyên nhân có cách khắc phục riêng, vì vậy việc đầu tiên là phân biệt chúng. Viết hoa và dùng từ IMPORTANT không giúp chẩn đoán vấn đề. Phần dưới đây dùng Claude Code làm ví dụ minh họa, vì hành vi loading và compaction của công cụ này được tài liệu hóa chi tiết tính đến tháng 8 năm 2026. Các công cụ khác có thể khác ở chi tiết, nhưng nhìn chung hoạt động theo cùng một cách.

Trước hết, cần hiểu 2 thuật ngữ. Context window là khối văn bản model nhìn thấy trong một turn: system prompt, các file chỉ dẫn của bạn, cuộc hội thoại và mọi file agent đã đọc. Harness là chương trình bao quanh model, có nhiệm vụ đọc file từ disk và tập hợp khối văn bản đó. Gần như mọi phàn nàn trong bài viết này thực chất là phàn nàn về harness, không phải model.

Tệp instruction của bạn là một message, không phải một setting

Tệp instruction không phải là configuration. Không có thành phần nào trong runtime đọc CLAUDE.md rồi thực thi nó. Harness đọc tệp từ disk và chèn phần text đó vào conversation. Trong Claude Code, nội dung này được gửi dưới dạng user message, nằm sau system prompt. Vì vậy, model nhìn thấy các rule của bạn giống như mọi nội dung khác mà bạn nhập vào.

Điều này dẫn đến một hệ quả khó chịu. Các rule của bạn phải cạnh tranh với mọi đoạn text khác trong cửa sổ, trên cùng một mức độ ưu tiên. Một rule chỉ là một nhận định. Tệp mà agent vừa mở là bằng chứng. Khi hai thứ mâu thuẫn, bằng chứng thường thắng. Không có lỗi nào được báo, vì theo góc nhìn của model thì không có gì sai xảy ra.

Tài liệu chính thức nói rõ điều này: các tệp instruction được xử lý như context, không phải configuration được thực thi. Muốn chặn một hành động bất kể model quyết định thế nào, bạn cần một hook, không phải một câu lệnh. Hãy ghi nhớ điểm này. Phần lớn các cách khắc phục ở cuối bài đều áp dụng nguyên tắc đó cho một trường hợp cụ thể.

Các file instruction nào được load và khi nào

Claude Code đi ngược lên cây thư mục, bắt đầu từ thư mục nơi bạn chạy nó. Mọi CLAUDE.md và CLAUDE.local.md từ thư mục gốc của filesystem đến thư mục làm việc của bạn đều được load đầy đủ khi khởi động. Chúng được nối theo thứ tự đó, nên file gần vị trí bạn chạy lệnh nhất được đọc sau cùng. Trong cùng một thư mục, file .local được thêm sau file chính.

Các file trong những thư mục con bên dưới thư mục làm việc của bạn hoạt động khác. Chúng không được load khi khởi động. Chúng được load khi agent đọc một file trong thư mục đó. Điều tương tự cũng áp dụng cho các rule giới hạn theo path trong .claude/rules/ có trường frontmatter paths:: chúng được đưa vào context khi một file khớp được đọc, không phải ở mỗi turn.

Chỉ riêng khác biệt này đã giải thích phần lớn các lỗi được báo cáo. Bạn đặt một rule trong packages/api/CLAUDE.md, hỏi một câu về API, và agent trả lời mà chưa từng mở file nào bên dưới packages/api/. Rule không bị bỏ qua. Nó chưa từng có trong context. Nếu repository của bạn phân tách hướng dẫn qua các file instruction cho từng package trong monorepo, đây là điều đầu tiên cần kiểm tra, lần nào cũng vậy.

Còn một bẫy khi load khác, và đây là nguyên nhân phổ biến nhất của câu “agent đã bỏ qua instruction của tôi”: Claude Code đọc CLAUDE.md, không đọc AGENTS.md. Một repository đã chuẩn hóa theo AGENTS.md nhưng không có CLAUDE.md sẽ không cung cấp gì để Claude Code load. Cách nối được hỗ trợ là tạo CLAUDE.md với dòng đầu tiên là @AGENTS.md. Dòng này import file khi khởi động; bạn có thể đặt thêm các ghi chú riêng cho Claude bên dưới. Symlink cũng hoạt động nếu bạn không cần thêm nội dung nào. Việc quyết định ngay từ đầu nội dung nào thuộc file đó là một vấn đề riêng, được đề cập trong tách instruction cho agent khỏi tài liệu dành cho con người.

Xác nhận file đã được tải trước khi viết lại

Không chỉnh nội dung cho đến khi bạn có bằng chứng agent nhìn thấy file. Có 2 bước kiểm tra, và hãy bắt đầu bằng bước đơn giản hơn.

Chạy /context trong session. Lệnh này in ra cửa sổ hiện tại theo từng nhóm, trong đó danh sách Memory files liệt kê mọi file hướng dẫn đã thực sự được tải. Nếu file không có trong danh sách này thì file đó không nằm trong conversation, vì vậy mọi nội dung bạn viết bên trong đều không có tác dụng. /memory liệt kê vị trí các file và mở chúng để chỉnh sửa, bao gồm cả những file chưa tồn tại.

Để có kết quả chắc chắn hơn, hãy ghi lại các lần tải file. Event hook InstructionsLoaded chạy mỗi khi một CLAUDE.md hoặc file rules được đưa vào context. Matcher của hook cho biết lý do file được tải: session_start, nested_traversal, path_glob_match, include hoặc compact. Đặt nội dung sau vào .claude/settings.json:

{
  "hooks": {
    "InstructionsLoaded": [
      {
        "matcher": "nested_traversal",
        "hooks": [
          {
            "type": "command",
            "command": "cat >> /tmp/instructions-loaded.log"
          }
        ]
      }
    ]
  }
}

Hook nhận payload dưới dạng JSON qua standard input, vì vậy cat sẽ nối toàn bộ record vào file. Theo dõi file bằng tail -f /tmp/instructions-loaded.log trong lúc làm việc. Exit status của event này bị bỏ qua, nên hook chỉ có thể quan sát và không thể chặn. Nếu file lồng nhau của bạn không bao giờ xuất hiện trong log dù session đó đáng lẽ phải tải file, hãy dừng việc viết lại nội dung. Vấn đề nằm ở vị trí đặt file.

Một phiên làm việc dài ảnh hưởng đến rules của bạn như thế nào

Có hai cơ chế riêng biệt ở đây và mỗi cơ chế cần một cách xử lý khác nhau.

Khoảng cách. Một rule được nêu ở turn 1 vẫn nằm trong context window ở turn 90, nhưng lúc này phải cạnh tranh với 90 turn văn bản mới hơn và cụ thể hơn với việc bạn đang làm. Bạn không thể loại bỏ ảnh hưởng này bằng cấu hình, nhưng có thể đo lường nó. Hãy chạy cùng một task trong một phiên mới. Nếu rule vẫn được áp dụng ở đó nhưng không còn được áp dụng khi phiên kéo dài, thì nguyên nhân là khoảng cách.

Compaction. Khi window đầy, harness sẽ tóm tắt cuộc hội thoại đến thời điểm đó rồi tiếp tục từ bản tóm tắt. Nội dung còn lại là những gì summariser đánh giá là quan trọng, không nhất thiết trùng với những gì bạn xem là quan trọng. Claude Code ghi lại kết quả theo từng cơ chế, và sự khác biệt rất lớn. Project root CLAUDE.md và các rule không có scope sẽ được nạp lại từ disk sau khi compaction. Auto memory cũng được nạp lại từ disk. Các rule có frontmatter paths: sẽ bị mất cho đến khi đọc lại một file phù hợp. Các file CLAUDE.md lồng trong subdirectory sẽ bị mất cho đến khi đọc lại một file trong subdirectory đó.

Hãy xếp hạng các instruction của bạn theo bảng đó, bạn sẽ thấy ngay thứ tự dễ mất. Rule chỉ được nhập vào chat là thứ mong manh nhất trong phiên: nó chỉ tồn tại nếu summary tình cờ giữ lại. Rule trong packages/api/CLAUDE.md đứng tiếp theo, vì nó được load một lần, bị loại khỏi summary, rồi chỉ quay lại khi thư mục đó được đọc lần tiếp theo. Rule trong file ở project root bền vững nhất, vì file này được đọc lại từ disk mỗi lần.

Vì vậy, nếu một instruction phải được áp dụng trong toàn bộ phiên, hãy đặt nó trong file ở project root và không dùng frontmatter paths:. Mọi lựa chọn khác đều là trade-off mà bạn nên chủ động cân nhắc. Quản lý nội dung còn lại trong context window trình bày /compact bằng focus argument và /clear giữa các task không liên quan, cả hai đều ảnh hưởng đến tần suất summariser quyết định rules của bạn còn được giữ lại.

Vì sao code xung quanh có sức nặng hơn rule

Đây là lỗi thường được mô tả nhất nhưng lại ít được chẩn đoán đúng nhất. File của bạn nói rằng việc truy cập database phải đi qua repository layer. Agent lại viết một handler gọi trực tiếp ORM (object relational mapper). Không phải agent phớt lờ bạn vì lý do về style. Bằng chứng đã chiếm ưu thế.

Một rule mô tả một ưu tiên. Code thể hiện một ưu tiên cụ thể. Khi agent mở 3 file trong module mà nó sắp chỉnh sửa và cả 3 file đều gọi trực tiếp ORM, context có 1 câu trừu tượng ở một bên và 3 ví dụ cụ thể, mới hơn, đúng với task ở bên kia. Sao chép pattern cục bộ thường là hành vi đúng. Trong trường hợp này, nó chỉ sai vì bạn biết một điều mà context không biết: những file đó là code legacy.

Vì vậy, hãy ghi điều đó vào rule. Những rule nêu rõ bằng chứng ngược lại của chính chúng sẽ đứng vững khi áp dụng vào repository thực tế. Những rule chỉ nêu một ưu tiên chung thì không.

Quyền truy cập database mới phải đi qua app/repositories/. Các file trong app/legacy/ vẫn gọi trực tiếp ORM. Đó là code cũ, không phải pattern cần áp dụng. Không được sao chép pattern đó.

Câu thứ hai mới là phần quan trọng. Nó cho agent biết trước điều nó sắp thấy và cách diễn giải điều đó. Cách sửa tương tự áp dụng cho mọi rule bị repository công khai mâu thuẫn: một style commit mà lịch sử của bạn không tuân theo, một cách bố trí test mà một nửa test suite bỏ qua, một quy ước import chỉ được dùng trong code mới. Ở bất cứ nơi nào code không khớp với file, hãy ghi rõ sự không khớp đó trong file.

Một quy tắc mơ hồ không thể kiểm tra thì cũng không thể tuân thủ

"Viết code sạch." "Đừng over-engineer." "Giữ mọi thứ đơn giản." "Cẩn thận khi migration." Không câu nào trong số này có thể được kiểm tra dựa trên một hành động cụ thể, dù bởi agent hay bởi bạn. Nếu agent nhận một quy tắc mà nó không thể dùng để kiểm tra output của chính mình, nó chỉ đang đoán, còn bạn thì đánh giá phỏng đoán đó theo cảm tính.

Hãy áp dụng bài kiểm tra này cho từng dòng trong file. Viết shell command sẽ exit non-zero khi quy tắc bị vi phạm. Nếu không viết được command đó, quy tắc không thể kiểm tra. So sánh các cặp sau:

• Không thể kiểm tra: "Giữ các function ngắn." Có thể kiểm tra: "Function dài hơn 60 dòng phải có một comment phía trên giải thích lý do."
• Không thể kiểm tra: "Test các thay đổi của bạn." Có thể kiểm tra: "Chạy npm test và dán số lượng lỗi trước khi đánh dấu task là hoàn tất."
• Không thể kiểm tra: "Giữ các file có tổ chức." Có thể kiểm tra: "HTTP handler nằm trong src/api/handlers/. Không có nội dung nào khác được đặt trong directory đó."
• Không thể kiểm tra: "Format code cho đúng." Có thể kiểm tra: "Dùng indentation 2 space trong các file .ts."

"Đừng over-engineer" là quy tắc mọi người bỏ cuộc đầu tiên, vì cách sửa không phải là viết một câu ngắn hơn mà là viết một câu dài hơn: nêu rõ thay đổi nhỏ nhất thực sự cần làm là gì sẽ cung cấp cho agent các tiêu chí để tự đối chiếu với diff của nó.

Độ dài cũng là cùng một vấn đề dưới một hình thức khác. Hướng dẫn của Claude Code đặt mục tiêu dưới 200 dòng cho mỗi instruction file và nêu rõ rằng file dài hơn làm giảm mức độ tuân thủ. Một file 700 dòng không tạo ra chỉ dẫn chắc chắn hơn. Đó là 700 dòng khẳng định với nhiều khả năng mâu thuẫn nhau hơn, đồng thời được tính vào context window của bạn trong mỗi turn, điều này thể hiện trực tiếp trong mức sử dụng token của bạn. Cách cấu trúc file để mỗi quy tắc nằm dưới một heading mà người đọc có thể nhanh chóng quét qua được trình bày trong cách viết instruction file để agent có thể thực hiện.

Cách chẩn đoán trong 10 phút

Chạy các bước này theo đúng thứ tự. Bỏ qua đến bước cuối là nguyên nhân khiến nhiều người tạo ra một file dài toàn quy tắc viết hoa nhưng vẫn không hoạt động.

1. Xác nhận rule đã được nạp. Chạy /context và đọc danh sách Memory files. Nếu không thấy file, hãy sửa vị trí rồi dừng lại. Các bước còn lại chưa áp dụng.
2. Tái hiện trong session mới. Bắt đầu một session mới và giao tác vụ nhỏ nhất có thể kích hoạt rule. Nếu rule vẫn hoạt động ở đây nhưng thất bại trong session dài, nguyên nhân có thể là khoảng cách hoặc compaction. Nếu cũng thất bại ở đây, vấn đề nằm ở chính rule.
3. Loại bỏ chỉ dẫn cạnh tranh. Yêu cầu thực hiện cùng thay đổi trong một thư mục có code hiện tại đã tuân theo rule. Nếu mức độ tuân thủ trở lại, code xung quanh đã lấn át câu chỉ dẫn của bạn.
4. Tìm xung đột. Hai file đưa ra hướng dẫn khác nhau cho cùng một hành vi là một lỗi đã được ghi nhận: model có thể chọn một cách tùy ý và sẽ không cho bạn biết điều đó.
5. Để rule có thể kiểm tra rồi kiểm tra lại. Viết lại rule với một path cụ thể và một điều kiện. Nếu mức độ tuân thủ tăng mạnh, nguyên nhân là cách diễn đạt.

Bước 4 chỉ cần một command. Grep mọi nguồn instruction cho chủ đề đó, không chỉ file bạn đang chỉnh sửa:

grep -rni "migration" --include="CLAUDE.md" --include="CLAUDE.local.md" .
grep -rni "migration" .claude/rules/ ~/.claude/CLAUDE.md ~/.claude/rules/ 2>/dev/null

Một kết quả xuất hiện trong 2 file có nội dung khác nhau chính là lỗi của bạn. Xóa một file. Đừng cố xếp hạng chúng bằng cách dùng câu chữ mạnh hơn, vì không có ranking engine nào để bạn dựa vào.

Các cách khắc phục, theo mức độ tác động

Mỗi bước dưới đây có tác động lớn hơn bước ngay phía trên và tốn nhiều công sức thiết lập hơn. Hãy bắt đầu từ trên cùng khi việc sửa lại một rule còn đơn giản. Chuyển xuống ngay khi rule đủ quan trọng để không thể chấp nhận việc thỉnh thoảng bị bỏ sót.

1. Làm cho rule cụ thể. Nêu rõ một path, một command hoặc một điều kiện. Thêm bằng chứng ngược mà agent sẽ tìm thấy trong repository, như đã trình bày trước đó. Cách này không tốn chi phí và xử lý được nhiều trường hợp hơn dự kiến.
2. Đưa rule đến gần đối tượng mà nó chi phối hơn. Dùng một CLAUDE.md lồng nhau, một rule giới hạn theo path trong .claude/rules/ hoặc một comment ở đầu chính file đó. Khi ấy, rule được đọc cùng lúc với code mà nó áp dụng. Hãy chấp nhận đánh đổi: mọi nội dung được nạp theo cách này sẽ bị loại khỏi context ở lần compaction tiếp theo và quay lại ở lần đọc phù hợp tiếp theo.
3. Đưa việc enforcement vào hook. Prose chỉ yêu cầu. Hook mới quyết định. Hook chạy dưới dạng code tại các lifecycle event cố định và áp dụng bất kể model kết luận gì.
4. Giao rule cho một tool xác định và xóa phần prose. Định dạng, thứ tự import, độ dài dòng, import bị cấm, cấu trúc commit message. ruff format, prettier --write, eslint, một hook pre-commit. Formatter luôn cho kết quả đúng và không tốn token. Câu mô tả chỉ đúng trong phần lớn trường hợp và tiêu tốn token ở mọi lượt.

Bước 3 đầy đủ. Giả sử agent tuyệt đối không được sửa các file migration. Đặt nội dung sau vào .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/guard-migrations.sh"
          }
        ]
      }
    ]
  }
}

Và đặt nội dung này vào .claude/hooks/guard-migrations.sh:

#!/usr/bin/env bash
set -euo pipefail

path=$(jq -r '.tool_input.file_path // empty')

case "$path" in
  */migrations/*)
    echo "Files under migrations/ are written by hand. Stop and ask first." >&2
    exit 2
    ;;
esac

exit 0

Chạy chmod +x .claude/hooks/guard-migrations.sh, sau đó bắt đầu session mới và yêu cầu agent sửa một file trong migrations/. Thao tác sửa sẽ bị từ chối và message của bạn sẽ được trả về làm lý do. Exit status 2 trên PreToolUse sẽ chặn tool call trước khi nó chạy, còn nội dung stderr của bạn sẽ được chuyển cho model dưới dạng message chặn thao tác. ${CLAUDE_PROJECT_DIR} trỏ đến project root, nên hook hoạt động bất kể agent đang ở directory nào. Agent không cần đồng ý với rule, nhớ rule hoặc vẫn còn rule trong context. Thao tác sửa sẽ không xảy ra.

Với một lệnh cấm đơn giản không có logic, permissions.deny trong settings của bạn cũng thực hiện được việc tương tự mà không cần script để bảo trì, và các permission mode quyết định thao tác nào được chạy mà không hỏi bạn trước. Nếu một instruction thực sự phải nằm ở system prompt level thay vì trong user message, --append-system-prompt sẽ đặt nó ở đó. Tuy nhiên, instruction này phải được truyền trong mọi invocation, nên phù hợp với script hơn là công việc tương tác.

Điều bạn không thể buộc agent làm bằng chỉ dẫn

Hãy phân biệt rõ phần nào thuộc về bạn. Vị trí đặt file, cách diễn đạt, xung đột giữa các file và kích thước file là vấn đề của tác giả, có thể khắc phục bằng các chỉnh sửa tương ứng. Phần còn lại là hành vi của model, và cách diễn đạt tốt hơn sẽ không loại bỏ được hành vi đó.

Đồng ý không có nghĩa là tuân thủ. Agent có thể xác nhận một quy tắc, nhắc lại chính xác quy tắc đó, rồi vi phạm chỉ 2 lần gọi tool sau. Việc xác nhận không tốn chi phí nào và không dự đoán được điều gì. Đừng xem đó là cách khắc phục, và đừng tính nó là một bài kiểm tra.

Một số thói quen có tính dai dẳng. Thêm comment, thêm xử lý lỗi phòng thủ, viết phần tóm tắt kết thúc, chạy command tiếp theo hiển nhiên. Những hành vi này sẽ quay lại khi có quy tắc cấm chúng, chỉ giảm tần suất chứ không biến mất hoàn toàn. Bạn có thể đo tần suất của chính mình: chạy cùng một task 10 lần trong các session mới rồi đếm số lần vi phạm. Khi con số đó cần bằng 0, quy tắc đó không nên nằm trong prompt.

Session hiện tại của bạn cũng trở thành một ví dụ. Nếu agent vi phạm quy tắc ở turn 12 mà bạn bỏ qua, vi phạm đó sẽ nằm trong context dưới dạng một ví dụ minh họa và gần đây hơn nhiều so với quy tắc. Hãy sửa vi phạm ngay khi bạn thấy nó. Một vi phạm không được sửa sẽ dạy phần còn lại của session làm theo.

Instruction file không phải là security boundary. Nó định hướng hành vi nhưng không cưỡng chế hành vi đó. Những việc mà sai sót gây hậu quả lớn, như credential hoặc command phá hủy dữ liệu, phải được xử lý bằng permission hoặc hook. Giữ secret ngoài tầm với của agent áp dụng cùng nguyên tắc cho dữ liệu: đừng yêu cầu agent không đọc một file; hãy sắp xếp để file đó không thể đọc được.

Tóm lại: hãy chứng minh file đã được load, làm cho quy tắc có thể kiểm tra, đặt quy tắc cạnh đối tượng mà nó chi phối, và khi tỷ lệ vi phạm vẫn quan trọng, hãy đưa quy tắc ra khỏi phần prose. Một quy tắc mà agent không thể bỏ qua là quy tắc lẽ ra không nên yêu cầu agent tuân theo.

FAQ

Tại sao Claude Code bỏ qua CLAUDE.md của tôi?

Trước khi cho rằng file bị bỏ qua, hãy kiểm tra xem file đã được nạp chưa. Chạy /context và xem danh sách Memory files; file không có tên trong danh sách này không nằm trong conversation. Các file hướng dẫn được gửi dưới dạng user message sau system prompt và được xem là context thay vì cấu hình bắt buộc, nên không có bảo đảm tuân thủ tuyệt đối. Hầu hết trường hợp thực tế thuộc một trong bốn nguyên nhân: file nằm trong subdirectory mà agent chưa đọc, hai file có nội dung mâu thuẫn và model chọn một cách tùy ý, rule quá mơ hồ nên không thể đối chiếu với một hành động, hoặc code xung quanh thể hiện điều ngược lại với rule.

Chỉnh sửa file hướng dẫn giữa session có thay đổi gì không?

Không thay đổi bản copy đã nằm trong conversation. Các file nằm phía trên working directory được nạp đầy đủ khi khởi chạy, nên model giữ nội dung tại thời điểm khởi chạy. Để nạp thay đổi, hãy bắt đầu session mới hoặc yêu cầu agent đọc file bằng các file tool thông thường. Cách này đưa phiên bản hiện tại vào conversation dưới dạng message mới. Sau khi compact, file tại project root được đọc lại từ disk, nên phiên bản mới cũng được nạp tại thời điểm đó.

File nào được ưu tiên khi CLAUDE.md ở root và file lồng nhau có nội dung mâu thuẫn?

Không file nào được ưu tiên một cách đáng tin cậy. Các file được phát hiện sẽ được nối vào context thay vì ghi đè lẫn nhau. Thứ tự đi từ filesystem root xuống working directory, nên file gần nhất chỉ được đọc sau cùng. Không có precedence engine để xử lý mâu thuẫn, và tài liệu của Claude Code nêu rõ rằng các rule mâu thuẫn có thể được xử lý tùy ý. Hãy viết các file lồng nhau dưới dạng phần bổ sung và ghi rõ path mà chúng áp dụng. Xóa nội dung mâu thuẫn thay vì cố làm cho một rule có độ ưu tiên cao hơn rule khác.

Các instruction của tôi có tồn tại sau /compact không?

Điều này phụ thuộc vào cách chúng được nạp. File project root CLAUDE.md, các rule không có phạm vi và auto memory được nạp lại từ disk sau khi compact. Các rule có frontmatter paths: và các file CLAUDE.md lồng trong subdirectory sẽ bị mất cho đến khi file tương ứng được đọc lại. Nội dung bạn chỉ nhập trong chat chỉ tồn tại nếu summariser tình cờ giữ lại. Nếu một rule phải có hiệu lực trong toàn bộ session, hãy đặt rule đó trong file project root và không dùng paths: frontmatter.

Khi nào nên chuyển một rule thành hook thay vì viết bằng prose?

Khi việc kiểm tra có thể xác định bằng logic rõ ràng và chi phí bỏ sót cao hơn chi phí viết một script nhỏ. Các trường hợp như giới hạn file path, yêu cầu chạy command trước khi commit và cấm gọi tool đều phù hợp. Một PreToolUse hook thoát với status 2 sẽ chặn hẳn tool call và gửi nội dung stderr về cho model làm lý do. Vì vậy rule vẫn có hiệu lực dù còn hay không còn trong context. Những việc formatter hoặc linter có thể tự quyết định nên giao cho tool tương ứng và xóa hoàn toàn khỏi file hướng dẫn.