SSD Nodes Learn Hosting plans →
Hướng dẫn Matt ConnorBởi Matt Connor · Cập nhật ngày 2026-08-26

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

File instruction yêu cầu dừng nhưng agent vẫn chạy? Tìm đúng nguyên nhân: rule chưa vào context, quá mơ hồ, bị mâu thuẫn hoặc bị đẩy xa sau compaction.

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à bạn quá lịch sự. Quy tắc chưa từng nằm trong context window. Quy tắc quá mơ hồ nên không thể đối chiếu với một hành động. Một nội dung khác trong context mâu thuẫn với quy tắc đó, thường là đ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 turn hiện tại, nên agent làm việc dựa trên những gì ở gần hơ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ụ thực tế, 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 August 2026. Các công cụ khác có thể khác về chi tiết nhưng nhìn chung hoạt động theo cùng nguyên lý.

Trước tiên 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ứa instruction của bạn, cuộc hội thoại và mọi file mà agent đã đọc. Harness là chương trình bao quanh model, có nhiệm vụ đọc file từ disk và ghép chúng thành khối văn bản đó. Hầu hết 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 về model.

Tệp instruction của bạn là một message, không phải 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à dán nội dung vào conversation. Trong Claude Code, nội dung đó đượ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ông dễ chịu. Các rule của bạn phải cạnh tranh với mọi phần văn bản khác trong cửa sổ, trên cùng một mặt bằng. Một rule chỉ là một nhận định. Tệp mà agent vừa mở là bằng chứng. Khi hai bên mâu thuẫn, bằng chứng thường chiếm ưu thế. 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êu rõ điều này: các tệp instruction được xử lý như context, không phải configuration được thực thi. Nếu muốn chặn một action bất kể model quyết định gì, bạn cần một hook, không phải một câu lệnh. Hãy ghi nhớ ý này. Phần lớn các cách khắc phục ở cuối bài đều áp dụng ý này cho một trường hợp cụ thể.

Các file instruction nào được nạp và thời điểm nạp

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ừ filesystem root đến thư mục làm việc của bạn đều được nạp đầ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 nối sau file chính.

Các file nằm 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 nạp khi khởi động. Chúng được nạp 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 lượt xử lý.

Chỉ một 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, nhưng 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 bao giờ có mặt trong context. Nếu repository của bạn chia guidance qua các file instruction theo từng package trong monorepo, đây là điều đầu tiên cần kiểm tra mỗi lần.

Còn một lỗi khi nạp file nữa. Đây là nguyên nhân phổ biến nhất của tình huống “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 nạp. Cách kết 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. Việc quyết định nội dung nào nên nằm trong file đó là một câu hỏi riêng, được trình bày trong cách tách instruction cho agent khỏi tài liệu dành cho con người.

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

Đừng chỉnh câu chữ cho đến khi bạn có bằng chứng agent có thể 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 hiển thị tên mọi file hướng dẫn đã thực sự được nạp. Nếu file không có trong danh sách này thì file đó không nằm trong conversation, nên 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, kể cả những file chưa tồn tại.

Để kiểm tra sâu hơn, hãy ghi lại các lần nạp 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 nạp: 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, nên 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. Event này bỏ qua exit status, 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 nạp file, hãy dừng việc viết lại câu chữ. Vấn đề nằm ở vị trí đặt file.

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

Có hai tác động riêng biệt ở đây và mỗi tác động 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ỏ tác động này bằng cấu hình, nhưng có thể đo lường nó. Chạy cùng một tác vụ trong một session mới. Nếu rule vẫn được tuân thủ ở đó nhưng không còn hiệu lực khi session kéo dài, thì nguyên nhân là khoảng cách.

Compaction. Khi window đầy, harness sẽ tóm tắt phần hội thoại đã diễn ra rồi tiếp tục từ bản tóm tắt đó. Những gì 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 rõ kết quả theo từng cơ chế, và khác biệt rất lớn. Các rule ở project root CLAUDE.md và các rule không có scope sẽ được nạp lại từ disk sau compaction. Auto memory cũng được nạp lại từ disk. Các rule có frontmatter paths: sẽ mất cho đến khi đọc lại một file phù hợp. Các file CLAUDE.md lồng trong subdirectory sẽ mất cho đến khi đọc lại một file trong subdirectory đó.

