Ba skill mới của Matt Pocock khép vòng lặp code với AI

1. Bản mới của bộ skill Matt Pocock và ba skill đáng chú ý

Eric mở đầu bằng một lời nhắn cho những ai đang dùng bộ skill của Matt Pocock để build ứng dụng với AI: video này dành cho bạn. Theo video đăng ngày 20/10/2026, Matt vừa phát hành một phiên bản mới của bộ skill (v1.3, trên màn hình là v1.3.1), và trong phiên bản đó có ba skill mà Eric thấy thật sự hữu ích.

Anh hứa sẽ đi qua ba câu hỏi cho từng skill: skill đó là gì, nó chạy thế nào, và nên dùng nó ở chỗ nào trong toàn bộ vòng đời phát triển phần mềm với AI (AI software development lifecycle). Đó là toàn bộ nội dung của video.

2. Nhắc lại: grill-me, to-spec và to-tickets chia theo feature

Trước khi vào phần mới, Eric nhắc nhanh lại các skill sẵn có của Matt Pocock mà anh đã giới thiệu ở video trước.

Skill đầu tiên là grill-me. Theo video đăng ngày 20/10/2026, mục tiêu của nó là thu thập context trước khi để AI agent làm bất cứ việc gì, như build ứng dụng hay dựng một workflow. Ta muốn gom được càng nhiều context càng tốt, vì làm vậy thì độ chính xác (accuracy) của AI sẽ cao hơn nhiều. Trên màn hình là một đồng hồ đo "Accuracy" với kim chỉ lên vùng cao.

Tiếp theo là skill to-spec (theo video đăng ngày 20/10/2026): nó chuyển mọi thứ hai bên đã thống nhất trong lúc grill-me thành một plan đúng nghĩa. Plan này được đưa sang skill to-tickets, nơi plan bị tách thành một loạt ticket.

Điểm quan trọng nhất ở đây, theo Eric (video đăng ngày 20/10/2026), là các ticket được chia theo feature chứ không theo layer. Mục tiêu là mỗi ticket được một AI agent duy nhất implement, và nhờ vậy ta bảo vệ được context window của agent.

3. Nhắc lại: implement bằng TDD và code-review trong context mới

Sau to-tickets là slash command /implement. Theo video đăng ngày 20/10/2026, skill này dùng test-driven development (TDD) để làm phần implementation.

Cuối cùng là skill code-review. Theo video đăng ngày 20/10/2026, nó dùng một context window mới tinh (fresh context window) và làm theo 12 thuật ngữ refactoring lấy từ cuốn sách của Martin Fowler.

Đó là các skill đã có, đã được giới thiệu ở video trước. Ai muốn xem bộ skill của Matt Pocock khác các bộ skill khác ra sao, hay xem toàn bộ phần đi sâu vào bộ skill này, có thể xem lại video đó của Eric.

4. Skill mới 1: /implement-spec, vì sao cần nó

Skill mới đầu tiên Matt tạo ra là /implement-spec. Vì sao nên quan tâm? Eric giải thích: nếu bạn từng dùng bộ skill của Matt, bạn sẽ gặp một vấn đề. Trước bản v1.3 (theo video đăng ngày 20/10/2026), sau khi chuyển spec thành một loạt ticket, bạn phải tự tay xử lý từng ticket một. Skill implement-spec ra đời để giải quyết đúng chỗ đó.

Phần frontmatter trên màn hình, đúng như trong repo (đọc ngày 21/10/2026):

---
name: implement-spec
description: "Implement the result of /to-spec and /to-tickets in code."
disable-model-invocation: true
---

5. /implement-spec chạy thế nào: nhiều agent song song, gộp về một branch

Về cơ bản (theo video đăng ngày 20/10/2026), skill này lấy spec và các ticket đã được tạo ra bởi hai skill trước (to-spec và to-tickets). Việc đầu tiên nó làm là sắp xếp lại toàn bộ ticket, chọn những ticket không phụ thuộc vào ticket nào khác (không bị chặn) và bắt đầu làm chúng.

