Lệnh /goal trong Claude Code là một cơ chế thiết lập điều kiện hoàn thành, cho phép Claude tự động làm việc qua nhiều lượt (turns) liên tục cho đến khi đạt mục tiêu.
Thay vì phải phản hồi từng bước nhỏ, bạn chỉ cần đưa ra một mục tiêu cấp cao; Claude sẽ tự lập kế hoạch, thực hiện, kiểm tra kết quả và lặp lại cho đến khi đạt điều kiện kết thúc.
Vấn đề lớn nhất mà lệnh này giải quyết là bạn không còn phải "babysitting" (trông chừng sát sao) tác nhân nữa. Trong các tác vụ dài, bạn khỏi phải ngồi trực máy gõ "continue" hay "keep going" mỗi khi Claude dừng lại chờ xác nhận. Lệnh /goal chuyển quy trình làm việc từ tương tác từng bước sang chế độ ủy thác theo mục tiêu.

Lệnh /goal là gì và giải quyết vấn đề gì?
Dùng /goal đánh dấu một bước chuyển quan trọng: từ chỗ xem Claude như một "trợ lý" (assistant) sang
một "tác nhân" (agent) thực thụ. Ở chế độ thông thường, Claude làm xong một yêu cầu rồi dừng lại chờ
phản hồi. Với /goal, Claude nắm giữ một mục tiêu dài hạn và tự quản lý vòng lặp làm việc của chính
mình thông qua các công cụ như Bash, đọc/ghi file và đọc hiểu mã nguồn.
Lệnh này phát huy hiệu quả nhất với những bài toán có tính lặp lại hoặc đòi hỏi sự kiên trì:
- Di chuyển API (migration): thay một thư viện hoặc mẫu code trên toàn bộ project, chạy test cho đến khi mọi call site đều biên dịch thành công.
- Triển khai tính năng theo spec: thực hiện một bản thiết kế chi tiết với nhiều tiêu chí nghiệm thu (acceptance criteria) cho đến khi toàn bộ test tương ứng đều vượt qua.
- Dọn nợ kỹ thuật (backlog): xử lý danh sách issue đã gắn nhãn, dọn các TODO hoặc sửa lỗi linting trên quy mô lớn mà không cần can thiệp thủ công.
/goal hoạt động như thế nào?
/goal vận hành dựa trên cơ chế vòng lặp đánh giá (Evaluator loop). Điểm mấu chốt là Claude
không tự chấm điểm công việc của chính mình, để tránh xu hướng tuyên bố hoàn thành sớm. Sau mỗi lượt
làm việc, một mô hình nhỏ và nhanh (mặc định là Haiku, hoặc mô hình được cấu hình theo provider của
phiên) đóng
vai trò bộ đánh giá độc lập: nó nhận transcript, trả về quyết định có/không kèm một lý do ngắn. Nếu
là "không", lý do đó trở thành chỉ dẫn cho lượt tiếp theo của Claude.

Bộ đánh giá tuân thủ "nguyên tắc mù": nó chỉ thấy những gì xuất hiện trong transcript (nội dung hội
thoại) hiện tại. Quan trọng nhất, nó không tự gọi công cụ (tools), không chạy lệnh bash hay đọc file
độc lập. Do đó, nếu Claude thực hiện một thay đổi nhưng không để kết quả kiểm chứng — chẳng hạn
output của npm test — hiện ra trong transcript, bộ đánh giá sẽ không có bằng chứng để xác nhận và
bắt Claude làm tiếp. Điều kiện của bạn phải chứng minh được bằng chính output mà Claude in ra màn hình.
Cách dùng /goal: đặt, theo dõi và xóa mục tiêu
Bạn tương tác với mục tiêu qua các cú pháp lệnh trong terminal:
- Thiết lập mục tiêu: gõ
/goal [điều kiện hoàn thành]. Claude bắt đầu lượt làm việc đầu tiên ngay lập tức. - Kiểm tra trạng thái: gõ
/goal(không tham số) để xem điều kiện đang chạy, thời gian, số lượt đã đánh giá, chi phí token và lý do gần nhất của bộ đánh giá. - Hủy mục tiêu: dùng
/goal clearhoặc các alias nhưstop,reset,cancel. - Khôi phục mục tiêu: nếu phiên bị ngắt, dùng
--resumehoặc--continuekhi khởi động lại. Lưu ý: điều kiện được giữ nguyên, nhưng bộ đếm thời gian và lượng token đã dùng sẽ được đặt lại về 0.
Với CI hoặc khi chạy ở chế độ không tương tác (non-interactive), đặt mục tiêu ngay trên dòng lệnh:
claude -p "/goal Migrate toàn bộ axios sang fetch trong src/services, đảm bảo npm test thoát mã 0"Cách viết điều kiện hoàn thành hiệu quả
Thành công của một phiên /goal phụ thuộc vào cách bạn định nghĩa "xong". Công thức tối ưu để viết
điều kiện là: [Trạng thái kết thúc đo lường được] + [Lệnh kiểm chứng] + [Ràng buộc bảo vệ] + [Giới
hạn số lượt].

