Hướng dẫn viết CLAUDE.md để Claude Code hiểu đúng dự án của bạn

Mình là Tony, hiện làm và vận hành các sản phẩm web, sử dụng Claude Code làm công cụ phát triển chính hằng ngày. Khi đưa coding agent vào một repo đã có sẵn kiến trúc, quy ước code và những ràng buộc nghiệp vụ, mình quan tâm đến cách giúp agent làm đúng theo dự án, thay vì mỗi phiên lại phải giải thích những điều giống nhau. Một trong những công cụ để giải quyết bài toán đó là CLAUDE.md.

Đây là bài mở đầu cho series Claude Code cho dự án thực tế, gồm sáu bài về những vấn đề developer thường gặp: tổ chức CLAUDE.md, phát triển một tính năng từ đầu đến cuối, xây dựng Skill, quản lý context và memory, kiểm soát quyền thực thi, và kiểm tra giao diện bằng trình duyệt. Series dành cho developer và tech lead đang duy trì codebase thực tế, không đi lại từ bước cài đặt Claude Code. Đọc xong bài này, bạn sẽ có một mẫu CLAUDE.md để áp dụng, biết cách tách quy tắc theo thư mục, chọn nơi lưu từng loại thông tin và kiểm tra agent có làm theo chỉ dẫn hay không.

Để minh họa, mình dùng một monorepo TypeScript giả định, gồm ứng dụng quản trị, API phục vụ nhiều tổ chức khách hàng và các package dùng chung. Repo có những quy tắc áp dụng cho toàn bộ dự án, những ràng buộc bắt buộc ở API và conventions chỉ dành cho UI. Bối cảnh này sẽ đi xuyên suốt bài để bạn thấy cách tổ chức chỉ dẫn trên một codebase có nhiều thành phần.

1. CLAUDE.md giải quyết việc gì và không giải quyết việc gì?

Khi bắt đầu một phiên làm việc, Claude Code cần hiểu dự án trước khi sửa code. Agent có thể đọc source, xem cấu trúc thư mục và tìm file cấu hình, nhưng không phải quy tắc nào cũng thể hiện rõ trong code. Chẳng hạn, team có thể yêu cầu mọi truy vấn dữ liệu phải kiểm tra tenant scope, hoặc developer phải chạy một nhóm test nhất định trước khi hoàn thành task. Nếu thiếu chỉ dẫn, agent phải tự suy luận từ những gì tìm được. Với codebase có nhiều conventions hoặc code cũ chưa tuân thủ quy ước mới, suy luận đó có thể dẫn đến lựa chọn sai.

CLAUDE.md cung cấp những chỉ dẫn ổn định để Claude Code sử dụng trong quá trình làm việc. Team có thể duy trì file này cùng source code, để agent hiểu những nguyên tắc cần giữ khi tham gia phát triển dự án. CLAUDE.md là context, không phải cấu hình bắt buộc thực thi. Claude vẫn có thể làm sai hoặc bỏ sót chỉ dẫn. Nếu cần chặn cứng một hành động, chẳng hạn cấm sửa migration hoặc chạy lệnh nguy hiểm, bạn phải sử dụng hooks hoặc permissions.deny trong settings.

Claude Code tìm CLAUDE.md ở đâu?

Claude Code hỗ trợ nhiều vị trí đặt file:

Vị trí	Phạm vi	Khi nào dùng
~/.claude/CLAUDE.md	Cá nhân, mọi dự án	Quy ước làm việc riêng của developer
./CLAUDE.md	Dự án	Quy tắc chung của team
./.claude/CLAUDE.md	Dự án	Vị trí thay thế cho file ở root
./CLAUDE.local.md	Cá nhân trong một dự án	Chỉ dẫn riêng không cần chia sẻ
Managed policy	Tổ chức	Chính sách quản trị áp dụng cho thành viên

Với CLAUDE.md cấp dự án, team nên commit vào Git để mọi người cùng sử dụng và review các thay đổi. Nếu dùng CLAUDE.local.md cho thiết lập cá nhân, hãy thêm file này vào .gitignore. Khi khởi động, Claude Code nạp các file CLAUDE.md ở thư mục đang làm việc và những thư mục cha, theo thứ tự từ gốc tới thư mục hiện tại. CLAUDE.md trong thư mục con chỉ được nạp khi agent đọc, ghi hoặc sửa file thuộc thư mục đó. Các file được cộng dồn vào context, không ghi đè lẫn nhau. Vì vậy, chỉ dẫn riêng cho API có thể bổ sung quy tắc chung, nhưng không nên mâu thuẫn với nó.