Nhờ vậy, ta có nhiều agent khác nhau làm việc cùng một lúc, và toàn bộ ticket được xử lý nhanh hơn nhiều so với trước đây (theo Eric, video đăng ngày 20/10/2026). Cuối cùng, mọi ticket được merge vào một branch duy nhất.

Eric chỉ vào sơ đồ: khi ticket này xong và mở khoá cho ticket khác, agent tiếp tục nhặt ticket kế. Sau đó (theo video đăng ngày 20/10/2026), skill dùng code-review skill bên dưới để review toàn bộ phần đã gộp. Cuối cùng, khi mọi thứ xong, nó sửa hết các lỗi được nêu ra và chuẩn bị pull request sẵn sàng, kèm bước dọn dẹp (cleanup).

Tóm lại (theo video đăng ngày 20/10/2026), cả implement-spec có thể hình dung là một gói chứa skill TDD, skill code review, cộng thêm việc nhiều worktree chạy song song.

6. Skill mới 2: /pr và nút cổ chai mới là khâu review

Skill tiếp theo là /pr. Câu hỏi nó trả lời: làm sao để con người review được những pull request do AI viết nhanh hơn?

Eric chỉ vào sơ đồ: AI viết code, điều đó ai cũng biết. Nhưng theo Eric (video đăng ngày 20/10/2026), nút cổ chai bây giờ là làm sao để những pull request AI viết ra trở nên nhanh và dễ review hơn. Mỗi ngày sẽ có hàng loạt pull request do AI viết, nên câu hỏi là làm sao để khâu đó nhanh lên.

7. Pull request là gì, và vì sao nó là tuyến phòng thủ cuối

Cho những ai chưa biết, Eric giải thích PR là viết tắt của pull request. Thông thường, một ứng dụng production có phiên bản live, tức phiên bản khách hàng đang dùng ngay lúc này.

Giả sử bạn muốn thêm một feature. Rõ ràng bạn không muốn thêm thẳng vào branch live. Bạn sẽ tạo một branch riêng, chỉ để làm feature đó, test nó, bảo đảm mọi thứ ổn, rồi mới merge ngược về branch main. Quá trình merge feature branch đó vào branch main (hay branch live) được thực hiện bằng cách tạo một pull request, còn gọi là merge request. Pull request liệt kê cái gì đã thay đổi, vì sao thay đổi, và những gì cần review.

Sau khi merge xong mọi thứ, code sẽ quay về branch live để khách hàng thật dùng. Nói cách khác, đó là một branch tách riêng khỏi branch live.

Bước này rất quan trọng, đặc biệt khi bạn có code ở một phía và khách hàng thật ở phía kia: đây gần như là tuyến phòng thủ cuối cùng (last line of defense). Nếu trong code có bug, ta muốn chặn nó ngay ở khâu review. Nếu không, nó sẽ ảnh hưởng tới khách hàng thật trên ứng dụng live.

Như đã nói, trước đây nút cổ chai là viết code, vì không có AI thì viết code chậm. Giờ câu hỏi là làm sao tăng hiệu suất của khâu review để đẩy nhanh cả workflow phát triển.

8. PR do AI viết thiếu bằng chứng; ba phần của PR skill

Theo góc nhìn của Matt (video đăng ngày 20/10/2026), mỗi khi để AI tạo một pull request, AI sẽ chỉ viết vài thứ quen thuộc, ví dụ một đoạn summary ngắn và một test plan. Với test plan, ta còn không biết các bước đó có hợp lệ hay không. Vẫn cần một người thật chạy ứng dụng, test nó, bảo đảm nó hoạt động rồi mới merge. Tức là không có bằng chứng nào cho thấy feature đó chạy hay không.