Xếp hạng các instruction theo bảng này sẽ cho thấy ngay thứ tự dễ mất hiệu lực. Rule chỉ được nhập vào chat là thứ dễ mất nhất trong session: nó chỉ tồn tại nếu bản tóm tắt tình cờ giữ lại. Rule trong packages/api/CLAUDE.md đứng tiếp theo, vì nó chỉ được load một lần, bị loại khỏi bản tóm tắt, rồi chỉ xuất hiện lại khi lần tiếp theo có file trong directory đó được đọc. Rule trong file ở project root bền vững nhất, vì file này được đọc lại từ disk sau mỗi lần compaction.

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

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

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

Rule mô tả một lựa chọn ưu tiên. Code thể hiện một lựa chọ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 phía và 3 ví dụ cụ thể, mới và phù hợp với task ở phía còn lại. 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: các file đó là code legacy.

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

Cách 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 dùng. Không được sao chép pattern đó.

Câu thứ 2 mới là phần quyết định. 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 mà repository của bạn rõ ràng không tuân theo: style của commit mà lịch sử repository không dùng, cấu trúc test mà một nửa test suite bỏ qua, hoặc quy ước import chỉ được áp 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.

Quy tắc mơ hồ không thể kiểm tra, nên cũng không thể tuân thủ

"Viết code sạch." "Khô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ù do agent hay do bạn thực hiện. 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 sẽ phải đoán, còn bạn thì đánh giá phỏng đoán đó theo cảm nhận.

Hãy áp dụng phép kiểm tra sau cho từng dòng trong file. Viết lệnh shell sẽ thoát với mã khác 0 khi quy tắc bị vi phạm. Nếu không thể viết lệnh đó, quy tắc không thể kiểm tra được. 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 ngay phía trên giải thích lý do."
  • Không thể kiểm tra: "Test các thay đổi." 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 đúng cách." Có thể kiểm tra: "Dùng indentation 2 space trong các file .ts."

"Không over-engineer" là quy tắc mà mọi người thường 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ự đáp ứng yêu cầu sẽ cung cấp cho agent các tiêu chí để tự đối chiếu với diff của nó.

Kích thước cũng là cùng một vấn đề dưới dạng khác. Hướng dẫn của Claude Code khuyến nghị mỗi instruction file nên dưới 200 dòng và nói rõ rằng file dài hơn làm giảm mức độ tuân thủ. File 700 dòng không phải là instruction chặt chẽ hơn. Đó là 700 dòng nhận định, với nhiều khả năng mâu thuẫn với nhau hơn; đồng thời toàn bộ nội dung đó bị tính vào window của bạn trong từng turn, nên thể hiện trực tiếp trong mức sử dụng token của bạn. Việc cấu trúc file để mỗi quy tắc nằm dưới một heading mà người đọc có thể quét nhanh được trình bày trong cách viết instruction file để agent có thể thực thi. Tốt hơn nữa, hãy cắt những phần chỉ mô tả thay vì đưa ra instruction: sơ đồ directory cho biết handler và model nằm ở đâu là thông tin về cấu trúc mà agent có thể tra cứu khi cần từ map đã parse của repository, thay vì phải mang theo trong window ở mỗi turn.

Cách chẩn đoán trong mười phút

Chạy các lệnh dưới đây theo thứ tự. Bỏ qua bước cuối là nguyên nhân khiến nhiều người kết thúc với một file dài đầy các rule 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 trong danh sách này chưa áp dụng.
  2. Tái hiện trong một session mới. Bắt đầu session mới và đưa vào task nhỏ nhất lẽ ra phải kích hoạt rule. Nếu rule 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 trong chính rule.
  3. Loại bỏ yếu tố 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ủ tăng trở lại, code xung quanh đã lấn át câu lệnh 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 hướng dẫn bất kỳ và sẽ không cho bạn biết điều đó.
  5. Làm cho rule có thể kiểm tra rồi kiểm thử 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 rõ rệt, cách diễn đạt là nguyên nhân.