CLAUDE.md khác auto memory thế nào?

Claude Code còn có auto memory, tự ghi chú tại ~/.claude/projects/<project>/memory/ với MEMORY.md làm mục lục. Đây là cơ chế khác với CLAUDE.md do bạn chủ động xây dựng và duy trì; mình sẽ đi sâu vào context và memory trong một bài riêng. Ở đây, mình tập trung vào những chỉ dẫn mà bạn và team chủ động viết cho agent.

2. Phân loại thông tin trước khi viết

Một lỗi dễ gặp là thấy điều gì agent cần biết thì thêm ngay vào CLAUDE.md. Sau một thời gian, file có thể chứa cả quy tắc code, ghi chú kiến trúc, hướng dẫn chạy test, tiến độ task và những quyết định chỉ áp dụng cho một tính năng. Developer khó biết phần nào còn hiệu lực, còn Claude phải xử lý thêm nhiều context không liên quan. Trước khi viết, mình đề xuất chia thông tin thành bốn nhóm.

Nhóm thứ nhất là quy tắc ổn định của dự án. Chẳng hạn, package manager, cấu trúc repository, nguyên tắc dependency hoặc yêu cầu kiểm tra trước khi báo hoàn thành. Những thông tin này phù hợp với CLAUDE.md cấp dự án.

Nhóm thứ hai là quy tắc theo vùng code. API phải kiểm tra tenant scope khi truy vấn dữ liệu, còn package UI có convention riêng cho component. Agent chỉ cần nhận những chỉ dẫn này khi làm việc tại vùng tương ứng.

Nhóm thứ ba là kiến thức tham khảo. Sơ đồ kiến trúc, API contract và các quyết định thiết kế có thể khá dài. Team nên giữ chúng ở thư mục tài liệu và chỉ rõ nơi agent cần đọc.

Nhóm thứ tư là quy trình theo loại task. Một quy trình review API gồm nhiều bước, với checklist và tiêu chí đánh giá riêng, có thể phù hợp với Skill hơn CLAUDE.md. Đây là nhóm dành cho những hướng dẫn agent không cần sử dụng trong mọi task.

Monorepo trong ví dụ có cấu trúc:

.
├── CLAUDE.md
├── package.json
├── pnpm-workspace.yaml
├── apps/
│   ├── admin/
│   │   ├── src/
│   │   └── package.json
│   └── api/
│       ├── src/
│       │   ├── modules/
│       │   └── middleware/
│       └── package.json
├── packages/
│   ├── ui/
│   │   ├── src/
│   │   └── package.json
│   └── shared/
│       ├── src/
│       └── package.json
└── docs/
    ├── architecture.md
    └── api-contracts.md

Trong repo này, pnpm là package manager chung. API phải đảm bảo dữ liệu của từng tenant được cách ly, còn packages/ui có conventions riêng cho component. docs/architecture.md giải thích quan hệ giữa các module, nhưng agent không cần đọc toàn bộ tài liệu đó trong mọi phiên. Cách phân loại này giúp team xác định ngay nên đặt một quy tắc ở đâu, thay vì dồn tất cả vào file root.

3. Một cấu trúc CLAUDE.md đủ dùng cho team

Hướng dẫn chính thức khuyến nghị giữ mỗi file dưới khoảng 200 dòng, dùng heading, danh sách và những câu cụ thể, có thể kiểm tra được. Chẳng hạn, "dùng 2 dấu cách để thụt lề" rõ hơn "format code cho đẹp". Với monorepo đang xét, mình sẽ bắt đầu bằng cấu trúc repository, ranh giới giữa các package, quy trình phát triển và yêu cầu verification.

Mẫu CLAUDE.md tại root

File: ./CLAUDE.md

# Project Instructions

## Project Overview

This repository is a TypeScript monorepo.

Applications:
- apps/admin: administrative web application
- apps/api: backend API

Shared packages:
- packages/ui: reusable UI components
- packages/shared: shared types and utilities

Package manager: pnpm

## Repository Boundaries

- Keep application-specific logic inside its application.
- Do not import application code into shared packages.
- Use existing shared packages before introducing duplicates.
- Do not change public API contracts without identifying
  affected consumers.

## Development Workflow