Vì vậy, trong pull request skill của Matt (theo video đăng ngày 20/10/2026), điều anh nhấn mạnh là cung cấp bằng chứng (proof), rủi ro (risk) và niềm tin (trust) chỉ trong vài giây. Skill có ba phần.

Phần 1 là Summary. Khác với các bản tóm tắt ta thường thấy, skill của Matt (theo video đăng ngày 20/10/2026) cố gắng vẽ diagram thay vì viết một đống chữ mà người review phải đọc hết rồi mới hiểu. Toàn bộ quan hệ giữa các phần thay đổi được minh hoạ bằng diagram. Lợi ích là nhìn một lần là thấy hết, không phải đọc từng dòng.

Phần 2 là Evidence. Theo video đăng ngày 20/10/2026, phần này để AI thật sự xem xét hiệu năng: thay đổi này có cải thiện performance không? Có screenshot không? Test có pass không? Có bằng chứng nào cho thấy nó thật sự chạy, thay vì kiểu "chắc là ổn thôi"?

Trong repo của Matt (đọc ngày 21/10/2026), template của skill pr có đúng ba mục này; dưới đây là nguyên văn phần template:

## Summary

<diagram, diff-sketch, or tree>

## Evidence

- **Before:** <screenshot/output/failing test run>
  **After:** <screenshot/output/passing test run>

## Merge Danger

**Door:** <one-way or two-way>

<optional: description>

**Blast Radius:** <one-word description>

<optional: potential ramifications of merge>

9. Merge danger: blast radius, roll back và quyết định trong vài giây

Phần 3 là Merge danger (theo video đăng ngày 20/10/2026). Giả sử pull request này làm hỏng thứ gì đó, tác động lên production là gì? Có roll back được không nếu có sự cố? Và blast radius là bao nhiêu, tức thay đổi này ảnh hưởng rộng tới đâu nếu có gì sai?

Theo video đăng ngày 20/10/2026, skill sẽ bày ra bằng chứng và kịch bản xấu nhất trước khi bạn quyết định review pull request đó. Lý do làm như vậy: nếu đó là một thay đổi nhỏ và roll back rất dễ, thì rõ ràng ta có thể cho nó đi qua. Tất nhiên còn tuỳ vào thay đổi. Nhưng nếu đó là thay đổi lớn và đôi khi rất khó làm lại, thì có lẽ đó là lúc nên dừng lại và để con người thật sự kiểm tra.

10. Tuỳ biến PR skill cho chính bạn và team

Eric lưu ý đó là phiên bản PR skill của Matt, còn phiên bản của bạn có thể rất khác. Ví dụ nếu bạn không xuất thân từ nền tảng kỹ thuật, hay chỉ biết chút ít về architecture, bạn vẫn có thể chỉnh lại skill để nó không nặng thuật ngữ kỹ thuật.

Điều quan trọng nhất là PR phải có nghĩa với chính bạn, và được điều chỉnh cho hợp với team của bạn.

11. Skill mới 3: /retro, để agent không lặp lại lỗi cũ

Tới đây, pull request hay feature về cơ bản đã hoàn chỉnh. Nhưng feature xong thôi thì chưa đủ, vì ta không biết AI đã mắc những lỗi gì trên đường đi. Làm sao để AI học từ những lỗi đó và không mắc lại? Đó chính là việc của skill tiếp theo.

Chuyện này càng đúng khi bạn có một task chạy dài, có thể là hàng chục, hàng trăm hay hàng nghìn ticket để AI hoàn thành. Có thể sẽ có lúc AI cứ mắc đi mắc lại cùng một lỗi, và việc đó ngốn rất nhiều token.

Từ đó ra skill thứ ba, /retro, cũng do Matt tạo. Theo video đăng ngày 20/10/2026, có thể hình dung retro skill là nhìn lại những gì agent đã làm và tìm cách sửa các lỗi nó đã mắc. Để làm vậy, nó đọc lại toàn bộ các cuộc hội thoại và xem xét hai thứ: cách cải thiện context, và cách cải thiện guardrails cho AI agent.

