Prompt Đầu Tiên

3 Permission Modes: Claude Code hoạt động ở chế độ nào?

Trước khi gõ prompt, bạn cần chọn "chế độ làm việc" của Claude Code. Đây không phải chi tiết kỹ thuật nhỏ — đây là quyết định ảnh hưởng trực tiếp đến mức độ kiểm soát của bạn trong toàn bộ session.

Claude Code có 3 permission modes, toggle bằng Shift+Tab:

Default (Approval Mode)

Mỗi khi Claude muốn sửa một file hoặc chạy một lệnh, nó dừng lại và hỏi bạn. Bạn đọc, approve hoặc reject.

Khi nào dùng: Production branch. Codebase của khách hàng. Lần đầu dùng Claude trên một project mới. Bất kỳ khi nào cost của sai lầm cao.

Trade-off: Bạn phải approve liên tục. Đôi khi Claude xin phép đọc file — cũng phải approve. Nếu task gồm 20 bước, bạn sẽ approve 20 lần.

Auto Accept

Claude tự động edit và tạo file mà không hỏi. Nhưng khi cần chạy lệnh shell (chạy test, install package, restart server) — vẫn hỏi bạn.

Khi nào dùng: Sandbox environment. Dev branch đã tách riêng. Khi bạn đã hiểu rõ scope của task và muốn Claude chạy nhanh.

Trade-off: Nếu Claude hiểu sai yêu cầu, nó có thể edit nhiều file trước khi bạn nhận ra. Vẫn được bảo vệ bởi git — nhưng phải git diff để kiểm tra sau.

Plan Mode

Claude chỉ dùng read-only tools: đọc file, grep, tìm kiếm, phân tích. Nó không sửa bất kỳ thứ gì. Kết quả là một bản plan chi tiết với các bước cụ thể.

Sau khi bạn review và approve plan, Claude mới chuyển sang execute — thường là trong Auto Accept mode.

Khi nào dùng: Task đủ lớn để cần plan trước. Feature mới trên codebase bạn chưa rõ. Code review an toàn. Bất kỳ khi nào bạn muốn "align trước, code sau".

Trade-off: Chậm hơn cho task nhỏ. Plan mode không phù hợp khi bạn chỉ cần fix typo hay đổi màu button.

┌─────────────────────────────────────────────────────────────────┐
│              SHIFT+TAB — CYCLING PERMISSION MODES               │
└─────────────────────────────────────────────────────────────────┘

          ┌──────────────────────────────────────┐
          │         DEFAULT (Approval)            │
          │                                      │
          │  • Hỏi xác nhận TỪNG lần edit file  │
          │  • Hỏi xác nhận TỪNG lần chạy lệnh  │
          │  • An toàn nhất, chậm nhất           │
          │  • Best for: production codebase      │
          └──────────────────────────────────────┘
                          │
                    Shift+Tab
                          │
                          ▼
          ┌──────────────────────────────────────┐
          │         AUTO ACCEPT (Edit)            │
          │                                      │
          │  • Tự động approve edit/create file  │
          │  • Vẫn hỏi trước khi chạy commands  │
          │  • Nhanh hơn, ít interrupt hơn       │
          │  • Best for: sandbox / dev branch     │
          └──────────────────────────────────────┘
                          │
                    Shift+Tab
                          │
                          ▼
          ┌──────────────────────────────────────┐
          │           PLAN MODE                   │
          │                                      │
          │  • Read-only: đọc file, KHÔNG sửa   │
          │  • Claude phân tích → trả plan       │
          │  • Hỏi clarifying questions          │
          │  • Best for: task phức tạp, review   │
          └──────────────────────────────────────┘
                          │
                    Shift+Tab
                          │
                          ▼
                   (trở về Default)

Bảng so sánh: Khi nào dùng mode nào

Quy tắc nhanh: Task < 5 phút → Default hoặc Auto Accept. Task > 30 phút hoặc chạm nhiều file → Plan Mode trước.

Boris's 3-Task Framework

Boris Cherny chia mọi task Claude Code thành 3 loại, và mỗi loại có cách tiếp cận khác nhau:

Easy: One-shot task

Với task rõ ràng, nhỏ, risk thấp — chỉ cần prompt cụ thể và để Claude chạy.

Ví dụ thực tế: Bạn đang review PR trên GitHub. Thấy comment "add loading state cho button". Thay vì assign cho ai, bạn tag @Claude trong issue:

Claude đọc file, sửa, tạo commit. Done.

Medium: Plan trước, execute sau

Task đủ lớn để cần plan. Bạn cần align với Claude về approach trước khi nó bắt đầu viết code.