Before editing:
1. Identify affected applications and packages.
2. Read the relevant implementation and tests.
3. State assumptions that affect the proposed change.
4. Propose an implementation plan for multi-file changes.

During implementation:
- Follow existing module conventions.
- Keep changes within the agreed scope.
- Add or update tests for changed behavior.
- Do not change unrelated code.

## Verification

Run checks for affected packages.

Common commands:

- API tests: pnpm -F api test
- Admin tests: pnpm -F admin test
- Shared tests: pnpm -F shared test
- UI tests: pnpm -F ui test

Use the package names defined in package.json.

Do not claim verification passed without running it.

## Definition of Done

Before reporting completion:

- Summarize changed files and behavior.
- Report commands executed and their results.
- Identify tests that were not run.
- Describe remaining risks or assumptions.
- List any required follow-up work.

## Documentation

Architecture: docs/architecture.md
API contracts: docs/api-contracts.md

Read relevant documentation before changing
architecture or API contracts.

Đây là mẫu dành cho repo giả định, nhưng một team có thể copy về rồi chỉnh lại cho phù hợp. Các package trong ví dụ được đặt tên api, admin, shared và ui trong package.json, nên lệnh pnpm -F api test mới chọn đúng package. Team cũng cần đảm bảo những script test được khai báo tương ứng trước khi dùng các lệnh này.

Phần Project Overview giúp agent xác định ứng dụng và package nào chịu trách nhiệm cho từng phần. Nó không cố mô tả toàn bộ kiến trúc; Claude có thể đọc tài liệu liên quan khi cần. Repository Boundaries giúp agent tránh đặt logic sai vị trí. Ví dụ, khi phát triển tính năng export báo cáo, Claude có thể muốn đưa code truy vấn dữ liệu vào shared package để tái sử dụng. Quy tắc dependency nhắc agent rằng shared package không nên phụ thuộc vào application code.

Development Workflow yêu cầu agent đọc implementation, xác định giả định và lập kế hoạch trước khi sửa nhiều file. Verification đưa ra những lệnh test cụ thể, còn Definition of Done yêu cầu agent báo những gì đã kiểm tra, những gì chưa chạy và rủi ro còn lại. Developer có thể dựa vào đó để review kết quả.

Có nên import tài liệu vào CLAUDE.md?

Claude Code hỗ trợ cú pháp @đường/dẫn/file để import nội dung từ file khác. Đường dẫn tương đối được tính từ file chứa lệnh import, và hệ thống hỗ trợ tối đa bốn tầng import lồng nhau. Ví dụ, tại CLAUDE.md ở root:

# Project Instructions

## Architecture

@docs/architecture.md

## Development Rules

@docs/development-rules.md

Import giúp team chia tài liệu thành nhiều file để dễ bảo trì, nhưng không làm giảm context vì Claude vẫn nạp toàn bộ nội dung được import. Nếu chỉ muốn agent tra cứu khi cần, hãy cung cấp đường dẫn thay vì import. CLAUDE.md cũng hỗ trợ comment HTML dạng khối. Claude Code bỏ các comment <!-- --> trước khi đưa nội dung vào context, nên team có thể để lại ghi chú bảo trì mà không tốn token cho những dòng đó.

4. Khi nào nên tách chỉ dẫn theo thư mục?

Giả sử bạn đưa tất cả quy tắc backend, frontend và shared packages vào CLAUDE.md ở root. Khi Claude sửa một button trong ứng dụng quản trị, nó vẫn phải xử lý các chỉ dẫn dành cho API. Khi sửa API, agent lại nhận thêm quy tắc về UI components. Với monorepo có nhiều conventions, mình sẽ tách những quy tắc chỉ áp dụng cho một vùng code.

Claude Code hỗ trợ thư mục .claude/rules/, trong đó mỗi file Markdown chứa một nhóm quy tắc. Nếu file không khai báo paths, Claude nạp quy tắc lúc khởi động. Nếu có frontmatter paths với các glob, Claude chỉ nạp quy tắc khi đọc hoặc sửa file khớp mẫu.

Tách quy tắc cho API và UI

Mình thêm hai file:

.claude/
└── rules/
    ├── api.md
    └── ui.md

File .claude/rules/api.md:

---
paths:
  - "apps/api/**/*.ts"
---

# API Rules

## Tenant Isolation

- Resolve the authenticated tenant before accessing
  tenant-scoped data.
