# Ba skill đã thay đổi cách Theo ship code

[Theo Browne](https://homus.dev/speakers/theo-browne) · [Theo - t3․gg](https://homus.dev/orgs/theo-t3-gg)

> Theo giải thích ba skill sol-loop, full send, full stop: review bằng model khác, để agent tự merge, và dừng trước nút merge.

Topics: Skills, Coding Agents, Workflow

Canonical: https://homus.dev/talks/these-3-skills-changed-my-life

## 1. Ba file markdown đã đổi cách Theo build

Theo mở đầu bằng một câu cảm thán: thời thế đổi thật. Anh vẫn nhớ những ngày ngồi đây kể cho mọi người nghe về công nghệ mới, framework mới, cách mới để build software. Còn bây giờ anh sắp làm nguyên một video về ba file markdown. Nghe thì có phần ngớ ngẩn, nhưng theo Theo, ba file này đã thay đổi đáng kể cách anh build (video đăng ngày 26/10/2026).

Gần đây anh dùng ba skill này rất nhiều, và nhận được nhiều câu hỏi về chúng tới mức anh thấy đã đến lúc ngồi xuống giải thích chúng làm gì và anh dùng chúng ra sao. Ba skill đó là **sol-loop**, **full send** và **full stop** (video đăng ngày 26/10/2026).

![Bảng trắng ghi My Three Favorite Skills: sol-loop, full send, full stop](https://homus.dev/photos/5Bmp9cz1JN8-0023.jpg)

Bảng trắng Theo dùng làm dàn ý cho video đăng ngày 26/10/2026: "My Three Favorite Skills" gồm sol-loop, full send và full stop.

Theo nói đây không phải những skill mà anh nghĩ ra từ một ý tưởng thông minh nào đó rồi ép vào công việc. Thực tế là ngược lại: đó là những hành vi anh thấy mình lặp đi lặp lại, rồi biến chúng thành skill. Theo lời anh trong video đăng ngày 26/10/2026, khi làm việc trên T3 Code, gần một nửa số thread của anh dùng tới một trong ba skill này, và anh cược rằng những thread cuối cùng được merge vào main gần như luôn dùng ít nhất một trong ba. Các skill này đã giúp anh định hình chắc chắn hơn một số cách build của mình, và anh hy vọng sau khi giải thích, mọi người cũng build hiệu quả hơn.

![Bảng thống kê Agent Skill Usage Over Two Weeks: On T3 Code itself 42.9%](https://homus.dev/photos/5Bmp9cz1JN8-0043.jpg)

Bảng thống kê Theo cho agent tự query, như trong video đăng ngày 26/10/2026: trên chính repo T3 Code, 111 trong 259 thread do người mở (từ 30/9 đến 14/10/2026, không tính subagent) có nạp sol-loop, full-stop hoặc full-send, tức 42,9%; tính trên mọi project là 28,6%. Bảng bên dưới tách ra từng skill: được gọi ngay trong prompt đầu, được gọi ở một lúc nào đó, và số lần thực sự được nạp.

## 2. Repo fleet: một chỗ giữ skill cho cả đội máy

Theo nói anh sẽ đi lần lượt từ trên xuống, nhưng các skill sẽ dễ hiểu hơn nhiều nếu anh nói qua một chút về cách anh quản lý toàn bộ skill của mình. Anh có một repo trên máy tên là **fleet**. Đây gần như là repo duy nhất anh còn mở trong VS Code. Lý do: đây là nơi anh giữ toàn bộ dữ liệu về "đội máy" (fleet) của mình, tức những chiếc máy tính khác nhau mà anh làm việc trên đó (video đăng ngày 26/10/2026).

Theo nhắc rằng với T3 Code, theo anh mô tả trong video đăng ngày 26/10/2026, bạn kết nối được tới nhiều máy khác nhau và điều khiển tất cả từ một app, kể cả app trên điện thoại, điều mà anh thấy rất tiện. Nhưng giữ cho mọi thứ đồng bộ giữa các máy đó, như bảo đảm máy nào cũng đã đăng nhập (auth), máy nào cũng có skill của anh, có MCP của anh, thì khá phiền. Vì thế anh dùng repo fleet này để theo dõi tất cả.

Trong repo, anh có các folder chia theo loại skill: có những skill anh chỉ thích dùng trong Claude, có những skill chỉ dành cho một máy cụ thể mà anh gọi là "command center", và có những skill anh muốn gần như máy nào cũng có (video đăng ngày 26/10/2026).

![VS Code mở repo fleet, cây thư mục skills/universal và file SKILL.md của sol-loop](https://homus.dev/photos/5Bmp9cz1JN8-0323.jpg)

Repo fleet trong VS Code, video đăng ngày 26/10/2026: thư mục `skills/universal` chứa các skill như html-communication, leaving-pr-comments, các skill mattpocock (code-review, grilling...), modernize, pr-prioritization. Bên phải là bản gốc của `sol-loop/SKILL.md`, với metadata ghi harness (claude, codex, antigravity, muse) và yêu cầu "T3 Code delegation or native subagent tools with an available Sol model".

Theo nói có lẽ anh sẽ dọn một lượt và xoá bớt nhiều skill, vì anh không dùng nhiều như anh tưởng. Anh vẫn thích thỉnh thoảng lôi skill grilling của Matt Pocock ra dùng, nhưng phần lớn thời gian chỉ là sol-loop, full send, full stop, cộng thêm các skill liên quan tới PR như file PR và babysit PR mà anh dùng rất nhiều (video đăng ngày 26/10/2026).

## 3. Skill để lại comment PR, và description là trigger

Một skill hữu ích khác là skill để lại comment trên PR. Theo mô tả nó khá đơn giản: anh dặn agent phải nói rõ mình là model nào, và nói rằng nó đang trả lời thay mặt anh nếu nó dùng tài khoản của anh để comment. Trên màn hình, file `leaving-pr-comments/SKILL.md` yêu cầu mỗi comment do agent viết thay Theo phải mở đầu bằng một khối ghi chú của GitHub, kiểu "GPT-6 Astra responding on behalf of Theo", và dùng tên công khai đã xác minh của model đã viết comment (skill như trong video đăng ngày 26/10/2026).

```
Prefix every agent-authored comment left on Theo's behalf with this GitHub note
callout:

```md
> [!NOTE]
> **GPT-6 Astra responding on behalf of Theo**

Actual comment starts here.
```

Use the verified public name of the model that wrote the comment.
```

Nhưng đó không phải chủ đề hôm nay. Chủ đề là sol-loop. Theo nhắc lại một điều anh đã nói nhiều lần và vẫn tin, dù bản thân anh không làm theo nhiều như lẽ ra nên làm: tự tay viết những file này là một ý hay. Với skill này, anh để agent tiếp quản một chút. Ban đầu anh viết tay, nhưng anh để ý thấy Claude làm sai vài chỗ, nên anh bảo nó cập nhật skill để sửa. Rồi tối hôm trước, lần đầu tiên sau một thời gian anh đọc lại, và nhận ra nó đã phình to khá nhiều. Anh sẽ dọn lại sớm, còn lúc này điều quan trọng là ý tưởng cốt lõi (video đăng ngày 26/10/2026).

Một điều quan trọng khác là vai trò của **description**. Theo nói description không giống như cái tên của nó: nó không nên mô tả skill là gì. Nó là tín hiệu để model biết khi nào nên dùng skill. Vì vậy phần lớn description của anh rất đơn giản, về cơ bản là trigger: anh mô tả khi nào model nên làm việc này. Skill tên là sol-loop, và description là "Use when the user says "sol loop"". Như vậy nó không được kéo vào trừ khi chính anh, hoặc một skill khác, nhắc tới nó một cách cụ thể (video đăng ngày 26/10/2026).

Ý Theo nhấn mạnh trong video đăng ngày 26/10/2026: description của anh chỉ là trigger, ví dụ "Use when the user says "sol loop"", để skill không bị kéo vào khi anh không gọi tới nó.

## 4. sol-loop: bản Opus viết phình ra, và bản Theo tự viết lại

Vậy skill này là gì? Theo đọc phần mở đầu của bản cũ: bạn sở hữu code và Sol review nó; sửa những gì đúng, phản bác những gì sai, và dừng khi hai bên đồng ý hoặc khi hết budget. Mục tiêu: thay đổi nhỏ nhất đáp ứng được ý định. Review làm cho code đúng, không làm cho nó to ra (video đăng ngày 26/10/2026).

```
You own the code. Sol reviews it. Fix what is right, push back
on what is wrong, and stop when you agree or the budget ends.
Goal: the smallest change that meets the intent. Review makes it
correct, not bigger.
```

Theo gọi đoạn này là "slop" do model thêm vào, và nói nhìn là biết Opus viết. Anh quyết định tự viết lại ngay lúc đó. Bản mới, theo lời anh, mô tả tốt hơn skill dùng để làm gì: đây là một workflow giúp các thay đổi code đúng hơn trước khi (hoặc đôi khi sau khi) file một pull request. Tóm tắt: dùng GPT-6.1 Sol để review code của bạn theo vòng lặp; thực hiện thay đổi tối thiểu có thể để làm hài lòng các reviewer Sol; cẩn thận với scope creep và đừng ngại phản bác (skill như trong video đăng ngày 26/10/2026).

![SKILL.md của sol-loop sau khi Theo viết lại, câu Be careful of scope creep được bôi chọn](https://homus.dev/photos/5Bmp9cz1JN8-0543.jpg)

Bản sol-loop Theo vừa tự viết lại trong video đăng ngày 26/10/2026: "This is a workflow for making your code changes more correct before (or sometimes after) filing a pull request. tl;dr - use GPT-6.1 Sol to review your code in a loop." Câu anh bôi chọn là "Be careful of scope creep and don't be scared to push back."

```
This is a workflow for making your code changes more correct before (or sometimes after)
filing a pull request. tl;dr - use GPT-6.1 Sol to review your code in a loop.

Make the most minimal possible changes to appease the Sol reviewers. Be careful of scope
creep and don't be scared to push back.
```

Theo nhấn mạnh câu cuối, "cẩn thận với scope creep và đừng ngại phản bác", là rất quan trọng. Một trong những vấn đề của skill kiểu này, theo anh, là nếu có quá nhiều agent với những ý kiến khác nhau nói chồng lên nhau, bạn có thể nhanh chóng rơi vào tình trạng scope phình ra và PR cuối cùng to hơn nhiều so với mức cần thiết. Theo Theo (video đăng ngày 26/10/2026), dòng bổ sung đơn giản này có thể giúp tránh được nhiều chuyện đó.

## 5. Budget: ba vòng, một reviewer, không lồng nhau

Anh có một mục **Budget** nói vòng lặp được chạy tới đâu, vì nếu không nó sẽ chạy mãi (skill như trong video đăng ngày 26/10/2026). Theo đọc: mặc định ba vòng tổng cộng. Vòng một review toàn bộ; các vòng sau chỉ kiểm phần code đã đổi và các phát hiện còn mở. Chỉ kéo dài lên năm vòng khi có chuyện về security, permission, auth, mất dữ liệu, hay những thứ có rủi ro khác. Dừng sớm nếu một vòng chỉ trả về những lỗi vặt (nit), và bỏ qua nit, comment, doc, những thứ không quan trọng bằng. "Yada, yada", anh nói.

```
## Budget

- Default: 3 rounds total. Round 1 is full. Later rounds check only
changed code and open findings.
- Extend to 5 only for security, permissions, auth, data loss, or state/concurrency, while a
blocker or should stays open with evidence. Or when the user asks.
- Stop early if a round returns only nits. Declined nits and comment,
doc, or format-only fixes need no new round.
- One reviewer only. Sol must not start subagents or reviewers.
- Keep a ledger: id, severity, outcome, usage if returned. Never guess it.
```

Quan trọng nữa là mỗi lúc chỉ có một reviewer: Sol không được tự khởi động subagent hay reviewer riêng của nó. Nếu không, theo Theo, chuyện lồng nhau sẽ xảy ra "rất, rất nhanh". Sau đó skill yêu cầu ghi lại (ledger) những gì reviewer báo. Tiếp theo là một phần về scope, và một phần về cách thực sự gọi Sol. Có vài cách khác nhau để làm việc này, anh sẽ nói ở phần sau (skill như trong video đăng ngày 26/10/2026).

Vòng lặp sol-loop theo mục Budget Theo đọc trong video đăng ngày 26/10/2026: một model viết, một reviewer Sol, mặc định ba vòng, chỉ lên năm vòng với các vấn đề rủi ro.

## 6. Opus viết code, Sol soát code, và dòng ghi chú cuối PR

Theo nói anh chủ yếu dùng skill này với Opus 5.5. Theo đánh giá của anh trong video đăng ngày 26/10/2026, Opus 5.5 là người cộng tác tốt hơn nhiều, nhìn chung thông minh hơn, viết code tốt hơn hẳn, và dễ chịu hơn khi làm việc cùng. Nhưng GPT-6.1 Sol thì kỹ hơn. Anh ví nó như con chó Rottweiler: nó ngoạm lấy vấn đề và không chịu nhả ra. Anh rất thích dùng nó để review chính vì lý do này.

Theo nói anh bất ngờ khi thấy skill và workflow này đã giúp tránh được rất nhiều trường hợp PR rơi vào một vòng review bất tận khi đã lên GitHub. Có nó chạy ngay trên máy mình giúp rất nhiều ở lượt soát đầu tiên, trước khi đưa lên thành PR. Nhờ vậy, theo kinh nghiệm anh kể (video đăng ngày 26/10/2026), khi tới tay các công cụ AI review code như Macroscope, CodeRabbit và những công cụ khác mà nhóm anh dùng, code thường đã khá chắc.

Anh nói thêm, cách này còn hay vì bạn tận dụng được phần trợ giá (subsidization) mà bạn nhận được từ subscription Codex. Gần đây anh không dùng subscription Codex nhiều lắm, nên đây là cách tốt để tiếp tục tận dụng nó, dù công việc hằng ngày của anh làm trên Opus (theo lời anh trong video đăng ngày 26/10/2026).

Một chi tiết nhỏ khác anh thấy khá hay: ở cuối skill có một đoạn cho lúc PR được file hoặc cập nhật, yêu cầu thêm một dòng ở cuối PR ghi đã review bằng sol-loop, bao nhiêu vòng, với model nào. Ngay trong video, anh thêm một phần nữa ghi verdict của Sol, ví dụ "approved". Lý do, theo Theo: anh để ý vài lần Opus gần như muốn giấu việc Sol không hài lòng với các thay đổi; giờ dòng này sẽ nói thẳng ra. Anh nói đây chính là lý do việc tự tay sửa các file này là quan trọng (video đăng ngày 26/10/2026).

![Mục 5. Stop and ship trong SKILL.md của sol-loop, có câu blurb Reviewed with sol-loop](https://homus.dev/photos/5Bmp9cz1JN8-0723.jpg)

Mục "5. Stop and ship" của sol-loop trong video đăng ngày 26/10/2026: chỉ push sau khi đồng ý và khi người dùng đã yêu cầu; nếu push lên PR thì thêm dòng "Reviewed with sol-loop: <N> rounds with <model>.", và chỉ ghi "on <effort>" khi đã xác minh. Cuối cùng là phần báo cáo: số vòng, model, Sol đã đổi gì, kích thước diff trước và sau.

```
Do not push during the loop. Push after agreement only if the user asked
to push, ship, or update the PR. If you push to a PR, add above the model
blurb: `Reviewed with sol-loop:  rounds with .` Add
`on ` only if verified.
```

Sửa xong, anh ship luôn: anh ghi là đã cập nhật skill sol-loop, chỉ nói "fix formatting", rồi đẩy nó ra toàn bộ đội máy (video đăng ngày 26/10/2026).

## 7. Cho Claude Code gọi được Sol qua CLI proxy

Điều Theo suýt quên nói là làm sao cho Claude Code truy cập được Sol. Có vài cách. Theo anh (video đăng ngày 26/10/2026), cách dễ làm nhất trong một công cụ như Claude Code là dựng một **CLI proxy** để gom toàn bộ auth vào một chỗ. Anh đã làm vậy một thời gian, và đã tuỳ biến dashboard của mình rất nhiều để xem mình đang đốt rate limit nhanh tới đâu, traffic đang đi về đâu. Anh còn dựng để nó đổ toàn bộ request và response vào một database ClickHouse, để anh query lấy thông tin hữu ích.

Theo nói CLI proxy là một trong những thứ anh thích nhất mà anh đã làm cho setup của mình, và anh rất khuyên mọi người fork rồi tự dựng một cái tương tự. Khi đã dựng xong, theo anh, bạn dùng được mọi model có trong proxy ở bất kỳ công cụ nào bạn muốn (video đăng ngày 26/10/2026). Trên màn hình là trang "Quota Management" trong CLI Proxy API Console, liệt kê các credential Claude, Codex và một số model khác cùng hạn mức theo tuần.

Nhưng anh dặn phải cẩn thận khi dùng model Claude ở chỗ khác. Theo Theo (video đăng ngày 26/10/2026), nếu bạn dùng subscription Claude Code, Anthropic sẽ rất không vui nếu system prompt không phải system prompt của Claude Code. Vì vậy bạn chỉ nên dùng subscription Claude với Claude Code. Anh dùng subscription Codex với Codex, subscription Claude với Claude. Nhưng anh cũng dùng subscription Codex của mình ở chỗ khác, như trong Claude qua proxy này, vì theo anh, OpenAI về cơ bản không quan tâm bạn dùng token ở đâu. "Anthropic thì quan tâm rất nhiều. OpenAI thì không", anh nói. Nên nếu dựng setup này, hãy cẩn thận chuyện đó.

Cách Theo mô tả setup CLI proxy trong video đăng ngày 26/10/2026: gom auth vào một proxy để Claude Code dùng được model của OpenAI, còn subscription Claude chỉ dùng với Claude Code.

Anh nhắc tới chuyện này ở đây vì nó làm cho việc cấu hình Claude Code để dùng model của OpenAI trở nên rất dễ. Còn nếu lo bị cấm, Theo nói đừng lo: Tibo (trên màn hình ghi là người làm Codex và ChatGPT ở OpenAI) đã quote tweet bài của anh và gọi đây là một giải pháp được "chúc phúc", và nếu cách này khiến bạn bị chặn thì Tibo nợ bạn một lần reset. Vậy nên, theo những gì phía OpenAI đã chính thức nói tính tới video đăng ngày 26/10/2026, cách này được phép. Bài đăng của Tibo trên màn hình có ba bước (cài CLIProxyAPI, kết nối, định nghĩa alias) và alias sau:

```
alias claudex='CLAUDE_CODE_SUBAGENT_MODEL=gpt-5.6-sol \
CLAUDE_CODE_ALWAYS_ENABLE_EFFORT=1 \
CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY=3 \
ENABLE_TOOL_SEARCH=false \
claude --model gpt-5.6-sol'
```

Vì vậy, nếu bạn thật sự muốn ở lại với Claude Code nhưng vẫn có các lượt review này, đồng thời để nó làm việc theo cách bình thường bên trong Claude Code với subagent, thì theo Theo đây là một giải pháp tốt (video đăng ngày 26/10/2026). Đó là cách anh làm một thời gian.

## 8. Orchestrator V2: agent trong T3 Code gọi agent khác

Anh làm theo cách đó cho tới khi bản cập nhật mới nhất của T3 Code Nightly ra mắt, tức **Orchestrator V2**. Tóm tắt nhanh của Theo: nó cho phép agent và thread của bạn gọi các agent, harness, thread khác và bất cứ thứ gì khác bên trong T3 Code (tính năng như trong video đăng ngày 26/10/2026).

Anh demo trên một thread mà anh đã mở PR sửa cách ghi dữ liệu về các kết nối database SQLite. Anh bảo nó nhờ Muse Wonder Full, GPT-6.1 Sol và Gemini 4 Argon review các thay đổi qua delegate, và xử lý mọi phản hồi hữu ích chúng đưa ra (video đăng ngày 26/10/2026).

```
Have Muse Wonder Full, GPT-6.1 Sol, and Gemini 4 Argon review your changes in
delegates. Address any useful feedback they give.
```

![Thread SQLite Blocking Across the Fleet trong T3 Code, model Claude Opus 5.5 khởi động ba reviewer](https://homus.dev/photos/5Bmp9cz1JN8-1023.jpg)

Thread "SQLite Blocking Across the Fleet" chạy Claude Opus 5.5 trong T3 Code (demo trong video đăng ngày 26/10/2026): sau prompt của Theo, agent báo "Launching three read-only reviewers in parallel: Muse Wonder Full, GPT-6.1 Sol and Gemini 4 Argon. All three get the same brief."

Theo chỉ ra: dù anh đang dùng Opus trong Claude Code bên trong T3 Code (mà theo anh, T3 Code dùng chính Claude Code thật với subscription Claude Code thật của bạn), giờ đây, nhờ phần orchestration có sẵn của T3, tất cả các agent kia được khởi động bằng harness gốc của chúng. Anh không nhồi GPT-6.1 Sol vào Claude Code. Anh đã dạy Claude Code cách gọi Muse, Codex và Gemini ngay trong T3 Code. Trên màn hình, các subagent lần lượt khởi động; mỗi cái có thread riêng bên trong, để review thay đổi và trao đổi với thread chính (demo trong video đăng ngày 26/10/2026).

Theo nói cách này giúp việc cài đặt dễ hơn nhiều. Tính tới video đăng ngày 26/10/2026, bản T3 Code Nightly đã có tính năng này, còn bản stable "sắp ra". Anh thấy việc để agent khởi động các subagent khác để lấy phản hồi như thế này rất hay, và không chỉ vì tận dụng được mọi subscription. Lý do chính, theo anh, là các model khác nhau được huấn luyện khác nhau và hành xử khác nhau. Giống như nhờ ba người có kinh nghiệm khác nhau review một PR: khả năng họ tìm ra những điều riêng biệt sẽ tăng lên.

Đánh giá riêng của Theo trong video đăng ngày 26/10/2026: model của OpenAI kỹ nhất và tìm lỗi tốt hơn các model khác; model Claude có thể tìm ra những thứ rất kỳ lạ, có khả năng nguy hiểm mà các công cụ khác bỏ sót; Muse và Gemini thì thỉnh thoảng tìm được vài thứ, nhưng anh thấy Gemini "ảo giác" nhiều hơn là thực sự tìm ra lỗi.

Nếu bạn không muốn biến việc này thành skill, hoặc chỉ muốn thử luồng làm việc, Theo nói những gì một người xem vừa viết trong chat là cách khởi đầu tốt: delegate cho N subagent, so sánh câu trả lời, tinh chỉnh cách giao việc, rồi lặp lại bao nhiêu lần tuỳ ý (video đăng ngày 26/10/2026).

Lúc đó verdict của Sol về tới. Theo đọc trên màn hình: không có phát hiện quan trọng nào về code sản phẩm, cả bảy test đều pass, và đây là những vấn đề khác mà nó quan tâm (demo trong video đăng ngày 26/10/2026). "Bạn hiểu ý rồi đấy", anh nói.

## 9. Sidebar là inbox: thread hoặc đang chạy, hoặc biến mất

Theo kinh nghiệm Theo kể (video đăng ngày 26/10/2026), khi anh gọi skill này, PR được đưa lên có ít vấn đề hơn, nhiều khả năng đúng hơn, qua review nhanh hơn và được merge nhanh hơn. Từ lúc anh gửi prompt tới lúc PR được mở thì lâu hơn, nhưng từ lúc PR mở tới lúc đóng thì nhanh hơn nhiều. Và quan trọng nhất, một điều anh rất coi trọng: anh không muốn ném một đống slop vào team mình. Anh thấy skill này làm giảm khả năng slop đi từ một thread trong T3 Code (hay bất cứ công cụ nào bạn dùng) lên thành pull request. Nếu bạn từng thấy những PR agent mở ra mà cảm thấy áy náy, theo anh skill này sẽ giúp khá nhiều.

Giờ là lúc nói về hai skill còn lại, full stop và full send. Theo nghĩ mọi thứ sẽ dễ hiểu hơn nếu bắt đầu với full send. Nhưng trước đó, anh muốn nói một chút về cách anh làm việc trong T3 Code. Anh xin lỗi vì video đang dần thành quảng cáo cho T3 Code; anh nói T3 Code miễn phí và mã nguồn mở (tính tới video đăng ngày 26/10/2026), và hy vọng mọi người không quá bực khi anh đưa những thứ mình thích vào sản phẩm của mình.

Nếu bạn chưa dùng T3 Code, theo Theo (video đăng ngày 26/10/2026), một thay đổi tư duy quan trọng cần hiểu là ý tưởng **sidebar là inbox**. Khi việc của bạn xong, nó nên biến đi. "Settled" giống như archive. Khi việc của bạn đã merge, hoặc bạn bỏ nó, hoặc bạn đã giải quyết xong vấn đề, đừng bao giờ ngại settle nó. Lý tưởng nhất là lúc nào cũng chỉ có ít thread.

Anh cho xem một thread có PR đang mở mà anh vừa review và thấy ổn. PR này được merge trên GitHub trong khoảng tối đa 60 giây, có lẽ ít hơn, và thread được đánh dấu merged (demo trong video đăng ngày 26/10/2026). Thread này không tự settle vì anh đã tắt tính năng đó cho nó, do đây là một thread chạy lâu. Nhưng nếu không tắt cờ đó (mà theo anh, thời điểm lúc này thật không may), thread đã biến mất. Đó là mục tiêu với T3 Code: mọi thread hoặc đang chạy, hoặc biến mất.

![Trang Settings General của T3 Code: Working section (beta) và Auto-settle merged threads đang bật](https://homus.dev/photos/5Bmp9cz1JN8-1423.jpg)

Cài đặt của T3 Code như trong video đăng ngày 26/10/2026: "Working section (beta)" gom các thread đang chạy vào một mục riêng, chúng trở lại đầu inbox khi cần bạn; "Auto-settle merged threads" settle thread khi PR của nó được merge; ngoài ra có auto-settle cho thread không hoạt động sau 7 ngày.

Vì thế anh đặc biệt muốn tối ưu để PR được merge, vì anh muốn những thread này biến đi. Anh nhắc lại: khi cho xem các workflow này, anh muốn truyền đạt rằng mục tiêu là mọi thread đều được merge và đóng nhanh trong mức hợp lý. Anh không nói merge một đống slop. Anh nói bạn nên tối ưu để không có quá nhiều thứ đang chờ bạn, và làm cho việc merge với sự tự tin càng dễ càng tốt, để các thread biến đi. Cuối ngày, hy vọng là bạn có nhiều thứ nằm trong mục "working" và không còn nhiều thứ bạn đang nợ câu trả lời.

## 10. full send: trao quyền merge một cách rõ ràng

Đến lúc nói về full send. Mục đích của skill này, theo Theo, là dựa hẳn vào ý tưởng: một việc không được chiếm chỗ trong đầu anh trừ khi bắt buộc. Hãy nhớ: khi PR merge, thread tự động được archive. Anh cũng bật mục "working" tuỳ chọn trong T3 Code. Tính tới video đăng ngày 26/10/2026, đây là tính năng beta; anh rất thích nó và có thể sẽ biến nó thành mặc định sớm. Anh nói thêm, nghe cũng buồn cười, là có vẻ Claude Code cũng vừa đưa nó thành mặc định.

Ý của mục này là nếu một thread đang chạy thì nó không cần bạn chú ý; nó nên nấp đi tới khi sẵn sàng cho bạn. Điều đó cũng có nghĩa là anh sẽ không thấy các thread đang làm gì. Ví dụ một thread đang chạy 10 subagent có thể in ra thứ nó muốn anh thấy, nhưng anh sẽ không thấy vì nó bị giấu dưới mục working, và anh cho rằng như vậy là lý tưởng. Nếu nó đặt câu hỏi bằng question tool, thì theo anh (video đăng ngày 26/10/2026) thread sẽ bị kéo ra và ném lên inbox phía trên.

Anh quyết định xây nhiều hơn phần workflow quanh chuyện này. Anh muốn có khả năng đồng ý với model, biết đại khái nó sẽ làm gì, biết nó sẽ xác minh, test, kiểm tra. Và nếu đó là một fix nhỏ mà anh biết nó sẽ làm gì và làm thế nào, hoặc nó đã sửa xong và chỉ còn một việc nhỏ trước khi merge được, thì anh không muốn phải quay lại thread đó, không muốn nó làm phiền anh lần nữa, bắt anh đọc lại tất cả chỉ để bấm một nút merge. Lý tưởng nhất: khi model và anh đã trao đổi qua lại và anh tin nó biết anh muốn gì và đại khái làm thế nào, nó sẽ không làm phiền anh nữa trừ khi bị kẹt. Đó là lý do anh làm skill full send (video đăng ngày 26/10/2026).

Một lần nữa, description chỉ là trigger: "Trigger this if the user requests 'full send'." Phần thân viết: nếu người dùng kích hoạt skill này, đó là vì họ không theo dõi thread và họ muốn bạn hoàn thành công việc từ đầu tới cuối một cách tự chủ; các cập nhật và tin nhắn cuối của bạn sẽ không được đọc cho tới rất lâu sau khi bạn dừng; bạn sở hữu công việc từ trạng thái hiện tại cho tới một PR đã merge. Nếu người dùng không yêu cầu full send một cách rõ ràng, đừng mặc định là được toàn quyền. Theo nói đoạn này là lối thoát phòng khi model tự dưng kéo skill vào (skill như trong video đăng ngày 26/10/2026).

```
If the user triggered this, it's because they are not watching this thread, and
they want you to complete the work end-to-end autonomously. Your updates and
your final message go unread until long after you stop. You own the work from
its current state to a merged PR.

If the user did not explicitly request "full send" in some clear way, do not
assume full autonomy. If they did, everything below applies.
```

Anh nói rõ mình đang cấp quyền cho việc gì, vì theo kinh nghiệm anh kể (video đăng ngày 26/10/2026), một số model, cụ thể là model của OpenAI, trở nên bồn chồn khi merge trừ khi trong context có ghi người dùng đã cho phép rõ ràng. Vì vậy skill ghi: Theo cho phép bạn merge PR khi merge gate pass, và force-push nhánh riêng của PR bằng `--force-with-lease` sau khi rebase.

![SKILL.md của full-send: Theo grants you permission to, và mục Steps](https://homus.dev/photos/5Bmp9cz1JN8-1603.jpg)

Skill full-send trong video đăng ngày 26/10/2026: "Theo grants you permission to: Merge the PR once the merge gate passes. Force-push the PR's own branch with --force-with-lease after a rebase." Bên dưới là mục Steps, bắt đầu bằng "Finish the change" và "Prove it".

Theo nói đây là một trong những thứ anh thêm vào vì skill của anh luôn "dễ uốn". Nếu thấy thứ gì không chạy như ý, anh hỏi model: sao bạn làm vậy? Nó trả lời: tôi nghĩ thế này vì thế này. Rồi anh cập nhật skill để ngăn điều anh không thích. Các gạch đầu dòng này đều có vì model của OpenAI đã làm những việc anh không thích (video đăng ngày 26/10/2026).

## 11. Các bước, phần Proof và merge gate

Sau đó anh mô tả luồng: hoàn thành thay đổi, chứng minh nó, file PR, babysit PR, merge và báo cáo. Theo nói phần chứng minh (prove it) rất quan trọng: anh muốn model tìm ra cách nào đó để xác minh thay đổi của nó chạy đúng. Anh cũng nhắc tới các skill khác của mình để bảo đảm nó babysit và theo dõi pull request đúng cách. Lý do, theo anh (video đăng ngày 26/10/2026): skill babysit PR của anh từng khiến model của OpenAI không dùng các watcher có sẵn của T3 Code mà làm những việc ngớ ngẩn thay vào đó. Nên anh thêm một đoạn: trong T3 Code, dùng tính năng watch pull request (`watch_pull_request`); nếu dừng trước khi merge, gọi `unwatch_pull_request` trước. "Lại là sửa lỗi trong skill của tôi", anh nói.

```
1. **Finish the change.** Complete the goal from the user's request with the
smallest change that works. Fix the case that happened, not every case
that could. If you are on the default branch, create a branch first.
2. **Prove it.** Get proof for every change you made. See "Proof".
3. **File the PR** with the `file-pr` skill. Rebase onto the latest default
branch first. Add one short line to the description that says how you proved
the change.
4. **Babysit the PR** with the `babysit-pr` skill. Fix real findings and CI
failures. Get proof for each fix before you push it.
5. **Merge** when the merge gate passes.
6. **Report** in your final message: the PR link, the merge commit, your proof,
and each decision you made for Theo.
```

Tiếp theo là mục **Proof**. Proof là bằng chứng bạn tự quan sát được trong phiên làm việc: output của lệnh, một lần tái hiện lỗi, một ảnh chụp màn hình. Dùng bằng chứng trực tiếp nhất mà thay đổi cho phép: tái hiện lỗi gốc, áp dụng fix, rồi xem chính lần tái hiện đó pass. Chạy các check mà CI của repo chạy (typecheck, lint, test). Thêm một test tập trung, fail khi chưa có fix, nếu hành vi đó chưa có test và repo có sẵn test setup. Với UI và hành vi lúc chạy: chạy app và nhìn tận mắt thay đổi; test mock xanh không chứng minh được trải nghiệm người dùng. Theo đọc tới đó rồi nói "yada, yada". Skill còn gọi tới skill `file-upload` của anh, để agent upload được ảnh chụp hay video khi chứng minh lỗi đã được sửa (skill như trong video đăng ngày 26/10/2026).

```
Proof is evidence you observed yourself in this session: command output, a
reproduction, a screenshot. Use the most direct proof the change allows:

- Reproduce the original failure, apply the fix, then watch the same
reproduction pass.
- Run the checks that the repo's CI runs (typecheck, lint, tests).
- Add one focused test that fails without the fix, when the behavior has none
and the repo has a test setup.
- For UI and runtime behavior, run the app and look at the change. Green mocked
tests do not prove that the user experience works. Attach screenshots with the
`file-upload` skill when they help.

When you cannot find a way to prove a change, you do not have full confidence.
Ask Theo.
```

Rồi tới một **merge gate** rõ ràng, tức những gì anh đòi hỏi trước khi nó được merge: proof bao phủ mọi thay đổi; các check bắt buộc đều xanh; mọi bot review đã chạy xong và từng phát hiện đã được sửa hoặc bác bỏ kèm lý do viết ra; không còn người review nào đang yêu cầu thay đổi; nhánh đã cập nhật theo nhánh mặc định và GitHub báo là merge được (skill như trong video đăng ngày 26/10/2026).

```
Full confidence means all of these are true on the latest commit:

- Your proof covers every change in the diff.
- Required checks are green.
- Review bots have finished, and each finding is fixed or dismissed with a
written reason.
- No human review still requests changes.
- The branch is up to date with the default branch, and GitHub reports it as
mergeable.
```

Sáu bước trong skill full send của Theo (video đăng ngày 26/10/2026): bước merge chỉ diễn ra khi đủ mọi điều kiện của merge gate.

## 12. Hỏi Theo bằng question tool, chỉ khi bị chặn

Rồi tới phần Theo gọi là quan trọng nhất. Như anh đã nói, mục đích của skill và của luồng này là khi anh xong với thread, anh không phải nhìn lại nó, và anh tin nó đưa được thay đổi vào mà không cần anh xem lần cuối. Vì thế mục **Asking Theo** rất quan trọng: model cần biết cách liên lạc với anh khi anh đang bỏ qua thread (video đăng ngày 26/10/2026).

Anh bảo nó dùng rõ ràng các question tool mà nó có. Một câu hỏi nằm trong tin nhắn bình thường sẽ không ai thấy, và thread trông như đã xong. Để hỏi Theo, hãy dùng question tool của harness để thread hiện ra là đang chờ: `AskUserQuestion` trong Claude Code, `request_user_input_async` hoặc `request_user_input` trong Codex, hoặc question tool có sẵn trong Antigravity. Đặt toàn bộ context vào câu hỏi: link PR, điều gì đang chặn bạn, và các lựa chọn, với lựa chọn được đề xuất đặt đầu tiên (tên tool như skill ghi trong video đăng ngày 26/10/2026).

![Mục Asking Theo trong SKILL.md của full-send](https://homus.dev/photos/5Bmp9cz1JN8-1823.jpg)

Mục "Asking Theo" của full-send (video đăng ngày 26/10/2026): tên question tool cho từng harness, rồi danh sách "Ask only when you cannot continue alone": không chứng minh được thay đổi, merge gate không qua được, bước tiếp theo nằm ngoài quyền đã cấp, mục tiêu mơ hồ theo cách làm đổi kết quả, hoặc một PR khác làm PR này thành thừa.

Theo nói thêm, chỉ hỏi khi không thể tự tiếp tục, vì sau khi thêm mục này anh thấy nó hỏi suốt. Nên anh đặt dòng này như một cái cổng: đừng hỏi trừ khi... Và một điều cuối: nếu không có quyền truy cập thứ cần thiết, hãy đi đường an toàn. Trên màn hình, cuối mục này ghi: mọi thứ khác thì tự quyết với mặc định hợp lý và liệt kê các quyết định đó trong báo cáo; nếu không có question tool, hoặc tool trả về không có câu trả lời, hãy đi đường an toàn: để PR mở và chưa merge, và bắt đầu tin nhắn cuối bằng câu hỏi (skill như trong video đăng ngày 26/10/2026).

```
Ask only when you cannot continue alone:

- You cannot prove the change.
- The merge gate cannot pass, and you cannot fix that yourself.
- The next step is outside the grant above: deleting data, touching production,
changing things outside the repo, closing a PR, or force-pushing any other
branch.
- The goal is ambiguous in a way that changes the result.
- Another PR makes this one obsolete.
```

## 13. 27 trên 32 lần tự merge, và lưới an toàn

Theo hỏi: bạn có biết có toàn bộ dữ liệu này trong một database trên mạng của mình, để agent query được, thì tuyệt thế nào không? Anh nói nó "quá hay". Theo số đo của Theo (video đăng ngày 26/10/2026), trong khoảng thời gian giới hạn mà anh đang query, có 32 lần anh nói full send, và 27 lần trong số đó đã merge mà anh không phải nhìn lại. Sau đó anh gọi khoảng thời gian này là "vài ngày gần đây"; còn bảng trên màn hình ghi đó là 32 thread do người mở trong repo T3 Code, cùng cửa sổ hai tuần với bảng thống kê đầu video.

![Bảng Full Send: 84.4% merge without using the question tool, 27/32 và 5/32](https://homus.dev/photos/5Bmp9cz1JN8-1923.jpg)

Kết quả agent query từ dữ liệu của Theo (video đăng ngày 26/10/2026): "Full Send: 84.4% merge without using the question tool". 27/32 thread có merge và không gọi question tool sau đó; 5/32 dùng question tool sau full send. Bốn trong năm thread có hỏi vẫn merge; thread thứ năm phát hiện fix đã có trên main và hỏi về việc đóng PR thừa. Chỉ 3/32 (9,4%) hỏi về chính việc full send hay phần dọn dẹp.

Anh biết nghe có vẻ điên rồ khi không nhìn lại. Nhưng theo anh, bạn nên xây hệ thống xác minh tốt để agent tự kiểm tra xem thứ đó có chạy không. Bạn cũng nên xây lưới an toàn tốt, để nếu có hỏng, bạn bắt được nó trước khi nó ảnh hưởng tới một phần lớn người dùng, và sửa trước khi chuyện đó xảy ra (video đăng ngày 26/10/2026).

Với T3 Code, theo Theo (video đăng ngày 26/10/2026), nhóm anh có một bản nightly phát hành sáu tiếng một lần, và nhận phản hồi ngay nếu nó làm hỏng gì đó, nên anh sửa được trước khi bản stable tiếp theo ra. Anh biết cả luồng làm việc này nghe có vẻ điên rồ, nhưng anh cho xem một lead dev của app Claude Code desktop công khai nói rằng họ có thể đổi mặc định sang nhóm theo trạng thái (group by status), để hợp hơn với kiểu workflow này (bài đăng trên màn hình, tính tới video đăng ngày 26/10/2026).

Theo nhận xét: ngày càng nhiều dev tận dụng AI theo hướng bớt nghĩ về "làm sao có code tốt nhất để tôi xem", và nghĩ nhiều hơn về "làm sao xây workflow mà agent tự xác minh và ship một cách tự tin, đồng thời gỡ lại được những thứ hỏng khi nó xảy ra". Vì rốt cuộc, dù bạn, agent của bạn, hệ thống xác minh của bạn, hay các developer của bạn giỏi tới đâu, sai sót vẫn sẽ xảy ra. Bạn cần bảo đảm gỡ được sai sót với ít thiệt hại nhất có thể (video đăng ngày 26/10/2026).

Dù vậy, anh nhắc lại: trong 32 lần dùng skill này "vài ngày gần đây", 27 lần tự merge. Anh biết mình đã dùng nó trên những thread nào, và không thread nào gây ra vấn đề (theo Theo, video đăng ngày 26/10/2026). Theo anh, khi đã làm agentic coding đủ nhiều, bạn biết model làm được gì và không làm được gì, xác minh được gì và không xác minh được gì, cái gì cần nhìn thêm và cái gì không. Khi đã có trực giác đó, khá dễ để biết: thứ này chắc tự merge được, thứ kia chắc cần xem lại.

## 14. full stop: làm mọi thứ trừ bấm merge

Nhưng Theo yêu workflow này quá nhiều để không dùng một thứ tương tự, kể cả khi thay đổi hơi "gai góc". Đó là chỗ skill cuối cùng xuất hiện: **full stop**. Nếu bạn theo dõi nãy giờ, có lẽ bạn đã đoán được full stop là gì và khác full send ở đâu (video đăng ngày 26/10/2026).

Anh thừa nhận: skill này gần như hoàn toàn là slop, có lẽ nên gọi là "full slop". Nó tồn tại vì anh thích workflow full send tới mức với những thay đổi đáng sợ hơn, anh nhớ nó. Anh không muốn những thay đổi đó tự merge, nhưng anh muốn chúng làm mọi thứ khác, để tới lúc nó làm phiền anh thì mọi thứ đã sẵn sàng. Vậy full stop là Claude dựng lại skill full send của anh với một thay đổi lớn: sở hữu công việc cho tới khi PR sẵn sàng để Theo merge; tiếp tục sửa, xác minh và review; không bao giờ tự merge (skill như trong video đăng ngày 26/10/2026).

```
# Full Stop

Theo is not watching. Own the work until the PR is ready for him to merge.
Keep fixing, verifying, and reviewing. Never merge it.
```

Một lần nữa, ý là để model chạy mà không cần anh để mắt tới, nhưng đừng làm phiền anh cho tới khi rất chắc chắn mọi thứ đã sẵn sàng. Làm mọi thứ có thể để xác minh thay đổi, trao đổi với agent khác và model khác để được xác minh, đưa PR lên, babysit nó, xử lý mọi lỗi CI, mọi comment của bot review, mọi comment của những người khác trong team. Và đừng làm phiền anh trừ khi có thứ gì đó chặn cứng mà nó cần, hoặc nó nghĩ đã sẵn sàng để merge (video đăng ngày 26/10/2026).

Khác biệt duy nhất giữa hai skill theo Theo mô tả trong video đăng ngày 26/10/2026: full stop đi hết mọi bước của full send nhưng dừng trước nút merge.

Theo nói anh rất thích skill này: tính tới video đăng ngày 26/10/2026, nó nhanh chóng thành skill anh dùng nhiều nhất. Tới mức khi anh bắt đầu stream hôm đó, mọi người gửi cho anh những PR họ muốn anh xem, và gần như PR nào anh cũng mở ra và gõ ngay "figure it out, full stop".

Có một ca khá buồn cười: một người báo bug cho anh qua tin nhắn riêng trên Twitter, gửi kèm hai PR họ đã file để sửa. Anh không muốn tự đi qua và xử lý hết, nên anh copy-paste tin nhắn và viết: "Friend sent this. Triage and takeover. Full stop."

## 15. takeover, modernize và đồ thị các skill

Anh cũng có một skill **takeover**, khá đơn giản; anh bảo đừng nghĩ quá nhiều về nó. Theo mô tả đây là kiểu skill "tôi là maintainer và có đủ thứ lằng nhằng phải xử lý". Description: tiếp quản công việc đang có; dùng khi người dùng yêu cầu tiếp quản một PR, một branch, một thread agent, hoặc yêu cầu takeover. Phần thân: nhận trách nhiệm hoàn thành mục tiêu ban đầu trong khi giữ ghi công (credit) cho người đóng góp ban đầu (skill như trong video đăng ngày 26/10/2026).

![SKILL.md của takeover với description và phần Takeover](https://homus.dev/photos/5Bmp9cz1JN8-2303.jpg)

Skill takeover trong video đăng ngày 26/10/2026: "Take responsibility for finishing the original goal while preserving the original contributors' credit. Do not defend an implementation just because another agent already built it." Sau đó là phần đọc PR, branch hoặc thread nguồn, kể cả các phát hiện review và các chỉnh sửa sau này của người dùng.

Lý do anh làm skill này: anh thấy những PR sửa những thứ quan trọng, nhưng anh không nhất thiết tin được chúng, hoặc không muốn đẩy một đống thứ lên trên branch hay PR của người khác. Với skill này, anh dán link một PR vào T3 Code (hay agent nào đang dùng trong đó) và nói "take this over, full stop". Theo anh mô tả (video đăng ngày 26/10/2026), nó sẽ xem PR đó, review nó, đọc description, hiểu vì sao họ làm, rồi quyết định code có đủ tốt để làm tiếp hay nên bỏ đi và coi như tài liệu tham khảo thay vì điểm xuất phát; tạo một PR mới với mọi thay đổi nếu hợp lý, hoặc đóng góp vào PR hiện có nếu hợp lý.

Ghi công cho tác giả ban đầu rất quan trọng với Theo, vì anh không muốn mọi người cảm thấy anh chỉ đóng PR của họ rồi sao chép ý tưởng. Anh muốn người làm PR ban đầu được ghi công. Chỉ là bắt họ làm PR cho hoàn hảo thì quá nhiều việc; anh thà để một người trong team mà anh biết sẽ đưa được nó tới đích, và quan trọng nhất là bấm được nút merge, sở hữu PR và đưa nó qua. Skill này cho phép anh làm vậy mà không xoá mất công của những người đóng góp.

Skill takeover còn gọi tới skill **modernize** của anh, một skill rất, rất đơn giản: xử lý PR đã cũ, rebase lên main, kiểm tra xem trong thời gian đó có gì khác đã merge mà giải quyết cùng vấn đề chưa, để biết PR này còn cần không, và đóng nó nếu không còn cần (video đăng ngày 26/10/2026).

Theo chỉ ra cái "đồ thị skill" kỳ lạ đang hình thành. Anh bắt đầu với modernize, một luồng anh thấy mình làm rất nhiều: anh cứ nói đi nói lại cùng một điều với model, như bảo đảm PR được cập nhật, đóng nó nếu không còn hợp lý vì đã có thứ tương tự được merge. Nên anh biến nó thành skill. Anh cứ bảo các thread tiếp quản PR và branch từ chỗ khác, và nhận ra đó nên là một skill vì anh liên tục gặp cùng những vấn đề. Rồi anh muốn tận dụng subagent Sol để review nhiều hơn, việc anh từng làm tay rất nhiều, nên anh làm skill sol-loop. Anh nhận ra chất lượng code ra tốt hơn mong đợi, nên anh đưa ra full send để đi tới tận cùng. Rồi anh nhớ luồng đó quá nhiều, nên anh làm full stop để có được nhiều nhất có thể mà không bị làm phiền (video đăng ngày 26/10/2026).

Thứ tự Theo kể lại trong video đăng ngày 26/10/2026: mỗi skill là một hành vi lặp đi lặp lại được viết thành file, và skill sau gọi tới skill trước.

Trước khi quên, anh sửa description của full stop thành "Use when Theo explicitly asks for "full stop"", rồi bảo agent trong T3 Code commit và push. Theo nói đây chính là cách anh cập nhật skill trên toàn đội máy. Anh nghĩ đâu đó trong repo có một script được chạy khi anh làm vậy, nhưng anh không biết và cũng không quan tâm. Anh thà chỉ nói điều mình muốn, và theo anh (video đăng ngày 26/10/2026), các model đủ thông minh để làm việc này. Trên màn hình, prompt là "Updated some skills. Commit and push.", và agent báo đã commit và push lên main, các skill check đều pass.

## 16. Vì sao Theo không gọi skill bằng slash command

Thêm một điều, vì anh thấy nhiều người nói vậy trong phần bình luận và anh cần mọi người hiểu vì sao anh không thích: "Gọi trực tiếp chẳng tốt hơn sao?", hay "sao không tắt quyền tự gọi skill của model?" (video đăng ngày 26/10/2026)

Theo giải thích: trong chuẩn skill có một tuỳ chọn `disable-model-invocation`. Nghĩa là model không tự kéo skill vào được; bạn phải tự gọi skill, ví dụ `/sol-loop` hay `/full-send`, tức slash command, hoặc cú pháp dấu đô la để kéo skill vào. Những cách đó rất tốt nếu bạn tự gõ và muốn chắc chắn skill chỉ được dùng khi bạn chủ động gọi. Tài liệu Claude Code (đọc ngày 26/10/2026) cũng mô tả `disable-model-invocation: true` là để Claude không tự gọi skill, dành cho các workflow bạn muốn tự kích hoạt bằng `/name`.

![SKILL.md của full-stop với dòng disable-model-invocation: true được bôi chọn](https://homus.dev/photos/5Bmp9cz1JN8-2543.jpg)

Để minh hoạ, Theo thêm dòng `disable-model-invocation: true` vào frontmatter của full-stop, ngay dưới description mới "Use when Theo explicitly asks for "full stop"" (video đăng ngày 26/10/2026). Đây là tuỳ chọn anh giải thích vì sao mình không dùng.

Nhưng anh không muốn phải nhớ gõ slash command cho từng skill. Anh còn lưu ý: theo anh (video đăng ngày 26/10/2026), một số harness, chủ yếu là Claude Code, không cho bạn tự gọi nhiều skill cùng lúc. Nên nếu tắt khả năng tự gọi của model, trong một số trường hợp bạn sẽ không kích hoạt được nhiều skill một lượt, điều anh thấy cực kỳ khó chịu.

Theo nói anh không nhớ lần cuối mình gọi skill bằng dấu gạch chéo là khi nào, ngoại trừ skill grilling, vì anh để skill grilling của Matt Pocock ở chế độ gọi tay, do cách bộ skill đó được cung cấp như vậy. Anh không tự kích hoạt skill của mình. Anh viết description mô tả câu trigger, rồi anh chỉ cần gõ kiểu "sol loop, takeover, full stop", hoặc thậm chí bấm nút speech-to-text và nói "full stop, takeover, sol loop", và theo anh nó hiểu đúng như vậy (video đăng ngày 26/10/2026). Anh không cần cú pháp đặc biệt nào chỉ để gọi các skill cần thiết.

Còn câu hỏi "khi nào thì cần gọi nhiều skill?", anh đáp: "Tôi không biết. Năm lần tôi vừa cho xem chẳng hạn?" (video đăng ngày 26/10/2026)

## 17. Ghép hai skill trên một PR sửa lỗi Windows

Anh kể một ca vừa làm đúng lúc bắt đầu stream hôm đó. Có người dẫn link một issue mà họ đã sửa bằng một PR, về việc mở Explorer trên Windows. Anh lấy PR đó, copy-paste, và viết "take over and get this landed, full send". Vậy là anh đã gọi hai skill khác nhau. Theo anh kể (demo trong video đăng ngày 26/10/2026), fix này đã được merge, và PR cũ được đóng vì không còn cần nữa. Còn trên màn hình, báo cáo cuối của agent trong thread này ghi bốn PR liên quan vẫn đang mở, rằng PR mới làm chúng thành thừa, và agent không đóng hay comment vào chúng vì chưa được cho phép.

Anh mở PR đã được merge, mà anh nói mình chưa từng mở trước đó: nó đã merge, và đã ghi công cho tác giả ban đầu. Trên màn hình, PR có tiêu đề bắt đầu bằng "fix(server): Reveal in File Explorer and browser launches work on Windows", trạng thái Merged. Như vậy, theo Theo, sự kết hợp các skill này cho phép anh lấy một PR anh chưa xem, tạo một PR mới dựa trên nó, ghi công cho người dùng ban đầu, xác minh các fix chạy đúng (anh nghĩ nó đã dùng một VM Windows PowerShell để test), rồi merge, tất cả mà anh không cần nhìn tới (demo trong video đăng ngày 26/10/2026).

Và vì skill của anh yêu cầu bảo đảm mọi thứ chạy và an toàn trước khi merge, nếu không thì gọi Theo để chắc chắn, anh khá tự tin rằng nếu không bao giờ phải nhìn lại thread này thì mọi thứ vẫn ổn (video đăng ngày 26/10/2026).

Ca Theo kể trong video đăng ngày 26/10/2026: một câu prompt gọi hai skill bằng tên, không cần slash command, và agent đi từ PR của người khác tới một PR mới đã merge.

Một người xem còn bổ sung một điều mà Theo thấy rất đáng biết và cảm ơn: theo lời người đó mà Theo đọc lại (video đăng ngày 26/10/2026), khi bạn gọi skill thủ công trong Claude Code, nó chèn prompt vào như một argument của skill, vì skill trong Claude Code có thể lập trình hơn một chút và bạn truyền được thông tin vào. Nên khi gọi skill thủ công trong Claude Code, toàn bộ prompt của bạn sẽ nằm hai lần trong context. "Không lý tưởng. Đừng gọi tay. Dở lắm", Theo nói.

Theo anh, chừng đó đã cho thấy vì sao anh thích các skill này tới vậy và cách anh nghĩ về skill của mình. Anh biết nhiều người muốn anh gom tất cả vào một repo nào đó; ngay trong video, anh quyết định mở một project mới cho việc này, đặt tên là tstack, và nói nó sẽ chưa sẵn sàng sớm (video đăng ngày 26/10/2026).

## 18. Bài học: trở thành người quản lý của chính mình

Theo khép lại bằng bài học anh muốn truyền đạt. Không phải "hãy copy các file markdown của tôi vì tôi rất thông minh". Mà là để mọi người thấy cách anh tìm ra giải pháp cho những vấn đề của mình, và cách anh đang xây một workflow ngày càng trừu tượng hơn, nơi anh tham gia ở một tầng khác so với trước đây. Anh nói mình đang trở thành, theo một cách nào đó, người quản lý của chính mình.

Và để khai thác tối đa agent của mình, theo Theo, điều quan trọng là phân tích luồng làm việc của bạn, tìm ra những gì bạn tin và không tin giao cho chúng, rồi bắt đầu mã hoá điều đó vào những thứ như skill, để bạn ship hiệu quả hơn. Anh cảm ơn mọi người đã xem tới đây, và chào tạm biệt: "until next time, peace, nerds" (video đăng ngày 26/10/2026).

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

- Tên gốc: These 3 skills changed my life
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=5Bmp9cz1JN8](https://www.youtube.com/watch?v=5Bmp9cz1JN8)

- Kênh YouTube Theo - t3․gg (Theo Browne): [youtube.com/channel/UCbRP3c757lWg9M-U7TyEkXA](https://www.youtube.com/channel/UCbRP3c757lWg9M-U7TyEkXA)

- T3 Code, ứng dụng của Theo dùng trong mọi demo, repo trên GitHub có giấy phép MIT (đọc ngày 26/10/2026): [github.com/pingdotgg/t3code](https://github.com/pingdotgg/t3code)

- CLIProxyAPI, proxy Theo dùng để gom auth và cho Claude Code gọi model của OpenAI (đọc ngày 26/10/2026): [github.com/router-for-me/CLIProxyAPI](https://github.com/router-for-me/CLIProxyAPI)

- Tài liệu Claude Code về skill, phần frontmatter và `disable-model-invocation` (đọc ngày 26/10/2026): [code.claude.com/docs/en/skills](https://code.claude.com/docs/en/skills)

- Bộ skill của Matt Pocock, có skill grilling mà Theo nhắc tới (đọc ngày 26/10/2026): [github.com/mattpocock/skills](https://github.com/mattpocock/skills)

Nguồn: https://homus.dev/talks/these-3-skills-changed-my-life · cập nhật 2026-10-26