# Top 1% dùng Claude Code khác thế nào

[Simon Scrapes](https://homus.dev/speakers/simon-scrapes) · [Simon Scrapes](https://homus.dev/orgs/simon-scrapes)

> Mười thay đổi trong cách dùng Claude Code: brief thay plan mode, check và /goal, CLAUDE.md làm mục lục, skill chỉ từ lỗi thật, hook, subagent, projects.

Topics: Coding Agents, Skills, Context Engineering, Workflow

Canonical: https://homus.dev/talks/how-the-top-1-use-claude-code-differently

## 1. Plan mode không còn là lời khuyên số một

Simon mở đầu bằng một nhận xét: suốt một năm qua, gần như mọi lời khuyên về Claude Code đều nói cùng một điều, đó là hãy bắt đầu trong plan mode. Ngay cả người tạo ra Claude Code cũng nói vậy. Hồi tháng Một, Boris Cherny kể rằng phần lớn session của anh đều bắt đầu ở plan mode. Nhưng hai tuần trước video này, trên Hacker News, chính Boris lại nói plan mode không còn hữu ích nữa.

![Simon Scrapes nói trước camera trong phòng thu](https://homus.dev/photos/J9NQTYUP6k0-0020.jpg)

Simon Scrapes nói trước camera ở phần mở đầu, trước khi đi vào mười thay đổi trong cách dùng Claude Code.

Hai phát biểu đó cách nhau chín tháng, và theo Simon, trong chín tháng ấy cách Boris cùng nhóm 1% người dùng giỏi nhất làm việc với Claude đã thay đổi hoàn toàn. Vì vậy video đưa ra mười điều nhóm top 1% đang làm, để bạn có được setup tốt nhất và thôi tốn thời gian cho những lời khuyên đã cũ. Điều đầu tiên chính là thứ họ dùng thay cho plan mode.

Để hiểu vì sao, hãy nhìn lại plan mode thực sự đã làm gì. Nó chưa bao giờ thay đổi khả năng của Claude. Nó chỉ chèn thêm một reminder vào mỗi tin nhắn prompt, đại ý "bạn đang ở plan mode, xin đừng bắt đầu code vội". Trong bình luận trên Hacker News, Boris kể anh nghĩ ra ý tưởng này vào một tối Chủ nhật muộn, vì đã quá mệt với việc lần nào cũng phải nhờ Claude lên kế hoạch trước khi bắt tay vào build. Simon thấy khá buồn cười khi một ý tưởng nảy ra trong một tối Chủ nhật cuối cùng lại trở thành một phần gắn chặt với cách tất cả chúng ta làm việc với Claude Code mỗi ngày.

Ở thời điểm đó, plan mode thực sự rất có ích, vì các model cũ hơn, hãy nghĩ lại Sonnet 4.6 và những bản Opus đời đầu, đều có xu hướng lao thẳng vào làm việc ngay. Đó là một giới hạn của model. Nhưng với các model mới hơn, Boris đơn giản là thôi dùng nó, vì giờ đây việc lên kế hoạch diễn ra ngay trong lúc model làm việc.

## 2. Thay plan mode bằng một brief ba dòng: task, guardrails, done

Vậy Boris làm gì thay thế? Như anh giải thích ở YC Startup School, anh mô tả task, mô tả những guardrails bao quanh task đó, mô tả thế nào là xong, tức definition of done, rồi để model tự tìm cách làm.

Simon lấy ví dụ một bản báo cáo khách hàng hằng tuần (weekly client report). Brief cho việc đó có thể chỉ gồm ba dòng. Task: làm báo cáo tuần này từ file export của CRM. Guardrails: không sửa template đã đặt sẵn, và không email cho ai cả. Definition of done: mọi con số khớp với file export.

![Sơ đồ ba ô Task, Guardrails, Done nối tới nội dung của một weekly client report](https://homus.dev/photos/J9NQTYUP6k0-0410.jpg)

Brief ba dòng cho weekly client report: Task là "This week's report from the CRM export", Guardrails là "Don't amend the template, don't email anyone", Done là "Every figure matches the export".

Thay vì đọc một bản kế hoạch trước khi task bắt đầu, giờ bạn kiểm tra những gì nó đã làm sau khi xong. Đó là lời khuyên hiện tại. Với những thay đổi lớn hơn, Boris nhờ Claude vẽ một diagram, hoặc thậm chí làm một demo tương tác về những gì nó đã thay đổi. Và ngay hôm trước video, Claude cũng công bố khả năng tích hợp sẵn để tạo live dashboard và animated explainer, nên lấy output tương tác kiểu này giờ còn dễ hơn.

Cách làm Simon đề xuất: khi task xong, bạn yêu cầu nó một trang hình ảnh (one-page visual) mô tả nó đã làm gì và nó đã giả định những gì trong lúc làm task đó.

Từ đây Simon bắt đầu dựng một bức tranh sẽ lớn dần qua cả video. Bên trái là bạn, và thứ duy nhất bạn viết là brief. Claude làm phần việc, và thứ quay về là output cùng trang explainer một trang kia. Nghĩa là giờ bạn chủ yếu kiểm tra kết quả, chứ không còn lên kế hoạch chi tiết từ trước nhiều như trước nữa.

Bức tranh Simon bắt đầu dựng: bạn chỉ viết brief, Claude làm việc, rồi trả về output kèm một trang giải thích để bạn kiểm tra kết quả thay vì duyệt kế hoạch.

## 3. Đừng chỉnh effort level, cũng đừng viết "think hard"

Brief đã nói rõ phải làm gì và guardrails là gì. Nhưng nhiều người vẫn cố điều khiển mức Claude suy nghĩ về task. Lời khuyên mới là bỏ qua chuyện đó hoàn toàn.

Có thể bạn còn nhớ năm ngoái người ta bảo phải viết những cụm như "think", "think hard", "think harder" hay "ultrathink", và mỗi cụm cho Claude một thinking budget lớn hơn. Nhưng giờ Claude Code đọc "think hard" đơn giản như một phần của prompt, như những chữ bình thường. Trên màn hình, Simon đặt cạnh nhau hai thời điểm: "Last year" với thinking budget, và "Now" với dòng "think hard about why the test fails" chỉ còn là chữ trong prompt.

Việc chỉnh mức suy nghĩ đã thành một setting riêng mà bạn có thể nhận ra là effort level. Mỗi model có một mức được khuyến nghị. Opus 5.5 được khuyến nghị ở medium, và Anthropic nói rằng ở mức medium, nó ngang hoặc vượt Opus 5 ở mức high cho công việc coding và knowledge work. Nói đơn giản, mặc định bây giờ đã làm thay điều bạn từng tự làm, với ít bước hơn và ít token hơn.

Thay đổi Simon mô tả: từ khoá suy nghĩ không còn mở thêm thinking budget, việc này giờ do setting effort level đảm nhận, và mức khuyến nghị đã đủ cho phần lớn task.

Vì vậy với đa số task, lời khuyên là cứ để nguyên, coi như bớt một thứ phải nghĩ, giữ ở effort level được khuyến nghị. Simon nói anh sẽ không ngạc nhiên nếu trong tương lai gần, Anthropic bỏ hẳn setting này và để nó tự chạy ở phía sau. Tóm lại, ý chính ở đây là: hãy tin vào setup của Claude.

## 4. Cho Claude một cách để tự kiểm chứng công việc

Hai điều tiếp theo nói về cách Claude chứng minh rằng nó đã thực sự làm xong task bạn giao. Có một ý từ bài đăng tháng Một của Boris vẫn còn cực kỳ đúng: cho Claude một cách để verify công việc của nó sẽ tăng chất lượng kết quả cuối lên 2 đến 3 lần. Và docs của Anthropic giờ đặt điều này làm mẹo đầu tiên.

![Hai trang web cạnh nhau: bài 'The Most Important Tip' trích Boris Cherny và trang Best practices của Claude Code Docs](https://homus.dev/photos/J9NQTYUP6k0-0343.jpg)

Bên trái, một bài blog trích lời Boris Cherny: có vòng feedback để tự verify thì Claude cho kết quả tốt hơn 2-3x. Bên phải, trang Best practices for Claude Code với mục "Give Claude a way to verify its work": một check Claude chạy được là khác biệt giữa session bạn phải ngồi xem và session bạn có thể bỏ đi.

Đúng như docs viết, một check mà Claude tự chạy được chính là khác biệt giữa một session bạn phải ngồi canh và một session bạn có thể rời đi. Nếu bạn muốn những setup tự động hơn, chỉ cần giám sát, thì điều này sẽ là then chốt.

Để làm được, bạn sẽ không bảo Claude "double check" công việc trong prompt. Hướng dẫn cho Opus 5 nói rằng model đã tự kiểm tra công việc của nó mà không cần được nhắc. Vì vậy dòng đó về cơ bản chỉ thêm chi phí mà không cải thiện kết quả. Việc bạn cần làm là luôn đưa cho nó những tiêu chí có thể trả về pass hoặc fail.

## 5. Biến definition of done thành một check chạy được

Ví dụ, Simon yêu cầu Claude viết một script nhỏ tên `check-report`, dùng để đối chiếu với tiêu chí done của ví dụ weekly client report ở trên. Script về cơ bản kiểm tra mọi con số so với file export, và kiểm tra mọi section trong template đều đã được điền. Đó là tất cả những gì script `check-report` xác nhận.

![File check-report: một script Python ngắn so từng con số trong báo cáo với file CRM export](https://homus.dev/photos/J9NQTYUP6k0-0443.jpg)

Script `check-report` trên màn hình: nạp báo cáo tuần và file `crm-export.csv`, rồi duyệt từng con số và assert rằng nó khớp với export, đúng như dòng chú thích "every figure matches the export".

Các dòng đầu của script hiện trên màn hình như sau:

```
#!/usr/bin/env python3
# every figure matches the export
report = load("weekly-report")
export = load("crm-export.csv")
for name, value in report.figures():
```

Cách nó vận hành: giả sử ở lần chạy đầu, check fail ở một con số không khớp với export. Claude sẽ quay lại sửa chỗ đó, chạy lại check, và khi pass thì mới cho bạn xem output. Nghĩa là với tư cách người dùng, bạn chỉ đọc bằng chứng, chứ không phải tự mình chạy kiểm tra trên output.

Cách làm cụ thể là nhìn lại definition of done, chính cái dòng trong brief của bạn, và biến nó thành một check mà Claude chạy được. Simon lưu ý check không nhất thiết phải là một script code chạy được. Nó có thể là tài liệu brand voice mà Claude dùng để đối chiếu bản nháp. Nhưng check càng deterministic thì càng bắt được nhiều lỗi.

Vòng kiểm chứng trong ví dụ của Simon: fail thì Claude tự sửa và chạy lại, chỉ khi pass mới đưa output kèm bằng chứng cho bạn.

Như vậy, giờ Claude tự làm nhiều phần việc hơn và chỉ trao cho bạn bằng chứng rằng nó đã làm đúng. Nhưng điều này chỉ có ích khi Claude có cách tiếp tục làm cho tới khi pass các check. Nếu không, bạn sẽ ngồi đó gõ "continue" liên tục để nó sửa phần bằng chứng của chính nó.

## 6. /goal và cái bẫy của judge Haiku

Điều đó dẫn tới `/goal`. Về cơ bản, `/goal` gõ "continue" thay cho bạn. Simon hy vọng trong tương lai mình thậm chí không cần viết lệnh này nữa, mà chỉ cần đặt tiêu chí là muốn nó tiếp tục cho tới khi đã xác nhận được definition of done, đơn giản vậy thôi. Nhưng hiện tại, chúng ta dùng `/goal`.

Có một điểm cần biết về cách nó hoạt động hôm nay, và Simon nói điểm này rất quan trọng. Sau mỗi turn, một model nhỏ riêng biệt như Haiku đọc goal của bạn và quyết định xem điều kiện đã đạt chưa. Nếu chưa, Claude sẽ chạy thêm một turn nữa để cố đạt goal đó.

![Sơ đồ: Claude ở turn 3 qua lại với Judge Haiku; Judge chỉ nối tới chat, không tới terminal hay report.md](https://homus.dev/photos/J9NQTYUP6k0-0543.jpg)

Cách `/goal` chấm điểm: Claude (turn 3) đi vòng qua Judge chạy Haiku, và Judge chỉ nhìn thấy chat; hai đường tới `$ terminal` và `report.md` bị gạch chéo.

Cái bẫy là judge, tức agent Haiku kia, không tự chạy lệnh hay đọc file. Nó chỉ được đưa cuộc chat bạn đã gửi và output của Claude. Vì vậy nếu goal được định nghĩa kém, ví dụ definition of done chỉ là "báo cáo đã xong", thì về cơ bản nó sẽ kết thúc quá sớm. Nó sẽ nghĩ đã đạt tiêu chí done trong khi thực tế chưa.

## 7. Viết một goal tốt: một end state, cách chứng minh, giới hạn turn

Vì thế goal phải thật rõ ràng và tường minh, để nó chính là cái check bạn đã tạo ở phần trước. Anthropic nói một goal tốt có một end state duy nhất, nói cách chứng minh end state đó, và nói những gì không được thay đổi. Nó cũng nên có một giới hạn số turn để không chạy mãi.

![Ô nhập lệnh đang gõ '/goal check-report script p', chế độ Code, model Opus 5.5 Medium](https://homus.dev/photos/J9NQTYUP6k0-0613.jpg)

Simon gõ goal của mình trong ô nhập ở chế độ Code, với model Opus 5.5 ở mức Medium: lệnh mở đầu bằng `/goal` và nhắc tới script check-report.

Goal của Simon cho ví dụ này rất đơn giản. Anh đọc nó như sau: `/goal`, script check-report pass và bạn cho tôi xem output; template không bị thay đổi; hoặc dừng sau 15 turn. Bây giờ Claude có thể đi tiếp trên con đường kiểm chứng đó, lặp đi lặp lại cho tới khi đạt tiêu chí của bạn, và tiêu chí đó được viết sẵn trong script check-report.

Cấu trúc goal theo Anthropic mà Simon áp vào ví dụ weekly client report.

Như vậy bạn giải phóng thêm thời gian vì không phải giám sát nó. Bạn không phải ngồi gõ "continue" mỗi lần, mà chỉ cần xác nhận output đúng như mong đợi. Giờ các agent đang chạy vòng lặp quanh bạn, và việc tiếp theo là bảo đảm những chỉ dẫn nền trong CLAUDE.md không đi ngược lời khuyên mới nhất của Anthropic.

Trước khi sang phần đó, video có một đoạn quảng cáo cho khoá học sắp ra của chính Simon về việc giao bớt công việc hằng ngày cho Claude, Codex và các công cụ AI khác.

## 8. CLAUDE.md là trang mục lục của workspace

Simon muốn chắc rằng nền móng của setup vững, vì mọi thứ nói tới từ đầu video đều dựa trên nó. Khi Opus 5 ra mắt gần đây, Anthropic đã làm một việc mà anh gọi là điên rồ: họ xoá hơn 80% chỉ dẫn của chính Claude Code, vì phần lớn chỉ dẫn đó tồn tại để sửa những thứ mà các model cũ hay làm sai.

Docs của Anthropic bảo giữ CLAUDE.md dưới 200 dòng, và đó không phải lời khuyên mới, vì file dài hơn tốn nhiều chi phí hơn và ít được làm theo hơn. Trên màn hình là đoạn docs "Keep your files short, organized, and consistent", với dòng được tô đậm: mục tiêu dưới 200 dòng cho mỗi file CLAUDE.md, file dài hơn tiêu nhiều context hơn và giảm mức tuân thủ.

Nhưng Simon chia sẻ cách anh bắt đầu nghĩ về CLAUDE.md, và cho rằng cách nghĩ này có thể hữu ích cho bạn. Với anh, CLAUDE.md giờ là trang mục lục (contents page) của workspace. Nó làm đúng việc mà SKILL.md làm bên trong một thư mục skill.

Có bốn thứ vẫn nên nằm trong CLAUDE.md:

- Các tool và lệnh mà Claude không thể tự đoán ra.

- Bất cứ việc gì bạn làm khác với cách Claude vẫn làm theo mặc định.

- Có liên quan tới điều trên: những "gotcha" mà Claude đã làm sai hơn một lần.

- Những ranh giới (boundaries) đã nói ở đầu video, ví dụ "chỉ viết bản nháp email".

Mọi thứ khác trong CLAUDE.md về cơ bản trở thành một pointer, một tham chiếu tới file khác, nơi Claude có thể vào lấy thêm thông tin khi cần.

CLAUDE.md theo cách nhìn của Simon: bốn loại nội dung luôn đúng, còn lại là pointer tới các file như report-template.md, client-brief.md, export-rules.md mà Claude chỉ mở khi cần.

## 9. Ba luật cho pointer và lệnh /doctor prompt-audit

Với chính các pointer, có ba luật cần theo.

**Luật một: viết tham chiếu dưới dạng path, không phải import.** Nếu bạn dùng ký hiệu @, toàn bộ file sẽ được nạp vào mọi session. Thay vào đó, hãy viết path trong dấu backtick kèm thời điểm nên mở nó, ví dụ "đọc client brief trước mọi việc liên quan tới khách hàng". Như vậy Claude biết chỉ mở file đó vào đúng lúc và nạp nó vào context.

![File CLAUDE.md cho Weekly client report, dòng @docs/client-brief đang bị gạch bỏ](https://homus.dev/photos/J9NQTYUP6k0-0823.jpg)

File CLAUDE.md mẫu cho weekly client report: chạy `check-report` trước khi coi báo cáo là xong, chỉ viết nháp và không bao giờ email khách, không sửa `docs/report-template.md`. Dòng import `@docs/client-brief.md` ở cuối đang bị gạch bỏ để thay bằng path thường.

Nội dung file CLAUDE.md trên màn hình, trước khi dòng import bị gạch:

```
# Weekly client report

Run `check-report` before you call a report done.
Draft only. Never email a client.
Never edit `docs/report-template.md`.

@docs/client-brief.md
```

**Luật hai: trỏ tới mọi file ngay từ CLAUDE.md.** Anthropic nói một file chỉ được với tới qua một file khác, tức là lồng nhau, sẽ chỉ được xem trước 100 dòng đầu. Khi đó có thể bạn bỏ lỡ chính chi tiết cần có trong các file tham chiếu.

**Luật ba: file nào dài hơn 100 dòng thì có một mục lục ở đầu.** Anthropic đặt luật này cho file skill, nhưng Simon áp nó cho mọi file mà mục lục trỏ tới, vì với file nào cũng vậy, bạn sẽ bị đọc dở chỉ 100 dòng đầu.

Simon thừa nhận đây là khá nhiều luật. Bạn có thể tự sửa, hoặc đơn giản là chạy `/doctor prompt-audit`. Lệnh này kiểm tra CLAUDE.md, skills và rules của bạn để tìm những chỉ dẫn viết cho model cũ, những path không còn tồn tại, và những file mâu thuẫn với nhau.

![Đoạn docs 'Audit your instruction files' với cụm 'run /doctor prompt-audit' được tô màu](https://homus.dev/photos/J9NQTYUP6k0-0903.jpg)

Đoạn docs "Audit your instruction files": chạy `/doctor prompt-audit` trong một session để Claude tìm chỉ dẫn viết cho model cũ, tham chiếu tới file hoặc lệnh không tồn tại, và các file mâu thuẫn nhau; bạn nhận một báo cáo kèm đề xuất sửa, và không file nào đổi cho tới khi bạn bảo Claude áp dụng.

Nó sẽ không thay đổi gì cho tới khi bạn xác nhận và đồng ý. Sau đó nó cắt mọi thứ Claude vốn đã tự làm khỏi các chỉ dẫn, và biến phần còn lại thành một mục lục, một index với nhiều pointer và tham chiếu tới các file khác.

Quay lại bức tranh đang dựng: CLAUDE.md nằm bên dưới Claude, vì nó được đọc trước mọi thứ khác và là nền móng của mọi công việc bạn làm. Hãy nghĩ về nó như cái index, và mỗi mũi tên đi ra từ CLAUDE.md trỏ tới một file mà Claude chỉ mở khi cần. Đó là progressive disclosure: chỉ nạp context cần thiết vào đúng lúc cần. Bản thân CLAUDE.md chỉ chứa thông tin luôn luôn đúng.

## 10. Chỉ đưa vào skill những gì Claude làm sai

Quay lại weekly client report: cách bạn thực sự chạy báo cáo đó sẽ được đưa vào một skill, nếu và chỉ nếu Claude không làm đúng được ngay lần đầu khi chưa có gì hỗ trợ. Simon kể đây là điều đã làm anh vấp hết lần này tới lần khác khi build skill. Phần lớn chúng ta lên quy trình cho skill trong đầu, rồi prompt để build skill trước khi Claude kịp thử làm việc đó một lần mà không có skill nào.

Nhưng hướng dẫn về skill của Anthropic bảo làm ngược lại, nhất là bây giờ khi model đã giỏi hơn rất nhiều. Bước đầu tiên họ ghi là hoàn thành task mà không có skill.

Trên màn hình là đoạn "Creating a new Skill", bước 1 "Complete a task without a Skill": làm một vấn đề cùng Claude bằng prompt bình thường; trong lúc làm, bạn sẽ tự nhiên cung cấp context, giải thích sở thích và chia sẻ kiến thức về quy trình; hãy để ý những thông tin bạn phải đưa đi đưa lại.

Nghĩa là bạn làm việc đó với Claude như thường, rồi chạy nó trên các task thật mà không có skill, và ghi lại chỗ nó thực sự làm sai. Khi đó phần skill chỉ giải quyết những vấn đề có thật, thay vì ghi chép những vấn đề tưởng tượng. Bạn không build skill cho một quy trình nữa, mà gần như reverse engineer skill để xử lý những thứ Claude không tự lo được khi chưa có gì.

Simon nói chắc bạn đã thấy một chủ đề lặp lại trong video, về những gì thay đổi suốt sáu tháng qua: để Claude yên làm việc của nó cho tới khi nó mắc lỗi. Rồi mới thêm hạ tầng và các file như skill để hỗ trợ nó tới đích. Đội của Anthropic cũng nói phần lớn những skill tốt nhất của họ bắt đầu chỉ với vài dòng và một gotcha duy nhất, sửa một điều mà Claude làm khi chưa có gì. Cách nhìn này coi skill là danh sách những thứ Claude đã làm sai, chứ không còn là cẩm nang cho cả quy trình.

Còn một cách khác: bây giờ bạn có thể record một skill trong desktop app, nó làm cùng việc đó bằng cách xem bạn làm. Khi Simon tự chạy thử trên một automation DM cho Instagram, nó nhận ra những chỗ anh làm sai trong lúc demo và ghi lại chính những chỗ đó. Anh nhớ skill lúc ấy nhỏ tới bất ngờ, và giờ anh hiểu chính xác vì sao: nó chỉ ghi lại những phần Claude không tự hiểu được.

Quy trình Simon tóm lại: skill sinh ra từ những lần Claude làm sai thật, rồi kiểm lại trên đúng model sẽ chạy nó.

Tóm lại, bạn chọn quy trình muốn tự động hoá, chạy nó không có skill trên một model tốt, và chỉ ghi lại những lần bạn phải sửa, những lần sửa đưa nó tới definition of done của bạn. Sau đó hãy chắc rằng bạn chạy nó trên đúng model bạn định dùng cho mọi lần sau, vì các model khác nhau sẽ cho kết quả khác nhau và cần nhiều hay ít chỉ dẫn hơn.

Đó là phần còn lại của hạ tầng. Trên bức tranh, skills nằm cạnh CLAUDE.md. CLAUDE.md là những gì luôn đúng về setup, về workspace hay doanh nghiệp của bạn. Còn một skill là những gì đúng với một quy trình cụ thể, và phần lớn chỉ là những chỗ cần sửa.

## 11. Thư viện skill: 7 trên 9 không hơn một file giả

Tiếp tục với skill, Simon nói nhanh về các thư viện skill. Anh thấy những gói skill nổi tiếng được chia sẻ liên tục và nhận hàng nghìn sao. Nhưng một developer đã thử nghiệm chín gói như vậy vào cuối tháng Chín. Người đó chạy 450 lần trên Opus 5.5, và chỉ hai trong chín gói làm tốt hơn một file giả (dummy file) có cùng độ dài, điều mà Simon nói thẳng là rất đáng suy nghĩ.

![Biểu đồ 'Cost of each skill relative to a same-length placebo' cho chín gói skill trên Claude Code và ba gói trên Codex](https://homus.dev/photos/J9NQTYUP6k0-1212.jpg)

Biểu đồ chi phí của từng gói skill so với một placebo cùng độ dài (dưới 1 nghĩa là skill rẻ hơn). Ở phần Claude Code, chỉ ponytail (0.88) và agent-skills (0.95) được ghi "beats placebo"; các gói còn lại như superpowers, caveman, compound-engineering hay karpathy ghi "no better than placebo", còn planning-with-files ghi "worse than placebo".

Đây là một vài trong những skill cho coding agent được gắn sao nhiều nhất. Vậy mà context bên trong chúng không làm output tốt hơn trong bảy trên chín kịch bản.

## 12. Dọn thư mục skill bằng plugin eval và /skill-doctor

May là đội Claude Code đã nhận ra điều này và giờ có sẵn một cách để kiểm tra. Bạn có thể chạy `claude plugin eval`, lệnh này chạy cùng một task có skill và không có skill, rồi chấm điểm dựa trên khác biệt. Bạn thấy được skill so với không skill: Claude Code làm task bạn cần tốt tới đâu trong mỗi trường hợp.

![Trang docs plugin-evals của Claude Code, mục The no-plugin baseline với câu được tô màu](https://homus.dev/photos/J9NQTYUP6k0-1243.jpg)

Trang plugin evals trong Claude Code Docs, mục "The no-plugin baseline": các lượt chạy của một case được lặp lại khi không nạp plugin, bạn nhận hai điểm WITH và W/OUT, và hiệu số giữa chúng là phần plugin đóng góp.

Như tên gọi, công cụ này chủ yếu được thiết kế cho plugin, nhưng bạn có thể chỉnh để dùng cho từng skill riêng lẻ. Simon đã làm việc đó cho thành viên trong cộng đồng của anh.

Điều nó cho bạn biết là: nếu hai điểm số ra bằng nhau, skill đó chỉ đang tốn thêm token của bạn, tức nó chỉ là đồ trang trí. Chưa kể nó còn làm thư mục của bạn thêm bừa bộn.

Để dọn skill, Simon chạy `/skill-doctor` trước. Lệnh này cho thấy mỗi skill tốn bao nhiêu và được dùng thường xuyên tới đâu. Rồi anh bỏ những skill không bao giờ dùng. Tiếp đó anh chạy plugin eval trên các skill còn lại và cắt thêm được vài skill nữa trong thư mục skills.

Cách Simon dọn thư viện skill của mình: đo chi phí và tần suất, bỏ skill bỏ xó, rồi eval phần còn lại để cắt những skill không tạo khác biệt.

Simon nói điều này hoàn toàn hợp lý khi nghĩ tới việc model giờ giỏi thế nào. Chỉ là phần lớn chúng ta chưa sửa lại thư viện cũ, với cả đống skill đã cài. Nếu chỉ mang về một điều từ video này, anh khuyên hãy xử lý việc đó ngay hôm nay.

## 13. Luật bắt buộc phải nằm trong hook, không phải chữ in hoa

Tới đây, bạn đã có gần như toàn bộ hạ tầng then chốt. Nhưng còn ba điều sẽ thực sự tăng tốc khối lượng công việc bạn làm được mà vẫn giữ chất lượng output cao.

Có lẽ bạn đã nhận ra rằng việc thêm những chữ như "IMPORTANT" hay "YOU MUST" viết hoa vào rules, vì Claude cứ làm sai, không còn hiệu quả nữa. Trên màn hình, Simon so một dòng CLAUDE.md theo kiểu hướng dẫn tháng Tư 2025: dòng "run tests before committing" được đổi thành "IMPORTANT: YOU MUST run tests before committing".

Nếu bạn thực sự muốn bảo đảm một điều sẽ xảy ra, bạn cần viết hook tốt. Với ai chưa dùng, hook chỉ là những script nhỏ chạy được, chạy vào một thời điểm bạn định sẵn. Thời điểm đó có thể là ngay trước khi Claude dùng một tool, hay mỗi lần nó dùng tool. Hook sẽ chạy vào lúc đó và hoàn toàn deterministic, không tốn token AI nào và chạy bất kể thế nào.

Trong ví dụ client report, nếu có rule "không bao giờ email khách hàng", bạn về cơ bản xoá dòng đó đi và biến nó thành một hook chặn mọi email gửi tới khách. Hook đó bảo đảm kết quả, vì nó chạy bất kể thế nào trên điều kiện bạn đặt.

Cách Simon rà CLAUDE.md: mỗi dòng viết hoa hoặc là thừa (Claude tự làm rồi), hoặc là luật cứng phải chuyển sang hook.

Vậy hãy rà file CLAUDE.md, tìm mọi thứ viết hoa. Mỗi dòng như vậy hoặc là thứ Claude vốn đã làm, nên xoá đi, hoặc là thứ tuyệt đối không được xảy ra, nên trở thành hook. Quay về lời khuyên gốc của Boris, đây chỉ là những guardrails được gắn vào các hành động mà Claude có thể làm thay bạn.

## 14. Để Claude tự dựng agent team, bạn chỉ đặt giới hạn

Hai điều cuối nói về việc bạn có thể đứng xa công việc tới mức nào, để mọi thứ chạy mà không cần bạn. Ví dụ: bạn có nên dùng subagent và agent team không, hay giờ nên giao luôn quyết định đó cho Claude?

Đầu năm nay, người ta build agent team bằng tay, với orchestrator, file agent và routing. Có một lead agent, và bạn có thể tương tác với từng subagent, giao task cho nó. Nhưng hướng dẫn cho Opus 5 giờ nói model này giao việc cho subagent dễ dàng hơn mọi model trước đó. Với những việc nhỏ, Anthropic nói điều đó về cơ bản chỉ nhân chi phí và thời gian lên. Lời khuyên của họ là đặt giới hạn số subagent được thêm vào, để không liên tục thêm ngày càng nhiều subagent cho một task đơn giản.

![Đoạn docs 'Controlling subagent spawning' về Claude Opus 5](https://homus.dev/photos/J9NQTYUP6k0-1458.jpg)

Đoạn "Controlling subagent spawning": Claude Opus 5 giao việc cho subagent dễ hơn các model trước; ủy quyền có lợi với những mảng việc độc lập và đủ lớn, nhưng nhân chi phí và thời gian khi dùng cho task nhỏ, nên hãy hướng dẫn rõ khi nào nên ủy quyền hoặc đặt giới hạn deterministic cho số agent được tạo.

Nói đơn giản, Claude sẽ tự phán đoán thay bạn về team cần dựng, team cần bao nhiêu thành viên, task nào cần giao cho thành viên nào. Claude làm việc đó. Còn việc của bạn bây giờ là đặt team được phép lớn tới đâu, các ranh giới, các guardrails. Điều đó giúp nó không tốn quá nhiều hoặc làm quá tay cho một task không cần tới.

Simon đã thử đưa cho Claude một brief nặng về research mà không có sẵn file agent nào. Trên task panel, bạn thấy mặc định nó tự dựng các helper của mình. Nó hiểu nên đi theo workflow nào, giao việc cho những subagent nào để hoàn thành task.

## 15. Ngoại lệ cho subagent, và Ultracode

Có thể bạn nhớ hồi người ta nói về Ultracode như một effort level. Ultracode thực ra tạo ra nhiều nhóm subagent, và có thể dựng thêm subagent mãi vào một team cho một task riêng lẻ.

Có một lưu ý với việc để Claude tự phân bổ subagent. Nếu bạn đang làm một skill vì Claude có giới hạn khi chưa có gì hỗ trợ, và trong đó có một bước như research lớn, hay một bước kết nối tới MCP hoặc connector, thì bạn nên bảo nó làm bước đó trong một subagent, để cuộc chat chính sạch sẽ cho phần việc thực sự quan trọng. Nhớ lại lý do ta tính tới subagent ngay từ đầu, một trong các lý do là giữ main context sạch. Vì vậy giao những task đó cho subagent có thể rất mạnh.

Ngoại lệ Simon nêu: trong một skill, các bước nặng như research hay gọi MCP nên chạy trong subagent để main context không bị lấp đầy.

Tóm lại, Claude sẽ thêm bất kỳ helper nào nó cần cho một quy trình, nó tự dựng chúng, nhưng bạn có thể kiểm soát giới hạn trong config.

## 16. Chạy mà không cần bạn: projects, routines và MCP events

Điều cuối cùng là chạy mọi thứ mà bạn thậm chí không cần nghĩ tới. Giấc mơ ngồi trên bãi biển với ly piña colada trong khi agent điều hành cả doanh nghiệp thì chắc chắn chưa tới. Nhưng điều cuối này đưa ta tới gần hơn. Trên màn hình là một nhân vật hoạt hình nằm thư giãn trên ghế bãi biển với ly cocktail, rồi bật dậy hoảng hốt khi một thông báo hiện ra.

Một trong những cập nhật mới nhất của Claude Code, projects, là một bước đúng theo hướng đó. Project giờ là một cuộc hội thoại liên tục, tự mở các thread của nó, trong khi trước đây bạn phải tự mở từng session, và nó tiếp tục chạy cả khi máy bạn đã tắt. Nó chạy nhiều agent song song để hoàn thành một task cụ thể.

![Sơ đồ You nối tới Coordinator, Coordinator mở tám thread trên Cloud, mỗi thread một branch](https://homus.dev/photos/J9NQTYUP6k0-1703.jpg)

Minh hoạ cách một project hoạt động: bạn nói với một Coordinator, Coordinator tách việc thành các thread chạy trên Cloud như "Optimize images", "Lazy-load scripts", "Split the JS bundle", mỗi thread có branch riêng dạng `claude/...`.

Lý do điều đó mạnh là khi bạn có context tách biệt cho từng project, kết hợp với task chạy theo hẹn giờ hoặc theo sự kiện, ví dụ một việc được thêm vào to-do list, hoặc một contact hay lead mới được thêm vào CRM, thì bạn có thể dựng routines trong Code, hoặc scheduled tasks trong chế độ Chat hay Cowork. Những thứ đó có thể xử lý công việc mà bạn không cần có mặt.

Simon nói đây chính là cách anh sản xuất toàn bộ carousel và shorts cho Instagram bây giờ. Tất cả những gì anh cần làm là bấm approve trong một giao diện anh tự build. Anh có nhắc rằng cách làm này được chia sẻ cho thành viên trong cộng đồng trả phí của anh.

Điều này càng quan trọng hơn khi Codex vừa công bố MCP events cho plugin, nghĩa là giờ các app đã kết nối có thể kích hoạt Codex chạy khi có chuyện gì đó xảy ra. Trên màn hình là trang recap DevDay 2026 của OpenAI, mục "MCP events for plugin automations": hỗ trợ cho đặc tả MCP Events đề xuất, để plugin có thể khởi động automation khi có sự kiện trong một app đã kết nối, ví dụ bảo ChatGPT theo dõi task mới trên một project board rồi đọc tài liệu liên quan và soạn kế hoạch ngay cả khi bạn vắng mặt.

Đích Simon hướng tới: gói mọi thứ trong video thành một quy trình tự chạy theo lịch hoặc sự kiện, và bạn chỉ còn việc kiểm output.

Về cơ bản, ta đang đóng gói mọi thứ đã nói trong video thành một gói để chạy. Khi đó bạn tập trung vào quy trình tiếp theo muốn tự động hoá, vì tất cả những gì cần làm với quy trình đã chạy mà không có bạn là xác nhận output của nó. Simon nhắc lại một lần rằng cộng đồng của anh giúp mọi người giao quy trình đầu tiên cho AI theo cách này.

Anh kết thúc bằng lời hẹn: video tiếp theo sẽ đi qua mọi cập nhật trong năm qua dành riêng cho việc build skill. Anh cảm ơn mọi người đã xem.

## Nguồn và liên kết

- Tên gốc: How the Top 1% Use Claude Code Differently
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=J9NQTYUP6k0](https://www.youtube.com/watch?v=J9NQTYUP6k0)

- Kênh YouTube Simon Scrapes (Simon Scrapes): [youtube.com/channel/UCdCR4-uYOg5ju-IUuDnfnQA](https://www.youtube.com/channel/UCdCR4-uYOg5ju-IUuDnfnQA)

- Claude Code Docs, Best practices (mục "Give Claude a way to verify its work"): [code.claude.com/docs/en/best-practices](https://code.claude.com/docs/en/best-practices)

- Claude Code Docs, Keep Claude working toward a goal (`/goal`, model nhỏ chấm điều kiện sau mỗi turn): [code.claude.com/docs/en/goal](https://code.claude.com/docs/en/goal)

- Claude Code Docs, memory và CLAUDE.md (mục tiêu dưới 200 dòng mỗi file): [code.claude.com/docs/en/memory](https://code.claude.com/docs/en/memory)

- Claude Code Docs, skills (có `/skill-doctor`): [code.claude.com/docs/en/skills](https://code.claude.com/docs/en/skills)

- Claude Code Docs, plugin evals (no-plugin baseline): [code.claude.com/docs/en/plugin-evals](https://code.claude.com/docs/en/plugin-evals)

- Claude Code Docs, hooks: [code.claude.com/docs/en/hooks](https://code.claude.com/docs/en/hooks)

- Claude Code Docs, model configuration (effort level và Ultracode): [code.claude.com/docs/en/model-config](https://code.claude.com/docs/en/model-config)

- Claude Code Docs, projects: [code.claude.com/docs/en/claude-projects](https://code.claude.com/docs/en/claude-projects) và routines: [code.claude.com/docs/en/routines](https://code.claude.com/docs/en/routines)

- Bài tổng hợp cách Boris Cherny dùng Claude Code, có câu trích về verify 2-3x: [paddo.dev/blog/how-boris-uses-claude-code](https://paddo.dev/blog/how-boris-uses-claude-code)

Nguồn: https://homus.dev/talks/how-the-top-1-use-claude-code-differently · cập nhật 2026-10-13