- Scope tenant-owned queries to the authenticated tenant.
- Never trust tenantId from request parameters without
  validating authorization.
- Do not return data belonging to another tenant.

## API Changes

- Preserve existing response contracts unless the task
  explicitly requires a change.
- Add authorization tests for tenant-scoped endpoints.
- Test both allowed and denied access.
- Review affected API consumers before changing schemas.

File .claude/rules/ui.md:

---
paths:
  - "packages/ui/**/*.ts"
  - "packages/ui/**/*.tsx"
---

# UI Package Rules

- Keep reusable components independent of applications.
- Define explicit TypeScript types for public props.
- Follow existing component export conventions.
- Do not introduce application-specific business logic.
- Update component tests when behavior changes.

Khi Claude làm việc với file TypeScript trong apps/api, nó nhận thêm quy tắc API. Khi agent làm việc trong packages/ui, quy tắc UI tương ứng được nạp. CLAUDE.md ở root chỉ cần giữ những chỉ dẫn chung.

Vì sao tenant isolation cần được viết rõ?

Giả sử API có endpoint xuất báo cáo:

GET /reports/export

Một implementation có thể lấy danh sách báo cáo theo bộ lọc mà request cung cấp. Nếu query không giới hạn theo tenant đang được xác thực, người dùng có thể nhận dữ liệu của tổ chức khác. Quy tắc "Scope tenant-owned queries to the authenticated tenant" yêu cầu agent chú ý đến phạm vi dữ liệu. Quy tắc "Test both allowed and denied access" yêu cầu kiểm tra cả trường hợp được phép lẫn bị từ chối. Team vẫn phải triển khai authorization trong code và viết test xác minh tenant isolation. Chỉ dẫn trong CLAUDE.md hay rules không thay thế những cơ chế đó.

Có nên đặt CLAUDE.md trong thư mục con?

Bạn cũng có thể đặt apps/api/CLAUDE.md. Khi Claude đọc, ghi hoặc sửa file trong thư mục này, Claude Code sẽ nạp chỉ dẫn tương ứng. CLAUDE.md theo thư mục phù hợp khi bạn muốn giữ chỉ dẫn ngay cạnh vùng code. .claude/rules/ phù hợp khi muốn tập trung quy tắc và xác định phạm vi bằng glob. Trong ví dụ này, mình chọn .claude/rules/ để team dễ quản lý. Không cần duy trì cùng một quy tắc ở cả hai nơi.

5. Những thông tin không nên nhét vào CLAUDE.md

CLAUDE.md càng dài không có nghĩa Claude càng hiểu dự án tốt hơn. Khi team thêm nhiều chỉ dẫn không liên quan, agent phải xử lý thêm context và có thể gặp những quy tắc mâu thuẫn. Ví dụ:

- Always create a new component for each new UI feature.
- Reuse existing components whenever possible.

Hai quy tắc này có thể dẫn đến những lựa chọn khác nhau cho cùng một task. Theo hướng dẫn chính thức, khi chỉ dẫn mâu thuẫn, Claude có thể chọn một trong hai. Team nên sửa thành tiêu chí cụ thể:

- Reuse an existing UI component when it supports
  the required behavior.
- Create a new component when existing components
  cannot support the behavior without unrelated changes.

Không nên đưa tiến độ task ngắn hạn vào CLAUDE.md. Nếu team đang sửa export báo cáo, hãy giữ brief và progress trong tài liệu riêng, thay vì cập nhật file root sau mỗi phiên. Tương tự, tài liệu kiến trúc hoặc API contract dài nên được lưu riêng. Claude có thể đọc khi cần; import toàn bộ vào CLAUDE.md vẫn tiêu tốn context.

Không đưa API key, token, mật khẩu, credentials hoặc dữ liệu nhạy cảm vào những file được commit cùng repository. Cuối cùng, các quy trình nhiều bước nhưng chỉ dùng cho một loại task nên được chuyển sang Skill. Ví dụ, team có thể xây Skill riêng để review API compatibility, migration, authorization, test và documentation, thay vì yêu cầu Claude đọc toàn bộ quy trình trong mọi phiên.

Bảng quyết định: Đưa thông tin vào đâu?