Bước 4 chỉ cần một lệnh. Grep mọi nguồn instruction để tìm topic này, 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

Nếu hai file có các nội dung khác nhau, đó chính là bug. 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 yêu cầu phân xử.

Các cách khắc phục, theo mức độ hiệu quả

Mỗi bước dưới đây có hiệu quả cao hơn bước trước, nhưng tốn nhiều công sức thiết lập hơn. Bắt đầu từ trên cùng khi việc sửa lại câu chữ của một rule là đơn giản. Chuyển xuống ngay khi rule đủ quan trọng để không thể chấp nhận việc đôi lúc bị bỏ sót.

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

Chi tiết về bước 3. Giả sử agent tuyệt đối không được sửa các migration file. Đặ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 bên dưới 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 được chuyển cho model dưới dạng message giải thích việc bị chặn. ${CLAUDE_PROJECT_DIR} trỏ đến project root, nên hook hoạt động dù agent đang ở directory nào. Agent không cần đồng ý với rule, ghi nhớ rule hoặc 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ùng nhiệm vụ mà không cần duy trì script, còn các permission mode quyết định nội dung nào được chạy mà không cần hỏi bạn trước. Nếu một instruction thực sự phải nằm ở cấp system prompt thay vì trong user message, --append-system-prompt sẽ đặt nó ở đó. Tuy nhiên, instruction phải được truyền trong mọi invocation, nên cách này phù hợp với script hơn là công việc tương tác.

Điều bạn không thể chỉ dẫn để loại bỏ

Hãy phân biệt rõ phần nào thuộc về bạn. Vị trí đặt, 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ả, nên tác giả phải sửa. 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.

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

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 hiển nhiên tiếp theo. Những hành vi này sẽ quay lại khi có rule cấm chúng, chỉ giảm tần suất chứ không về 0. Bạn có thể đo tần suất của 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. Nếu con số đó cần bằng 0, rule phải được đưa ra khỏi prompt. Gọi một job là đã hoàn tất trong khi vẫn còn phần chưa làm cũng có cùng dạng thói quen này. Cách sửa phải mang tính cấu trúc thay vì chỉ bằng câu chữ: skill unlazy thay câu đó bằng một Depth Tree và các file gate mà agent phải vượt qua trước khi được phép xác nhận đã hoàn tất.

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

Instruction file không phải security boundary. Nó định hình hành vi nhưng không thực thi hành vi đó. Bất cứ thứ gì mà việc bỏ sót gây hậu quả nghiêm trọng, chẳng hạn credentials hoặc destructive commands, phải được xử lý bằng permissions hoặc hook. Giữ secrets 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, biến rule thành thứ có thể kiểm tra, đặt rule cạnh đối tượng mà nó chi phối, và khi miss rate vẫn còn quan trọng, hãy đưa rule ra khỏi prose. Một rule mà agent không thể bỏ qua là một rule vốn chưa từng được yêu cầu agent tuân thủ.

FAQ

Vì 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 đó thì 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 xử lý như context, không phải 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 4 nhóm: file nằm trong subdirectory mà agent chưa đọc, 2 file mâu thuẫn và model chọn một file một cách tùy ý, rule quá mơ hồ để đố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.

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

Không thay đổi bản sao đã có trong conversation. Các file nằm phía trên working directory được nạp đầy đủ khi khởi động, nên nội dung model đang giữ là nội dung tại thời điểm khởi động. Để nạp bản sửa, 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 compaction, file ở 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 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à nêu rõ path mà chúng áp dụng. Xóa phần mâu thuẫn thay vì cố làm cho một rule có độ ưu tiên cao hơn rule kia.

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

Còn tùy cách chúng được nạp. Project root CLAUDE.md, các rule không có phạm vi và auto memory được nạp lại từ disk sau compaction. 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ỉ còn 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 frontmatter paths:.

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

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

#claude-code#agents-md#context#prompting#coding-agents