12. Retro phần context: navigation pointer và AGENTS.md gọn hơn

Bắt đầu với context. Eric mô tả cách nó hoạt động (theo video đăng ngày 20/10/2026): giả sử ta để AI agent sửa một bug hay hoàn thành một feature. Đôi khi agent mất rất lâu mới tìm được đúng thông tin cần. Có thể ta cần tạo một file AGENTS.md, trong đó có danh sách các file chính (key files): chúng nằm ở đâu, tìm chúng thế nào cho nhanh. Như vậy agent không phải lục qua mọi file, mà biết chính xác chỗ cần tìm nhờ AGENTS.md.

Câu hỏi về Navigation trên màn hình, đúng như trong SKILL.md của retro (đọc ngày 21/10/2026):

Navigation: how easy was it for the agent to find the right files? Are there hidden dependencies between files? Would a navigation pointer make it easier?

Phần tiếp theo (theo video đăng ngày 20/10/2026) là cải thiện chính file AGENTS.md, thứ đóng vai system prompt. Có chỗ nào quá dài, thừa, nên bỏ khỏi AGENTS.md không? Gom lại, mục tiêu của context engineering ở đây là xem ta cải thiện context window của agent được tới đâu.

13. Retro phần guardrails, và lời cảnh báo của Matt

Phần thứ hai là guardrails. Theo video đăng ngày 20/10/2026, mục tiêu là để AI agent tuân theo các quy tắc cố định (fixed rules). Những quy tắc cố định này gồm những thứ như API không được gọi, kiểu import, file nằm sai thư mục. Có thể ta thêm vài lint rule để chặn các lỗi đó xảy ra.

Còn những thứ cần tính nhất quán về style và "gu" code (code taste) thì không có quy tắc cứng; đó là thứ ta sẽ đặt thành coding standard.

Theo những gì Matt Pocock nói (dẫn trong video đăng ngày 20/10/2026), ta không nên bật retro ở chế độ autopilot. Mục tiêu là chạy nó định kỳ. Nếu để nó chạy liên tục, nó sẽ biến mọi thứ nó nhìn thấy thành chuyện bắt bẻ vụn vặt (nitpicking). Khi đó cả dự án sẽ trôi từ việc build feature sang chỉ lo cải thiện chính dự án.

Vì vậy vẫn nên chạy retro định kỳ, nhưng cần có con người trong vòng lặp (human in the loop) để duyệt những đề xuất mà retro skill đưa ra.

14. Ghép lại: cả workflow và trang bản đồ skill

Gom tất cả lại: ta có các skill đã nói ở video trước, cộng với ba skill mới trong video này. Ba skill mới (theo video đăng ngày 20/10/2026) đặt vào đúng chỗ của chúng: implement-spec nằm giữa to-tickets và code-review. Sau code-review là pull request skill, giúp con người review pull request dễ hơn nhiều. Và sau khi xong, ta có retro skill, khép kín vòng tròn để lần sau, khi AI agent làm một feature hay sửa một bug, mọi thứ hiệu quả hơn. Đó là toàn bộ workflow từ bộ skill của Matt Pocock.

Eric cũng cho thấy thẻ repo trên màn hình, kèm lệnh cài cả bộ skill:

npx skills add mattpocock/skills

Đó là toàn bộ nội dung về các skill mới của Matt Pocock và vị trí của chúng trong vòng đời phát triển phần mềm. Nếu muốn xem chi tiết từng skill nằm ở đâu và hoạt động thế nào, Eric đã dựng hẳn một trang riêng (đường dẫn có ở phần nguồn bên dưới). Trên trang đó (theo video đăng ngày 20/10/2026) bạn bấm vào từng skill để xem nó là gì, dùng khi nào và chạy ra sao; mọi thứ nằm trên một canvas.

Eric kết thúc video bằng lời mời: ai có câu hỏi, hay có skill yêu thích muốn anh review, cứ để lại bình luận.