Loại thông tin	Vị trí nên dùng	Ví dụ
Quy tắc chung, ổn định	CLAUDE.md cấp dự án	Package manager, cách chạy test, Definition of Done
Quy tắc riêng theo vùng code	.claude/rules/ với paths	Tenant isolation cho apps/api/**/*.ts
Quy tắc gắn với một thư mục	CLAUDE.md trong thư mục con	Convention riêng cho một ứng dụng
Kiến thức cần tra cứu	Tài liệu tham khảo	Architecture, API contracts, ADR
Quy trình nhiều bước, dùng theo task	Skill	Review API compatibility
Chỉ dẫn cá nhân cho mọi repo	~/.claude/CLAUDE.md	Quy ước làm việc riêng
Chỉ dẫn cá nhân trong một repo	CLAUDE.local.md	Ghi chú môi trường cá nhân
Quy tắc bắt buộc phải chặn hành động	Hooks hoặc permissions.deny	Chặn lệnh nguy hiểm, cấm sửa migration

Khi thêm một quy tắc mới, bạn có thể dùng bảng này để chọn vị trí phù hợp. Quan trọng nhất là xác định quy tắc áp dụng ở đâu, khi nào agent cần đọc và có cần cơ chế chặn thực thi hay không. Chẳng hạn, yêu cầu agent không sửa migration thuộc nhóm cần kiểm soát bằng cơ chế thực thi nếu team muốn ngăn hành động đó, chứ không thể chỉ ghi trong CLAUDE.md.

6. Kiểm tra agent có áp dụng quy tắc hay không

Sau khi viết CLAUDE.md, bạn cần kiểm tra hành vi thay vì chỉ hỏi Claude có hiểu quy tắc hay không. Chạy /context để xem Claude Code đang nạp những file nào. Lệnh /memory cho phép mở các file memory để kiểm tra hoặc chỉnh sửa. Còn /init có thể tạo CLAUDE.md khởi đầu từ codebase hoặc gợi ý cải thiện nếu file đã tồn tại. Với monorepo ví dụ, mình đề xuất ba nhóm kiểm thử: phạm vi quy tắc, ràng buộc nghiệp vụ và quy trình bàn giao.

Kiểm thử 1: Agent có nhận đúng quy tắc theo thư mục?

Giao cho Claude một task chỉ sửa UI component trong packages/ui, rồi dùng /context để xem những file đang được nạp. Sau đó, chuyển sang một task liên quan đến apps/api và kiểm tra lại. Khi agent truy cập file TypeScript thuộc vùng API, quy tắc trong api.md phải được nạp theo đường dẫn. Mục tiêu là xác minh quy tắc có đúng phạm vi, không phải yêu cầu Claude nhắc lại toàn bộ chỉ dẫn.

Kiểm thử 2: Agent có xử lý đúng tenant isolation?

Dùng một task giả định:

"Thêm endpoint cho phép quản trị viên xuất danh sách giao dịch. Endpoint phải hỗ trợ lọc theo khoảng ngày và phân trang."

Agent cần xác định tenant từ ngữ cảnh xác thực, giới hạn truy vấn dữ liệu và kiểm tra quyền truy cập. Trong test, tạo dữ liệu cho hai tenant A và B. Gửi request bằng tài khoản thuộc tenant A, sau đó thử truyền input có tham chiếu đến tenant B. Kết quả mong đợi là tài khoản A không nhận được dữ liệu của B.

Nếu Claude chỉ kiểm tra export thành công mà bỏ qua tenant isolation, team có bằng chứng rằng implementation chưa đáp ứng yêu cầu. Lúc này cần kiểm tra lại instruction, code và test. Một câu trả lời của agent rằng nó đã tuân thủ quy tắc không thay thế được kết quả kiểm thử.

Kiểm thử 3: Agent có bàn giao đủ bằng chứng?

Giao một thay đổi nhỏ có test rõ ràng trong apps/api. Sau khi Claude hoàn thành, kiểm tra xem agent có báo những file đã sửa, lệnh đã chạy, kết quả test và những phần chưa xác minh hay không. Nếu Claude ghi "All tests passed" nhưng chưa chạy test, agent đã không tuân thủ Definition of Done. Nếu test thất bại, báo cáo phải thể hiện đúng kết quả thay vì coi task đã hoàn thành.

Ma trận đánh giá