Các điều kiện cảm tính như "code sạch" (clean code) sẽ thất bại, vì "sạch" không phải một đầu ra terminal mà bộ đánh giá nhìn thấy được. Bạn cần bằng chứng cụ thể:
- Mơ hồ (tồi): "Hãy migrate module auth và làm cho nó chạy tốt, code sạch sẽ."
- Cụ thể (tốt): nêu rõ thư mục, lệnh kiểm chứng, ràng buộc bảo vệ và giới hạn lượt.
/goal Toàn bộ file trong src/services/auth dùng fetchWrapper thay vì axios.
Test trong tests/auth/ pass hoàn toàn (npm test thoát mã 0).
Không xóa hoặc skip bất kỳ file test nào. Dừng lại sau tối đa 15 lượt.Hai cái bẫy thường gặp. Thứ nhất, bỏ ràng buộc loại trừ __tests__ khiến Claude viết lại mock test
để chạy theo wrapper mới, phá vỡ tính cô lập của unit test. Thứ hai, những từ như "proper" hay
"clean": trong một lần chạy thực tế, mục tiêu "proper validation errors" khiến Claude trả về một
chuỗi 400, trong khi yêu cầu là một object JSON lỗi có cấu trúc. Hãy chỉ rõ schema JSON hoặc mã
thoát mà bạn cần.
/goal so với /loop, Stop hook và auto mode
Claude Code có ba cách giữ phiên chạy liên tục giữa các lượt. Chọn đúng cách quyết định cả hiệu quả token lẫn khả năng thành công của tác vụ:

| Phương pháp | Lượt tiếp theo bắt đầu khi | Dừng lại khi |
|---|---|---|
/goal | Lượt trước kết thúc | Mô hình đánh giá xác nhận điều kiện đã đạt |
/loop | Sau một khoảng thời gian | Bạn dừng thủ công, hoặc Claude thấy việc đã xong |
| Stop hook | Lượt trước kết thúc | Script hoặc prompt tùy chỉnh của bạn trả về tín hiệu dừng |
/goal điều khiển vòng lặp của các lượt hội thoại,
còn auto mode tự động phê duyệt các lệnh gọi công cụ (tool calls) bên trong mỗi lượt. Kết hợp cả hai
để có một phiên chạy hoàn toàn không cần giám sát.
Best practice, an toàn và khi nào không nên dùng /goal
Yêu cầu hệ thống và an toàn
- Chấp nhận Trust Dialog:
/goalchỉ chạy trong workspace bạn đã chấp nhận Trust Dialog, vì nó thuộc hệ thống hooks. - Bật hooks: lệnh sẽ báo lỗi nếu
disableAllHooksđược thiết lập trong cấu hình. - Luôn dùng Git: commit trước khi chạy, và ưu tiên một nhánh riêng. Claude có thể sửa hàng chục file tự động, bạn cần đường lui nếu kết quả sai.
- Cảnh giác trong CI: tác nhân có thể "lách luật". Nếu mục tiêu là "xóa mọi TODO", nó có thể xóa luôn đoạn code chứa TODO để về đích cho nhanh. Hãy luôn thêm ràng buộc "không được xóa hoặc đơn giản hóa code chức năng".
Khi nào không nên dùng /goal
- Tác vụ quá ngắn: dưới 3 lượt làm việc, chi phí thiết lập
/goalkhông đáng so với một prompt trực tiếp. - Mục tiêu cảm tính: "làm cho code dễ đọc" là thứ không kiểm chứng được và sẽ đốt token vô hạn.
- Công việc khám phá: khi chưa rõ cấu trúc codebase hay đích đến, hãy dùng hội thoại thông thường cho đến khi đường đi rõ ràng.
- Khi cần học hỏi:
/goaltối ưu cho kết quả (completion), không phải sự thấu hiểu (comprehension); bạn sẽ bỏ lỡ các bước xử lý trung gian nếu để máy tự chạy.