Workflow chuẩn (Boris's quote):

Bước 1: Shift+Tab → Plan Mode Bước 2: Viết prompt với đủ context Bước 3: Claude trả về plan chi tiết Bước 4: Review plan, comment nếu cần điều chỉnh Bước 5: Approve → Claude chuyển sang Auto Accept để execute

Hard: Bạn là người điều hướng

Task phức tạp, nhiều unknowns, cần judgment calls liên tục. Claude là pair programmer, nhưng bạn drive.

Mindset: Đừng viết prompt dài và để Claude làm một mình. Thay vào đó:

Anti-pattern hay gặp: Nhồi toàn bộ "refactor auth architecture" vào 1 prompt → Claude tự quyết định approach → kết quả không match với vision của bạn.

• Chia task thành subtask nhỏ hơn
• Làm từng subtask với Default mode
• Bạn review và quyết định hướng đi sau mỗi bước
• Dùng Plan Mode cho từng subtask nếu cần

┌─────────────────────────────────────────────────────────────────┐
│               BORIS'S 3-TASK FRAMEWORK                          │
├─────────────────┬───────────────────┬───────────────────────────┤
│   EASY          │   MEDIUM          │   HARD                    │
│   (One-shot)    │   (Planned)       │   (You drive)             │
├─────────────────┼───────────────────┼───────────────────────────┤
│ Fix typo        │ Add JWT refresh   │ Refactor auth architecture│
│ Change color    │ Dark mode toggle  │ Migrate database schema   │
│ Add comment     │ New API endpoint  │ Design new module từ đầu  │
│ Format file     │ Viết test suite   │ Debug race condition phức │
├─────────────────┼───────────────────┼───────────────────────────┤
│ Ai drive:       │ Ai drive:         │ Ai drive:                 │
│ Claude          │ Claude (sau plan) │ BẠN                       │
├─────────────────┼───────────────────┼───────────────────────────┤
│ Mode dùng:      │ Mode dùng:        │ Mode dùng:                │
│ Auto Accept     │ Plan Mode →       │ Default                   │
│ hoặc GitHub     │ Auto Accept       │ (từng bước review)        │
│ @mention        │                   │                           │
├─────────────────┼───────────────────┼───────────────────────────┤
│ Time estimate:  │ Time estimate:    │ Time estimate:            │
│ < 5 phút        │ 15-60 phút        │ 1+ giờ                    │
├─────────────────┼───────────────────┼───────────────────────────┤
│ Verification:   │ Verification:     │ Verification:             │
│ Nhìn kết quả   │ Review plan +     │ Review sâu từng bước,     │
│ là xong        │ run tests          │ bạn là decision maker     │
└─────────────────┴───────────────────┴───────────────────────────┘

Ví dụ thực chiến: Add Dark Mode Toggle (Step-by-step)

Đây là ví dụ Medium task theo đúng Plan Mode workflow. Task này từ video gốc của khóa học — được expand chi tiết để bạn có thể tự reproduce.

Tình huống

Bạn có một app React + Tailwind CSS đang chạy ở light mode. Product manager yêu cầu:

Ước tính nếu làm tay: nửa ngày. Với Plan Mode: khoảng 25 phút.

Bước 1: Vào Plan Mode

Trong terminal tại root directory của project:

Bấm Shift+Tab hai lần để vào Plan Mode. Thanh trạng thái dưới cùng hiển thị Plan Mode.

Bước 2: Viết prompt có đủ context và constraint

Prompt yếu (đừng làm thế này):

• Dark mode toàn app (background, text, card, border đều phải đổi)
• Toggle switch ở header để user tự chọn
• Preference phải lưu lại khi reload trang
• Contrast color phải đẹp, không xung đột với light theme hiện tại

$ claude

Bước 2: Viết prompt có đủ context và constraint

Prompt mạnh (làm thế này):

Thêm dark mode vào app của tôi.

Ví dụ thực chiến: Add Dark Mode Toggle (Step-by-step) (tiếp)

Bước 3: Claude trả về plan 7 bước

Claude đọc các file liên quan (không sửa gì — Plan Mode) và trả về plan:

Bước 4: Review plan và comment điều chỉnh

Bạn đọc plan. Có một điểm muốn điều chỉnh: không cần animation cho version 1 (cần ship hôm nay), và muốn update toàn bộ component luôn.

Gõ vào:

Plan: Implement Dark Mode Toggle

Step 1: Đọc tailwind.config.ts → identify màu hiện tại
        → propose dark palette tương phản tốt

Step 2: Thêm darkMode: 'class' vào tailwind.config.ts
        (switch từ media query sang class-based)

Step 3: Tạo DarkModeContext + useDarkMode hook
        → localStorage + OS preference detection

Step 4: Wrap App.tsx với DarkModeProvider
        → inject class 'dark' vào <html> element

Step 5: Tạo DarkModeToggle component (toggle switch UI)
        → Accessible: aria-label, keyboard nav

Step 6: Import DarkModeToggle vào Header.tsx
        → đặt trước user avatar

Step 7: Update global CSS classes trong các component hiện có
        → bg-white → bg-white dark:bg-gray-900
        → text-gray-900 → text-gray-900 dark:text-gray-100
        → (và các class card, border, input)

Câu hỏi: Step 7 sẽ update tất cả component files. Hiện có
~12 component. Bạn có muốn tôi update toàn bộ hay chỉ các
component trong layouts/ và pages/ trước?

My app needs dark mode implemented across the entire app.
Tech stack: React 18, Tailwind CSS v3, TypeScript.
App structure: src/components/ (reusable), src/pages/ (routes),
src/layouts/Header.tsx (header file chứa navigation).

Yêu cầu:
1. Dark mode áp dụng toàn app — background, text, card, border, input
2. Toggle switch đặt trong Header.tsx (góc phải, cạnh user avatar)
3. Dùng localStorage để lưu preference giữa các session
4. Respect prefers-color-scheme của OS nếu user chưa từng toggle
5. Tìm màu contrast phù hợp với light theme hiện tại — đọc
   tailwind.config.ts để hiểu color palette đang dùng

Constraint: KHÔNG dùng thư viện ngoài (next-themes hay tương tự).
Chỉ dùng Tailwind dark: variants + localStorage. Keep it simple.

Bước 4: Review plan và comment điều chỉnh

Bước 5: Approve plan

Claude xác nhận điều chỉnh và hỏi bạn có muốn chuyển sang execute không. Bạn confirm.

Bước 6: Claude execute với Auto Accept

Claude tự động chuyển mode (hoặc bạn Shift+Tab sang Auto Accept). Claude bắt đầu execute từng bước:

Bạn theo dõi. Mỗi file Claude edit hiện ra diff rõ ràng. Với Auto Accept, bạn không cần approve từng file — nhưng vẫn thấy được Claude đang làm gì.

Bước 7: Verify visual và run tests

Sau khi Claude xong:

• Đọc tailwind.config.ts → thêm darkMode: 'class'
• Tạo src/hooks/useDarkMode.ts
• Tạo src/context/DarkModeContext.tsx
• Update src/App.tsx
• Tạo src/components/DarkModeToggle.tsx
• Update src/layouts/Header.tsx
• Update 12 component files với dark: variants

Plan trông tốt. Một điều chỉnh:
- Skip animation/transition cho toggle và color switching ở V1
  (cần ship hôm nay, animation sau)
- Step 7: Update tất cả component, không chỉ layouts/pages

Ready to proceed.

Bước 7: Verify visual và run tests

Mở browser, test toggle. Kiểm tra:

Nếu có vấn đề gì (ví dụ một card bị quên update), bạn prompt thêm:

• Light mode: đúng màu cũ
• Dark mode: contrast đẹp, không có text khó đọc
• Reload: preference giữ lại
• OS dark mode: auto-detect đúng

npm run dev

Ví dụ thực chiến: Add Dark Mode Toggle (Step-by-step) (tiếp)

Kết quả

Thời gian (ước tính): khoảng 20-30 phút (bao gồm đọc plan + review + verify) So với làm tay: thường mất vài giờ vì phải touch hàng chục component Files touched: config file, utility mới, cùng toàn bộ component trong header Bugs: không có merge conflict — vì bạn đã review plan trước, Claude không sửa lệch

Card trong src/components/ProductCard.tsx chưa có dark mode.
Background vẫn white. Fix dark:bg-gray-800 cho card container.

Anatomy của prompt tốt

Mỗi prompt hiệu quả có 4 thành phần. Không nhất thiết phải có đủ 4 cho task nhỏ — nhưng task càng lớn, càng cần đủ:

Bảng đối chiếu: Prompt yếu vs Prompt mạnh

Cùng một task — khác biệt về kết quả:

Pattern quan sát được: Prompt mạnh luôn trả lời 3 câu hỏi ngầm:

• Claude cần đọc file nào để hiểu vấn đề?
• Constraint là gì (không được làm gì, phải dùng gì)?
• "Done" trông như thế nào?

┌─────────────────────────────────────────────────────────────────┐
│                  4 THÀNH PHẦN CỦA PROMPT TỐT                    │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  1. CONTEXT                                                     │
│     Cho Claude biết: file nào, folder nào, codebase area nào    │
│     "File src/auth/login.ts, function verifyPassword() dòng 42" │
│                                                                 │
│  2. CONSTRAINTS                                                 │
│     Style, library được/không được dùng, performance, deadline  │
│     "Không dùng thư viện ngoài. Giữ bundle size nhỏ."          │
│                                                                 │
│  3. SUCCESS CRITERIA                                            │
│     Kết quả trông như thế nào? Test nào phải pass?              │
│     "Dark mode toggle hiển thị ở header. Unit test pass."       │
│                                                                 │
│  4. "THINK HARD" TRIGGER (nếu task khó)                        │
│     Extended thinking — Claude suy nghĩ sâu hơn trước khi làm  │
│     Thêm "think hard" hoặc "think harder" vào cuối prompt       │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Anti-patterns: 5 sai lầm phổ biến nhất

Anti-pattern 1: Prompt quá broad — "Build me an app"

Claude không biết: React hay Vue? REST hay GraphQL? Auth cần không? Database là gì? Deploy ở đâu?

Claude sẽ đoán. Và đoán của Claude không match vision của bạn.

Cách đúng: Break down trước. Bắt đầu với 1 tính năng cụ thể nhất:

❌ "Xây cho tôi một app quản lý todo"

Anti-pattern 1: Prompt quá broad — "Build me an app"

Anti-pattern 2: Skip Plan Mode cho task > 30 phút

Bạn biết task này lớn — nhiều file, nhiều edge case — nhưng vẫn gõ thẳng prompt mà không dùng Plan Mode.

Claude bắt đầu viết. Sau 10 phút, bạn nhận ra Claude đang đi theo hướng khác với bạn muốn. Bạn interrupt. Claude phải rollback. Mất nhiều thời gian hơn nếu plan từ đầu.

Quy tắc: Task ước tính > 30 phút làm việc của bạn → Plan Mode trước, không ngoại lệ.

Anti-pattern 3: Auto Accept trên production branch

✅ "Tạo React component TodoList với mock data. Chưa cần backend.
    Dùng TypeScript, Tailwind CSS. Cần: hiển thị list, add item,
    toggle done. Không cần delete ở V1."

Anti-pattern 3: Auto Accept trên production branch

Auto Accept tốt cho sandbox. Trên production branch, một file bị edit sai có thể ảnh hưởng đến user thật. Luôn dùng Default mode (approval) khi đang làm việc trực tiếp trên main/production.

Cách đúng: Tạo feature branch trước, rồi mới dùng Auto Accept.

Anti-pattern 4: Không define "done" → Claude loop vô tận

❌ git checkout main
   claude  # rồi dùng Auto Accept ngay

Anti-pattern 4: Không define "done" → Claude loop vô tận

Claude sẽ optimize. Rồi optimize thêm. Rồi refactor. Rồi thêm tests. Rồi thêm docs. Không có điểm dừng tự nhiên.

Cách đúng: Luôn có success criteria rõ ràng:

❌ "Optimize toàn bộ codebase"

Anti-patterns: 5 sai lầm phổ biến nhất (tiếp)

Anti-pattern 5: "Hãy fix tất cả bugs"

✅ "Optimize queries trong src/api/products.ts.
    Mục tiêu: response time < 200ms (hiện tại ~800ms).
    Đo bằng cách chạy test suite. Dừng khi đạt target."

Anti-pattern 5: "Hãy fix tất cả bugs"

Đây vừa broad vừa nguy hiểm. "Fix bugs" có thể dẫn đến Claude thay đổi behavior mà bạn không expect, với scope không giới hạn.

Cách đúng: Một bug cụ thể, một prompt cụ thể. Hoặc nếu muốn scan, dùng Plan Mode để Claude liệt kê bugs trước, bạn chọn cái nào fix.

❌ "Fix tất cả bugs trong project"

Mẹo nâng cao

Mẹo 1: "Think hard" và extended thinking

Với bug khó, bài toán phức tạp, hoặc architecture decision quan trọng — thêm trigger extended thinking vào cuối prompt:

Ví dụ:

Extended thinking giúp Claude "viết nháp" quá trình suy luận trước khi đưa ra câu trả lời. Kết quả thường chính xác hơn đáng kể cho task phức tạp.

Mẹo 2: Reference file cụ thể bằng @filename

Thay vì mô tả file, dùng @:

Race condition trong payment processing — 2 request gửi đồng thời
cùng order ID đôi khi tạo 2 transaction. File: src/api/payment.ts.
Phân tích và đề xuất fix. Think hard trước khi trả lời.

Mẹo 2: Reference file cụ thể bằng @filename

Claude sẽ load đúng file đó vào context, không phải đoán.

Mẹo 3: Multi-line prompt — ngắn nhưng cụ thể

3 dòng đủ cho hầu hết task medium, nếu mỗi dòng đều cụ thể:

❌ "Đọc file auth trong thư mục src rồi..."
✅ "Đọc @src/auth/login.ts và @src/auth/middleware.ts, sau đó..."

Mẹo 3: Multi-line prompt — ngắn nhưng cụ thể

Không cần paragraph dài. Cụ thể > dài dòng.

Mẹo 4: Interrupt khi Claude đi sai hướng

Nếu Claude bắt đầu làm gì đó không đúng ý bạn — đừng để nó chạy hết rồi mới sửa. Bấm ESC ngay để interrupt.

Fix: LoginForm trong src/components/LoginForm.tsx không validate email format.
Constraint: Dùng regex RFC 5322, không install thư viện ngoài.
Test: Thêm 3 cases trong LoginForm.test.tsx (valid, invalid format, empty).

Mẹo 4: Interrupt khi Claude đi sai hướng

Interrupt sớm = tiết kiệm thời gian + tiết kiệm context window (xem Bài 2.5).

[Claude đang viết function 50 dòng theo pattern bạn không muốn]
→ Bấm ESC
→ "Dừng lại. Approach đó sẽ không work vì [lý do]. Hãy thử theo hướng này..."

Áp dụng ngay

Bài tập 1: Reproduce Dark Mode Demo (15 phút)

Dùng bất kỳ project React + Tailwind nào của bạn (hoặc tạo project mới bằng Vite):

Bước 1: Mở terminal tại root project, chạy claude

Bước 2: Shift+Tab → Plan Mode

Bước 3: Copy prompt Dark Mode từ bài này (có điều chỉnh cho tech stack của bạn)

Bước 4: Đọc plan Claude trả về — ghi lại:

Bước 5: Comment điều chỉnh (nếu có) → approve → Claude execute

Bước 6: Verify: toggle hoạt động, preference lưu lại, contrast đẹp

Kết quả cần đạt: Dark mode chạy được, toggle ở header, localStorage giữ preference.

Bài tập 2: Prompt yếu vs Prompt mạnh — so sánh kết quả (10 phút)

Chọn 1 task đơn giản trong project của bạn (ví dụ: thêm loading state vào một button).

Lần 1 — Prompt yếu:

Ghi lại: Claude làm gì? Hỏi lại bao nhiêu lần? Kết quả có match không?

Lần 2 — Prompt mạnh (cùng task):

• Claude đề xuất bao nhiêu bước?
• Claude hỏi clarifying question nào?
• Có bước nào bạn muốn điều chỉnh không?

Thêm loading state vào button.

Bài tập 2: Prompt yếu vs Prompt mạnh — so sánh kết quả (10 phút)

So sánh:

Bài học: Prompt mạnh thường nhanh hơn và ít token hơn, dù bản thân prompt dài hơn.

• Số lần Claude hỏi lại: ___ vs ___
• Token usage (xem ở cuối session): ___ vs ___
• Kết quả cần sửa lại: ___ lần vs ___ lần
• Thời gian tổng: ___ phút vs ___ phút

Thêm loading state vào component [YourButton] trong [path/to/file].
Khi prop isLoading=true: disable button + hiển thị spinner (Tailwind animate-spin).
Khi isLoading=false: trở về bình thường. Update TypeScript interface.
Test: Thêm 2 cases (loading/not loading) trong [YourButton.test.tsx].

Tóm tắt bài học

🎯 Prompt là brief, không phải command. Cung cấp đủ context (file, area), constraint (không được dùng gì, phải dùng gì), và success criteria (kết quả trông như thế nào).

🎯 3 permission modes — mỗi cái có use case riêng: Default (production, an toàn nhất), Auto Accept (sandbox, sau khi đã có plan), Plan Mode (task complex, cần align trước).

🎯 Boris's 3-task framework: Easy → one-shot với Auto Accept. Medium → Plan Mode trước, Auto Accept sau. Hard → bạn drive, Claude là pair programmer với Default mode.

🎯 Plan Mode là best practice cho task > 30 phút. Read-only, không risk. Claude hỏi clarifying questions, trả plan chi tiết. Bạn review và điều chỉnh trước khi approve.

🎯 Extended thinking với "think hard" / "think harder" / "ultrathink" khi task phức tạp — Claude suy nghĩ sâu hơn trước khi đưa ra câu trả lời, kết quả chính xác hơn đáng kể.