Quy tắc	Task thử	Bằng chứng mong đợi
API phải giới hạn dữ liệu theo tenant	Thêm endpoint export	Query có tenant scope, test chặn truy cập chéo
UI package không chứa business logic	Thêm component hiển thị báo cáo	Logic nghiệp vụ không bị đưa vào packages/ui
Thay đổi API phải xét consumer	Sửa response schema	Agent xác định nơi sử dụng và ảnh hưởng
Phải chạy test phù hợp	Sửa API handler	Có lệnh test và kết quả thực thi
Phải báo phần chưa kiểm tra	Hoàn thành task khi thiếu môi trường test	Báo rõ test chưa chạy và lý do

Nếu agent liên tục bỏ qua một quy tắc, hãy kiểm tra ba điểm: quy tắc có được nạp không, câu chữ có đủ cụ thể không và có chỉ dẫn nào mâu thuẫn không. Sau khi sửa, chạy lại cùng bộ task để đối chiếu kết quả. Nếu vấn đề nằm ở quyền thực thi, đừng cố giải quyết bằng cách viết CLAUDE.md nghiêm khắc hơn. Hãy dùng settings hoặc hooks để giới hạn hành động.

7. Bảo trì CLAUDE.md khi codebase thay đổi

Khi team đổi kiến trúc, tách package hoặc cập nhật tooling, CLAUDE.md cũng cần được review. Nếu không, Claude có thể làm đúng những chỉ dẫn cũ nhưng tạo ra kết quả không còn phù hợp với dự án. Ví dụ, nếu team chuyển API handlers sang package mới, glob apps/api/**/*.ts có thể không còn bao phủ toàn bộ vùng code cần áp dụng tenant isolation. Team phải cập nhật paths và kiểm tra lại.

Nếu team đổi tên package hoặc thay lệnh test, phần Verification cũng phải được sửa. Một lệnh lỗi thời có thể khiến agent báo thất bại không cần thiết hoặc bỏ qua bước kiểm tra cần thiết. Mình đề xuất checklist bảo trì:

• Khi thay đổi kiến trúc, kiểm tra Project Overview và Repository Boundaries.
• Khi đổi thư mục hoặc package, kiểm tra glob trong .claude/rules/.
• Khi thay đổi tooling, cập nhật lệnh ở phần Verification.
• Khi phát hiện quy tắc mâu thuẫn, sửa hoặc xóa quy tắc cũ.
• Khi quy trình trở nên dài, cân nhắc chuyển sang Skill.
• Khi agent thường xuyên bỏ qua quy tắc, bổ sung task kiểm thử.

Team cũng cần phân biệt chỉ dẫn trong CLAUDE.md với những điều chỉ nói trong hội thoại. Khi conversation bị nén bằng compaction, Claude Code đọc lại CLAUDE.md ở root dự án từ đĩa, còn chỉ dẫn chỉ xuất hiện trong hội thoại có thể mất. Nếu một convention cần áp dụng lâu dài, hãy ghi vào tài liệu phù hợp và commit khi cần chia sẻ.

Bắt đầu từ một CLAUDE.md nhỏ

Nếu repo chưa có CLAUDE.md, bạn có thể chạy /init để tạo bản khởi đầu, rồi review trước khi sử dụng. Hãy tập trung vào cấu trúc repo, ranh giới giữa các package, lệnh test và điều kiện bàn giao. Khi cần quy tắc riêng cho API hoặc UI, hãy tách sang .claude/rules/ với glob tương ứng.

Với monorepo có nhiều developer, mình ưu tiên ba điều: agent biết tìm code ở đâu, hiểu những ràng buộc phải giữ và biết kiểm tra gì trước khi báo hoàn thành. Các chỉ dẫn khác chỉ nên bổ sung khi có nhu cầu rõ ràng. Bạn có thể lấy mẫu CLAUDE.md trong bài, chỉnh cho đúng repo và dùng ba bài kiểm thử để đánh giá. Giữ những quy tắc giúp agent làm đúng, sửa những câu mơ hồ và bỏ thông tin đã lỗi thời. CLAUDE.md không cần trở thành tài liệu lớn nhất repo, mà cần đủ rõ để team duy trì lâu dài.

Ở bài tiếp theo, mình sẽ hướng dẫn quy trình dùng Claude Code để phát triển một tính năng từ đầu đến cuối, từ khảo sát repository, lập kế hoạch, triển khai đến chạy test và review kết quả. Agent có đủ thông tin về dự án vẫn khác với agent làm xong task đúng yêu cầu. Bài đó sẽ nối những chỉ dẫn trong CLAUDE.md với quy trình phát triển phần mềm thực tế.