Build một skill và một MCP server từ đầu, và khi nào cần cái nào

1. Mở đầu: hai live build, code thật, và một chút nói thẳng

Brian Munz mở buổi live (video đăng ngày 14/10/2026) bằng lời cảm ơn mọi người đã tham gia. Anh nói lần này anh lùi lại một bước khỏi kiểu "đi dây trên cao" (high wire act) của một live build, tập trung nhiều hơn vào phần giáo dục nhưng vẫn làm một số thứ trực tiếp. Cách làm lần này là để mọi thứ có cơ hội chạy thành công, anh và nhóm muốn nó chạy được, để người xem thật sự học được gì đó.

Chủ đề hôm nay là skill và MCP server, theo Brian là hai chủ đề rất nóng trong AI suốt một thời gian dài (video đăng ngày 14/10/2026). Điều anh và Prismatic cố gắng làm là tập trung vào khía cạnh thực tế của AI, thay vì chạy theo những chu kỳ hype hứa hẹn cả thế giới.

Anh tự giới thiệu: Brian Munz, developer advocate tại Prismatic, đến từ Pennsylvania, "như các bạn thấy qua đồ của đội Sixers". Anh nói mình đã làm developer "cả triệu năm" (slide giới thiệu của anh ghi "Developer for [REDACTED] years"), chủ yếu làm về data integration, nhưng cũng từng làm cho vài công ty AI từ trước thời bùng nổ. Anh hy vọng điều đó cho anh một góc nhìn tốt về cái gì là thật, cái gì không, cái gì là hype, nhất là khi nói về những khía cạnh hữu ích của AI và cách nó liên quan tới developer.

Nội dung buổi live (video đăng ngày 14/10/2026): nói về MCP và skill, và build cả hai. Anh sẽ cho xem một ví dụ rất cơ bản về cách build một skill, cách build một MCP server, để thấy việc đó dễ hay khó tới đâu. Anh cũng nói về ưu và nhược điểm, đặc biệt là MCP có những chi tiết thú vị cần để ý và cần phân tích kỹ khi bạn bắt đầu hiểu nó. Slide "Today" ghi gọn: "Two live builds. Real code. Some real talk." với các mục Why (agent cần know-how và access), Build một skill live, Build một MCP server live, Real talk (chỗ MCP rối), và Q&A, kèm câu "Live Demos are the spice of life" ký tên "Shakespeare, probably".

Nếu còn thời gian thì sẽ có Q&A. "Với AI thì không bao giờ biết được, với live build cũng không bao giờ biết được", anh nói, rồi bắt đầu luôn.

2. Agents of chaos: vì sao cần skill và MCP

Vậy tại sao lại có skill, và tại sao lại có MCP server? Brian cho rằng phần lớn những gì bạn nghe về AI, nhất là AI trong phát triển phần mềm, xoay quanh một sự thật: AI là "agents of chaos" (theo Brian, video đăng ngày 14/10/2026). Chúng cố hết sức. Chúng đoán, và đoán một cách tự tin. Mọi thứ là xác suất. Nó cần context mà nó không có.

Anh đề nghị tạm gác sang một bên những chuyện bạn đã nghe về siêu trí tuệ, về một bộ não sẽ, như ví dụ chiếc kẹp giấy (paperclip), giết hết loài người. Vứt hết ra ngoài cửa sổ. Theo anh (video đăng ngày 14/10/2026), đây chỉ là những thứ đang cố làm điều bạn yêu cầu, cố lấy thông tin, và chúng cần guardrails. Skill cung cấp guardrails, MCP cung cấp guardrails. Ai cũng biết về hallucination và những chuyện kinh dị người ta kể; theo Brian, phần lớn những gì bạn nghe về AI trong phát triển phần mềm là chuyện dựng guardrails để mấy thứ đó không xảy ra.

Câu hỏi là làm sao tạo ra tính tất định (determinism) bên trong một sản phẩm, một công nghệ vốn không tất định. Brian nói (video đăng ngày 14/10/2026): nếu bạn đưa cho một AI agent cùng một prompt năm lần, nhiều khả năng bạn nhận về năm kết quả khác nhau. Anh chắc là hôm nay mọi người sẽ thấy điều đó. Anh đã chạy thử buổi này vài lần rồi, và nó có thể là một chuyến đi khá điên. Nhưng cơ hội tốt nhất bạn có thể tự tạo cho mình là giảm rủi ro bằng những thứ như skill và MCP.

Nói về skill, Brian tóm lại (video đăng ngày 14/10/2026): về cơ bản bạn đang cố cung cấp context cho AI agent theo cách này hay cách khác, và anh sẽ đi vào chi tiết ngay sau đó.

3. Old school: các nền tảng cơ bản của developer

Một tin tốt, theo Brian (video đăng ngày 14/10/2026): nếu bạn là một nền tảng, một sản phẩm muốn tạo skill để người ta tương tác với nền tảng của bạn tốt hơn, và bạn đã nắm vững những nền tảng của phát triển phần mềm kiểu cũ, tức là tài liệu sạch và cập nhật, một SDK được thiết kế tốt, quy ước đặt tên, code ví dụ, thì bạn đã đi được khoảng 80% chặng đường. Lý do anh đưa ra: nếu bạn chỉ trỏ một agent vào nền tảng của bạn, nó sẽ đi tìm docs, tìm các ví dụ, tìm mọi thứ bạn cần, và nó sẽ cố hết sức, làm một việc tạm ổn dựa trên những gì có công khai. Đó là tin tốt.

Slide "Old School, The fundamentals" trong video đăng ngày 14/10/2026 (hình bộ xương phát sáng bên cạnh) liệt kê: Clean, current docs (AI giờ đọc chúng như input huấn luyện); Well-formed SDK (type thật, được export); Consistent naming & conventions (API dễ đoán); Real, public example code (chạy được, không phải pseudocode); Clear error messages (nói rõ cái gì hỏng và vì sao).

Brian nói một phần trong số đó thật ra là kiểu SEO truyền thống, rồi tự sửa: không hẳn SEO, nhưng một phần là chuyện kiểu SEO và chuyện làm mọi thứ dễ dàng cho developer. Vì trong trường hợp này, theo anh (video đăng ngày 14/10/2026), một AI agent đang giả làm, hoặc chính là, một developer. Nó đang đóng vai developer, nên nó sẽ dùng đúng những công cụ đó.

Rồi tới phần "new school", theo Brian (video đăng ngày 14/10/2026): đó là skill, tức là dạy cho AI những quy ước (convention) của bạn.

4. New school: skill là giai điệu của bài hát

Tất cả những thứ anh vừa kể, bạn có thể gói vào một skill: chỉ cho agent đồ nằm ở đâu, đưa cho nó context nó cần để thật sự thành công. Brian dùng một ẩn dụ âm nhạc, và dặn mọi người đừng mổ xẻ ẩn dụ này quá kỹ: một skill giống như giai điệu (melody) của một bài hát (theo Brian, video đăng ngày 14/10/2026). Bạn đang nói với agent: bài hát phải nghe như thế này khi bạn làm xong. Nó có thể chơi bằng tuba, trumpet, guitar, gì cũng được. Nhưng khi đi ra ở đầu bên kia thì nó phải trông như thế này. Và nếu bạn làm theo cách này, tôi sẽ vui, và bạn đã làm đúng việc của mình.

Cũng theo cách đó, nếu bạn bảo agent build một integration trong Prismatic, nó sẽ build đúng cách, vì bạn đã nói cho nó biết phải làm thế nào (theo Brian, video đăng ngày 14/10/2026). Anh nói thêm: anh làm ở Prismatic, nhưng buổi này không phải một màn chào hàng lớn cho Prismatic. Anh sẽ cho xem một chút Prismatic, nhưng anh nghĩ các nguyên tắc cơ bản và những thứ anh trình bày khá dễ chuyển sang chỗ khác.

Bốn điều cơ bản để bắt đầu, anh sẽ cho xem khi bắt tay vào build:

• Front matter. Nếu bạn quen YAML, nếu bạn là developer, đó là thứ bạn thấy ở đầu các file YAML; mọi người sẽ thấy anh build phần này (video đăng ngày 14/10/2026).
• Process guidance. Bạn đưa cho nó một danh sách. Ví dụ với việc build một integration trên Prismatic: trước hết bạn cần dựng cấu trúc file, rồi build file này, rồi đặt cái này vào file kia. Bạn đưa cho nó các bước, để nó không phải tự đi tìm hiểu rồi có khả năng làm hỏng (theo Brian, video đăng ngày 14/10/2026).
• Templates và code ví dụ. Phần này anh sẽ nói kỹ hơn sau (video đăng ngày 14/10/2026).
• Start small. Bạn không cần ôm cả đại dương khi tạo một skill (theo Brian, video đăng ngày 14/10/2026).

5. Cùng một prompt, có và không có skill: connector Pokémon

Trước khi build, Brian muốn cho xem một thứ anh thấy thú vị. Anh nói chủ yếu sẽ dùng Claude Code, vì đó là agent anh thoải mái nhất, và theo anh là một trong những coding agent phổ biến nhất (video đăng ngày 14/10/2026); anh cũng sẽ cho xem một chút Codex.

Anh đã yêu cầu Claude Code, khi không có skill nào, build một Prismatic connector để xem nó làm gì và khác biệt ra sao. Prompt là build một Prismatic custom component cho API Pokémon, kèm mô tả đại khái cần trả về gì. Một API rất cơ bản, một yêu cầu khá cơ bản. Ở cuối, nó báo: build sạch, tôi làm xong rồi, đây là tóm tắt mọi thứ tôi đã làm. Nó cực kỳ tự tin, tưởng mình đã làm một việc tuyệt vời (demo trong video đăng ngày 14/10/2026).

Nó làm Brian nhớ tới một nhân vật trong Arrested Development, nếu ở đây có ai là fan: nhân vật này lúc nào cũng cố làm một trò ảo thuật, tạo ra một quả cầu lửa, nhưng thay vào đó thì dầu bật lửa phun ra, và anh ta chỉ nói: ừ, nhưng dầu bật lửa ở đâu ra vậy? Bạn không muốn kết thúc với dầu bật lửa, bạn muốn có quả cầu lửa. "Không biết ví von vậy có ổn không, nhưng thôi", anh nói.

Nó đã chạy và build xong. Anh không chiếu lại phần đó theo thời gian thực vì nghĩ không đáng mất thời gian. Nhưng có một cách để kiểm tra: Prismatic có một validator để validate component trước khi đưa vào. Validate thứ nó làm ra thì kết quả là validation failed (demo trong video đăng ngày 14/10/2026). Trên terminal, validator báo thiếu file bắt buộc src/actions.ts hoặc src/actions/index.ts rồi in "VALIDATION FAILED". Agent đã đi tìm mọi context Prismatic có về SDK và mọi docs, "và tôi hứa là docs của chúng tôi tốt", nhưng nó vẫn không tạo ra được.

Brian nói thêm (video đăng ngày 14/10/2026): đôi khi nó validate được một cách kỳ lạ, anh gặp vài lần như vậy khi chạy. Nhưng kể cả khi validate được, đến lúc xét từng phần anh cần từ component thì nó có thể hỏng ở đó. Nó không có context từ anh mà nó cần. Nên ngay cả khi đúng format, nhiều khả năng nó không có đúng business logic.

Rồi anh mở lần chạy có Prismatic skills (demo trong video đăng ngày 14/10/2026). Ngay khi bắt đầu, nó nhận ra yêu cầu, nhận ra có một skill ở đó, biết framework và build ra. Đến cuối, nó build xong, deploy toàn bộ, và biết chính xác phải làm gì. Trên màn hình là bản tóm tắt "Published successfully" cho component Pokémon TCG, với phần Auth, Actions, Error handling và Structure theo layout connector chuẩn.

Brian thừa nhận: chạy với skill thì lâu hơn (theo Brian, video đăng ngày 14/10/2026). Nhưng đó là vì bạn đã đưa cho nó tất cả các bước, và nó đang rất cẩn thận. Nó tự test, nó thay đổi hành vi của mình. Rồi anh quay lại slide, xin lỗi vì phải mở ghi chú: "Tôi không làm hết chuyện này bằng trí nhớ đâu, tin hay không thì tùy."

6. Use case: một integration của Acme với Salesforce bị lỗi

Use case cho phần skill, và cũng là use case anh dùng xuyên suốt sang phần MCP: hãy tưởng tượng anh là một nền tảng. Brian giải thích Prismatic là một embedded integration platform: nó cho phép một nền tảng SaaS mở integration cho khách hàng của họ, để khách hàng của họ kết nối tới các integration. Giả sử, là khách hàng của Prismatic, một công ty tên Acme đã kết nối tới Salesforce, và việc tích hợp với Salesforce bị lỗi (ví dụ trong video đăng ngày 14/10/2026).

Trên màn hình là file fixtures/acme-sync-failure.json: event instance.execution.failed, customer Acme Corp, integration "Salesforce Sync" version 12, environment production, 3 lần lỗi trong giờ qua và 3 lần liên tiếp, lỗi cuối ở bước "Fetch Updated Contacts" với HTTP 401 và mã INVALID_SESSION_ID, message "Session expired or invalid" (dữ liệu demo trong video đăng ngày 14/10/2026). Anh định phóng to lên rồi nói như vậy sẽ hơi khó nhìn ngay sau đó. Anh nói thêm đây không hẳn là hình dạng thật của một failure, nhưng cứ coi như một failure đi vào.

Nếu bạn là người làm support, Prismatic sẽ lấy thông điệp lỗi này và gửi đi đâu đó. Bạn nhận một alert báo có lỗi. Bạn thấy được chuyện gì đã xảy ra nhưng không có nhiều context. Theo Brian (video đăng ngày 14/10/2026), nếu bạn có một skill được cung cấp đúng context về Prismatic, rồi về nền tảng của bạn với tư cách khách hàng Prismatic, một người làm SaaS, một người làm support, thì skill đưa context đó cho agent để nó diễn giải được failure.

Khi đó bạn có thể tự hỏi: chuyện này có cần báo cho team ngoài giờ không? Nó có nghiêm trọng không? Và nên viết nó thành tin nhắn thế nào, nếu đây là thứ bạn đã quá quen? Theo Brian (video đăng ngày 14/10/2026), bạn có thể dùng một skill để làm tất cả những việc đó, vì nó sẽ lấy failure, xử lý, hiểu nó và biết cách định dạng nó thành một tin nhắn thật.

7. Chạy thử khi chưa có skill

Brian phóng to terminal, nói phóng to làm mọi thứ hơi khó nhìn, rồi giải thích (demo trong video đăng ngày 14/10/2026): anh phải chạy theo một cách đặc biệt, vẫn là Claude nhưng chạy qua một script (scripts/claude.sh trên màn hình). Việc này mất một phút, vì anh muốn môi trường thật "vanilla": máy anh có quá nhiều skill và đủ thứ khác.

Lần đầu anh hỏi khi chưa có skill (demo trong video đăng ngày 14/10/2026). Yêu cầu là draft một Slack alert cho event đó, tức là diễn giải failure và tạo một Slack alert mà anh sẽ copy rồi dán vào Slack. Prompt trên màn hình:

Draft a Slack alert for the event in fixtures/acme-sync-failure.json.

Anh trả lời trước một câu hỏi mà anh đoán người xem sẽ đặt ra (video đăng ngày 14/10/2026): chẳng phải có thể tự động hoá chuyện này, để AI tự xử lý rồi gửi thẳng thành Slack alert sao? Tất nhiên là được. Nhưng một là anh muốn cho xem một ví dụ đơn giản, hai là đôi khi sẽ có con người trong vòng lặp (human in the loop). Và đây cũng chỉ là một trong cả triệu khả năng bạn có thể làm với skill.

Kết quả, theo Brian, thật ra khá ổn (demo trong video đăng ngày 14/10/2026). Nó nói event này đáng một alert critical, mức độ nghiêm trọng, đây là cái gì hỏng. Nó không có cách gửi alert và hiểu điều đó.

Giờ tới phần "chaos": anh hỏi lại y hệt. Anh không biết lần này nó sẽ làm gì, nhưng đã có vài lần anh hỏi như vậy và nó trả về một khối JSON kèm câu "đây là những gì bạn có thể làm". Lần này kết quả trông hơi khác một chút, "mà có khi cũng không" (demo trong video đăng ngày 14/10/2026).

Brian nói (video đăng ngày 14/10/2026): kết quả này có thể trông ổn, nhưng nó vẫn không có context. Nó không biết bạn muốn định dạng thế nào. Có thể team có những quy định riêng: không chỉ là critical hay không critical, và đủ thứ khác. Nó không biết quy trình kinh doanh của bạn, và không biết việc này gắn với bạn ra sao. Nhất là nếu đây là một công cụ nội bộ, nó chỉ dùng được context có trong tài liệu nội bộ, "và ai cũng biết mọi người thích cập nhật tài liệu nội bộ tới mức nào", đó là chưa kể bạn có cho AI quyền vào hệ thống đó hay không.

8. Dọn môi trường và tạo thư mục skill: skill chỉ là markdown

Vậy việc nên làm là build một skill. Brian mở một tab terminal. Skill nằm trong các thư mục tên là skills, anh giải thích, và anh sẽ tạo một skill mới. Anh tưởng thư mục đang trống, nhưng nó không trống. Anh dọn nó đi bằng script reset: "tôi chưa reset từ lần trước". Giờ thì sạch hoàn toàn. "Thật lòng mà nói, có khi đó là lý do lần chạy thử không có skill của tôi trông tốt như vậy", anh nói, rồi thêm rằng trước đó nó cũng trông gần như vậy, chỉ là tệ hơn (demo trong video đăng ngày 14/10/2026).

Giờ trong thư mục skills không còn gì. Anh nhắc còn có một kiểu thư mục agents mà bạn có thể dùng; anh đang dùng Claude, và Claude làm hơi khác (theo Brian, video đăng ngày 14/10/2026). Việc tiếp theo là tạo một thư mục để chứa skill. Skill tên là alert-writer. Lệnh tạo thư mục cũng tạo luôn file sẽ dùng:

mkdir -p .claude/skills/alert-writer
code .claude/skills/alert-writer/SKILL.md

Anh phóng to editor một lúc, "dù điều đó làm mọi thứ xấu đi", và giờ trong thư mục có một file SKILL.md. "Spoiler alert" nếu bạn chưa biết: skill chỉ là các file markdown (theo Brian, video đăng ngày 14/10/2026), và markdown thì đại khái là một dạng tài liệu có cấu trúc theo kiểu lập trình. Khi người ta biết chuyện này, đã có người nói với anh, nguyên văn: "Thế thì ngớ ngẩn quá. Dễ quá. Vậy còn ý nghĩa gì nữa? Đây còn là code không? Tôi là ai với tư cách một developer?"

Đến một mức nào đó, anh thấy phản ứng đó dễ hiểu. Nhưng nếu nghĩ kỹ, đây là các large language model (LLM), được xây ra để hiểu và xử lý ngôn ngữ. Vì vậy, theo Brian (video đăng ngày 14/10/2026), một skill là cung cấp thứ ngôn ngữ mà model cần làm context để làm việc nó cần làm. Nhưng như mọi người sẽ thấy ngay sau đây, còn có những thành phần kiểu code mà bạn có thể đặt vào skill và chúng giúp rất nhiều.

9. Front matter: name, description và cách agent chọn skill

Đầu tiên là phần front matter anh đã nhắc. Front matter về cơ bản là một phần header, thường thấy ở các file YAML, và được mượn sang cho skill (theo Brian, video đăng ngày 14/10/2026). Editor đã tự đoán trước nội dung, có thể từ những lần anh chạy trước. Tất cả những gì front matter làm là đặt tên skill rồi mô tả skill. Tên là alert-writer.

Rồi tới description. Editor lại đoán luôn phần này (demo trong video đăng ngày 14/10/2026), và anh nói không cần gõ hết ra vì chỉ tốn thời gian. Một câu hỏi quan trọng ở đây: AI có thể viết skill hộ bạn không? Brian trả lời: "một trăm phần trăm", và phần thứ hai của việc viết skill anh sẽ cho xem đúng như vậy. Nhưng hãy nhớ, thứ bạn đang cố cung cấp là context mà AI khó tự hiểu, tức là context của bạn. Bạn biết mình muốn gì.

Vì vậy, theo Brian, một phần lớn là xác định skill này thật sự làm gì. Front matter trên màn hình (demo trong video đăng ngày 14/10/2026):

---
name: alert-writer
description: Writes integration failure alerts in our team's format. Use when an integration, sync, or instance fails and the team needs to be alerted, or when asked to draft or send an alert.
---

Nói gọn lại: alert đi vào, hãy hiểu nó; đây là lúc skill được dùng. Brian giải thích vì sao phải có front matter (theo Brian, video đăng ngày 14/10/2026): khi agent khởi động, nó có một loạt skill có thể dùng. Việc nó làm là quét qua front matter của tất cả các skill, kiểu "được rồi, mình có những skill gì, chúng làm được gì".

Anh mở một cửa sổ Claude khác để minh hoạ một điểm hay bị nhầm. Có thể bạn đã thấy: trong Claude bạn gõ dấu gạch chéo, còn trong Codex là ký hiệu đô la, và đó là một command; một skill sẽ hiện ra ở đó. Bạn có thể có một skill hiện thành /alert-writer. Nhưng theo Brian (video đăng ngày 14/10/2026), điều đó khác với bản chất của một skill: một skill chỉ có nghĩa là nó có sẵn cho agent, và agent sẽ quyết định dùng skill nào và khi nào. Nên nếu anh gõ lại prompt lúc nãy, agent sẽ thấy skill và nghĩ: description nói với mình đây là việc người này đang cố làm. Docs Claude Code (đọc ngày 27/10/2026) ghi hai đường: Claude dùng skill khi thấy phù hợp, hoặc bạn gọi thẳng bằng /skill-name.

10. Theo chuẩn Agent Skills: để Claude viết phần thân

Chừng đó là đủ để khởi tạo skill và để Claude nhận ra nó, nhưng skill chưa có phần mô tả dài. Brian định nhờ chính agent build phần còn lại, và lý do là: ngày nay đã có những chuẩn được định nghĩa sẵn cho skill (theo Brian, video đăng ngày 14/10/2026).

Anh kể: ở Prismatic, khi anh và nhóm lần đầu ra mắt skill, gần một năm trước tính từ lúc quay (video đăng ngày 14/10/2026), skill được làm tập trung cho Claude, vì Claude khi đó đang dẫn đầu mảng này và đủ mạnh để làm việc anh và nhóm cần, là build integration và những thứ tương tự. Nhưng từ đó tới nay đã có chuẩn, để bạn không chỉ build skill cho Claude, không chỉ build cho Codex hay gì đó; có những chuẩn bạn dùng được cho tất cả. Vì thế khi nhờ Claude viết phần thân, lý tưởng là nó sẽ dùng các chuẩn và best practice đó để làm ra skill tốt nhất. Sau khi build xong, anh sẽ validate skill.

Anh xin lỗi vì phải xoay xở nhiều màn hình, rồi đưa prompt vào agent (demo trong video đăng ngày 14/10/2026). Nội dung là điền phần thân của skill alert-writer vừa tạo, tức file markdown đó, nằm dưới front matter, và giữ toàn bộ file dưới 100 dòng. Mọi context anh nhắc lúc nãy, thứ mà chỉ bạn, người làm ở công ty đó, mới biết, được đặt vào đây. Phần của prompt thấy trên màn hình:

the frontmatter. Keep the whole file under 100 lines.

- When to alert: repeated failures in production, or any auth failure in production
- When not to alert: a single failure that succeeded on retry, or anything outside production
- Severity:
  - critical = production plus data not syncing, or an auth failure
  - warning = degraded or retrying
  - info = recovered or FYI
- Format: four lines (what broke, who's affected, impact, suggested next step)
- Rules: message 500 characters max, title 80 max, lead with the customer and integration, use only facts from the event
- Example: one worked example, a different failure shaped like fixtures/acme-sync-failure.json (different customer, warning-level), shown as the event JSON, the resulting alert, and the send_alert call

Brian nhấn mạnh một điểm rất quan trọng (video đăng ngày 14/10/2026): anh đưa một ví dụ, một failure khác nhưng có cùng hình dạng với failure này. Đây là failure mình nhận được, nhưng điều mình nói với agent là: failure khi đi vào sẽ trông như thế này. Mình đưa cho nó context để nó biết, về mặt code, dữ liệu trông ra sao, để nó không phải tự đi đoán. Anh cho prompt chạy, và nói thêm rằng đây mới chỉ là phần cho dữ liệu đi vào.

Phần cực kỳ quan trọng tiếp theo, theo Brian (video đăng ngày 14/10/2026), là khi bạn build một thứ gì đó, ví dụ lại là một Prismatic integration. Prismatic integration là code native: bạn build chúng bằng code rồi chúng được đưa vào Prismatic, nên bạn có thể chỉnh sửa, mày mò chúng ở local như mọi file khác. (Đúng lúc đó agent hỏi anh một loạt câu, và anh nói có lẽ lẽ ra anh nên chạy thử phần này trước.) Với skill, bạn có thể quy định: nếu ai đó dùng skill integration, thì đây là cách mình muốn nó được định dạng, đây là cấu trúc mình thích.

Anh và nhóm còn trỏ skill vào repo công khai của Prismatic trên GitHub: đây là monorepo của mình, đây là thứ mình cho là một template tốt để người ta dùng khi tạo integration. Agent đi tới đó, lấy template và điền vào (theo Brian, video đăng ngày 14/10/2026). Anh tóm lại: skill chỉ là chữ là một chuyện; chỉ cho nó đúng chỗ là chuyện khác; nhưng khi có code mẫu, kiểu "đây là hình dạng cần có, đây là cách đặt tên file", thì đó là lúc skill trở nên đặc biệt mạnh.

11. Validate bằng skills-ref, rồi chạy lại với skill

Có vẻ agent đã build xong. Anh kiểm tra: nó đã điền phần còn lại theo đúng yêu cầu, và theo anh, được định dạng đúng theo cách người ta cho là nên định dạng vào lúc này (video đăng ngày 14/10/2026). Trên màn hình, Claude báo file có 85 dòng, dưới giới hạn 100 dòng, và đã bao gồm khi nào alert, khi nào không, các mức severity, format bốn dòng, các rule, luồng send_alert và một ví dụ mức warning với một khách hàng và integration khác fixture (demo trong video đăng ngày 14/10/2026).

Tiếp theo là validate. Cùng với các chuẩn đã định nghĩa về cách build skill, Brian nói giờ nhiều agent đi kèm validator cho skill (theo Brian, video đăng ngày 14/10/2026). Anh dùng skills-ref, công cụ do chính những người định nghĩa chuẩn tạo ra, để validate skill vừa làm và đảm bảo nó ổn:

skills-ref validate .claude/skills/alert-writer

Kết quả trên terminal là "Valid skill: .claude/skills/alert-writer", "tuyệt" (demo trong video đăng ngày 14/10/2026). README của skills-ref (đọc ngày 27/10/2026) ghi đây là thư viện tham chiếu cho Agent Skills, dùng cho mục đích minh hoạ, không dành cho production.

Giờ có skill rồi, có một bước khá quan trọng. Brian chuyển sang Claude và nói (video đăng ngày 14/10/2026): với skill thì mỗi agent một khác, nhưng nhìn chung skill được nạp khi session với agent bắt đầu. Nên anh thoát khỏi session rồi vào lại bằng claude.sh, để nó nhận skill, rồi chạy lại đúng prompt ban đầu. Lý tưởng là nó lấy đúng failure đó, dùng skill, và cho ra tin nhắn được định dạng theo cách mình muốn.

Nó chạy dần qua từng bước, lấy dữ liệu event. Ngay ở đây, anh chỉ vào dòng báo đã nạp skill: như anh nói, đó là dấu hiệu tốt, nó biết skill ở đó (demo trong video đăng ngày 14/10/2026). Tin nhắn được định dạng như mong muốn: severity là critical, có mốc thời gian, đủ cả. Vấn đề, tất nhiên, là ở đây mình mới chỉ tạo tin nhắn chứ chưa gửi cho ai. Có những cách làm việc đó qua Prismatic hay các hệ thống khác, nhưng anh chỉ muốn làm nổi bật phần build skill.

12. Skill cho việc bạn làm hoài, và guardrails của skill

Brian nói (video đăng ngày 14/10/2026): nếu bạn là developer và có việc gì bạn làm liên tục, hãy viết một skill cho nó; anh không thấy lý do gì để không làm, và bạn giữ nó ở local. Theo anh, cách này cực kỳ hữu ích. Anh còn dùng skill khi upload video lên YouTube: skill chuẩn bị đồ cho anh hoặc lấy context, kiểu "nên dùng hashtag gì đây", vì anh không muốn tự đi tìm. Bạn có thể dựng tất cả những thứ đó bằng skill.

Rồi anh chuyển sang MCP (video đăng ngày 14/10/2026), hỏi "thời gian thế nào rồi?" và tự trả lời "không ổn lắm". Anh sẽ cố đi nhanh nhất có thể; có thể sẽ lố giờ một chút, nhưng không sao, hy vọng là có ích.

Trước khi qua MCP, anh đưa ra vài nguyên tắc cho skill, trên slide "Guardrails" với tiêu đề "Skills guide. They don't enforce." (video đăng ngày 14/10/2026):

• Skill là một gợi ý. Agent vẫn có thể đi lạc khỏi đường (theo slide của Brian, video đăng ngày 14/10/2026).
• Đặt những điều không thể thương lượng vào code. Theo Brian (video đăng ngày 14/10/2026), agent sẽ chú ý tới code nhiều hơn, và code là tất định; slide ghi: schema, validation, các bước tất định.
• Giới hạn thứ nó được chạm vào. Với hallucination và những chuyện kinh dị bạn nghe về AI, skill có thể nói rất rõ ràng; không hoàn hảo, nhưng kiểu "không bao giờ làm cái này, luôn làm cái kia" (theo Brian, video đăng ngày 14/10/2026). Slide ghi: quyền truy cập ít nhất mà vẫn làm xong việc.
• Agent quyết định, hệ thống thực thi. Slide ghi: phán đoán đến từ model, việc thực thi là thứ bạn tin được (video đăng ngày 14/10/2026).

13. MCP là phần "làm": dev tools và MCP vào sản phẩm

Sang MCP, Brian vẫn giữ ẩn dụ "khập khiễng" của mình. Nếu skill là giai điệu thì MCP là phần "làm" (the doing): nó cho AI quyền truy cập để thật sự làm việc trên nền tảng của bạn (theo Brian, video đăng ngày 14/10/2026). Slide "New School, MCP: giving the AI access" ghi: "A skill knows what good looks like. MCP lets the agent actually do it.", bên cạnh là hình cây đàn guitar.

Một điều rất lớn cần nói rõ: anh và nhóm thấy hai hướng chính với MCP (theo Brian, video đăng ngày 14/10/2026).

Hướng thứ nhất là MCP cho dev tools. Nếu bạn muốn một developer, người mà nhiều khi đang dùng coding agent, build được thứ gì đó trên nền tảng của bạn, thì nhiều người đang tạo MCP server, và Prismatic cũng có một cái, để agent có thể "làm X, Y, Z trên nền tảng của tôi": tạo một user trên nền tảng, hay build một integration ngay trong nền tảng. Không chỉ là cách làm, mà làm luôn (theo Brian, video đăng ngày 14/10/2026). Điều anh sẽ nói thêm sau: rất nhiều khi MCP kiểu này là một lớp bọc quanh CLI hoặc SDK. Thật ra, câu hỏi khi cân nhắc MCP làm dev tool là: CLI của bạn tốt tới đâu?

Anh kể như một lời dẫn: ở Prismatic, anh và nhóm vừa build lại skill để mở ra cho nhiều agent hơn chứ không chỉ Claude (video đăng ngày 14/10/2026). Khi làm vậy, anh và nhóm bớt dùng MCP cho nhiều việc, vì Prismatic cũng có một CLI vốn đã tự đăng nhập, tự xác thực và làm mọi thứ khác. Theo Brian (video đăng ngày 14/10/2026), khi chất lượng CLI hay SDK của bạn tăng lên, nhu cầu cần một MCP server có thể giảm xuống. Vẫn chắc chắn có những use case cho nó, nhưng hãy thận trọng. Anh nói với AI, người ta hay thả một thứ như quả bom lên trên mọi thứ, dùng nó cho mọi việc; đây chỉ là điều cần cân nhắc. Nếu CLI tốt, docs tốt, và bạn dùng skill, nhất là khi bạn có cả hai, thì việc bảo trì một MCP server bớt quan trọng đi.

Hướng thứ hai là MCP vào sản phẩm của bạn. Theo Brian (video đăng ngày 14/10/2026), đây là một thứ mạnh, và anh nghĩ nó có nhiều use case hơn và bền hơn: nó cho agent làm những việc đó vào trong nền tảng của bạn. Quay lại ví dụ người làm support ở một nền tảng SaaS đang xử lý một công ty gặp sự cố: giờ người đó có thể thực hiện các thao tác trong nền tảng Prismatic, trong sản phẩm, những thao tác có ích và kích hoạt được các việc khác.

14. Gửi alert qua một flow Prismatic

Brian chuyển sang Prismatic. Để đi xa hơn ví dụ alert ban đầu, giờ mình muốn thật sự gửi alert đó lên Slack. Mình hoàn toàn có thể build một MCP server cho nền tảng của người làm support để gửi tin nhắn Slack đó. Nhưng vì mình là khách hàng Prismatic, mình sẽ dùng một integration flow: kích hoạt flow này, gửi tin nhắn vào qua một webhook, và flow sẽ xử lý nó (demo trong video đăng ngày 14/10/2026).

Ở demo này, anh chỉ thêm một emoji theo mức critical. Nhưng bạn có thể tưởng tượng rất nhiều việc khác được làm ở đây: tạo log, escalate theo cách nào đó, đủ thứ. Với anh, đây là use case hữu ích hơn (theo Brian, video đăng ngày 14/10/2026): một người support kêu lên "trời ơi, vụ này tệ thật, mọi thứ của họ sập hết". Nó đi vào như một trigger, đủ loại quy trình được khởi động, và nó gửi một tin nhắn Slack.

Nhưng với MCP này, điều mình muốn làm trong nền tảng của mình là kích hoạt flow này. Không chỉ là gửi một tin nhắn: mình gửi lỗi đi, khởi động flow đó trong Prismatic, và nó chạy. Anh nhắc lại hai phía của MCP (theo Brian, video đăng ngày 14/10/2026): phía dev tool anh vừa nói, và phía còn lại, nơi mình cho khách hàng truy cập chức năng của mình qua một MCP server và bảo nó "kích hoạt flow này", rồi flow chạy và thực thi thật.

Theo Brian (video đăng ngày 14/10/2026), đây là một cách dùng MCP rất mạnh vì bạn giữ mọi thứ tách bạch và tương đối an toàn. Nhiều vấn đề anh sẽ nói sau biến mất, vì đây là một trường hợp kiểu sản phẩm nội bộ nói chuyện với sản phẩm.

15. Bộ khung MCP server: SDK, Zod và tool

Giờ build một MCP server (demo trong video đăng ngày 14/10/2026). Brian quay lại ghi chú, nói thay vì gõ code thì mình cứ đi thẳng vào. "Màn hình này trông lộn xộn quá", anh nói, rồi lỡ mất chỗ đang làm, chạy lại script và khởi động Claude lần nữa.

Cho demo này, anh đã bỏ qua vài bước. Một điều quan trọng cần biết về MCP server, theo Brian (video đăng ngày 14/10/2026): nếu bạn là người làm kỹ thuật, bạn biết có những thứ như Express server; MCP server là một server. Bạn chạy nó lên như một server, nó ngồi đó chờ yêu cầu và thực thi.

Đính chính của người trình bày: trong buổi live, Brian nói rằng giờ đã có chuẩn cho MCP và Vercel có một chuẩn mới để cài MCP, cài theo kiểu giống một service bình thường bằng npx. Trong phần mô tả video (đăng ngày 14/10/2026), người trình bày đính chính: CLI của Vercel (npx skills add) cài Agent Skills, không phải MCP server.

Thay vì làm hết từ đầu trước mặt mọi người, anh mở file bên trái, lúc đầu nó lại nằm ở cuối trang. "Đây là tất cả những gì cần để dựng một MCP server và cho nó chạy", anh nói, và phải thu nhỏ màn hình cho vừa. Theo Brian (video đăng ngày 14/10/2026), phần lớn ở đây nằm trong ngữ cảnh Express.js làm server, và bạn hoàn toàn có thể để AI dựng việc này cho bạn; anh chỉ muốn chỉ ra vài điểm. Để server sẵn sàng sử dụng, đã có sẵn SDK để tạo MCP server. File mcp-server/src/index.ts trên màn hình:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "alerts", version: "1.0.0" });

// TODO: register send_alert tool here

const transport = new StdioServerTransport();
await server.connect(transport);

Phần import SDK làm cho server chạy được; phần transport là chỗ nó chạy, ở đây là local. Một thứ quan trọng khác là Zod. Brian giải thích đó là một thư viện schema, và nó sẽ quan trọng ở bước sau: thư viện schema tạo ra một data schema cho các tool bạn tạo, vì trong MCP, việc bạn làm là đưa tool cho agent (theo Brian, video đăng ngày 14/10/2026).

Trong demo, tool là alert; với Prismatic hay thứ gì khác, tool có thể là trigger flow, trigger integration flow. Bạn có một loạt tool, và các tool đó có sẵn cho agent. Schema quan trọng vì bên trong nó, như mọi người sẽ thấy, là chỗ bạn nói cho agent biết tool này là gì và làm gì. Theo Brian (video đăng ngày 14/10/2026), giống như cách agent quyết định dùng skill nào, bạn đang cho nó một cách để hiểu nên dùng tool nào, và bạn có thể kết hợp hai thứ đó.

Bên dưới là chỗ sẽ đặt tool send alert (demo trong video đăng ngày 14/10/2026). Những phần khác không quá quan trọng; đây là chỗ tạo server, và mình đặt tên MCP server là alerts.

16. Viết tool send_alert, build và đăng ký server

Brian chạy prompt để build tool, "vì dù sao mình cũng sẽ làm vậy". Anh định phóng to lên cho "to và xấu" lần nữa rồi đổi ý: "mọi người có thể zoom trên Zoom mà, không thì cái tên đó để làm gì". Prompt trên màn hình:

In mcp-server/src/index.ts, replace the TODO with a send_alert tool using registerTool. Read .claude/skills/alert-writer/SKILL.md and match its send_alert call and limits with a strict zod schema. POST the payload plus sentAt to PRISMATIC_ALERT_WEBHOOK_URL and return the HTTP status and any executionId. Support ALERT_DRY_RUN=1, fail clearly if the URL is missing, and never log or echo the URL.

Prompt bảo agent đọc skill. Brian nói đây cũng là một điểm quan trọng (theo Brian, video đăng ngày 14/10/2026): nếu bạn kết hợp skill với MCP server, như anh và nhóm đã làm ở phiên bản đầu tiên của skill Prismatic, bạn có thể nói rõ "mình đang viết cái này để làm gì; tool này là để thực hiện skill này". Agent sẽ có context đó và viết tool tốt hơn. Prompt cũng bảo agent post kết quả lên webhook Prismatic, tức flow anh vừa cho xem: nó sẽ post tới đó, chạy qua flow, rồi trả về trạng thái.

Anh cho chạy, nói có thể mất một chút; nó hẳn có khá nhiều context vì nó thật sự đi vào skill để xem. "Chúng ta chỉ còn khoảng bảy phút, nhưng sẽ ổn thôi", anh nói; ai muốn ở lại thì cứ ở lại, nhưng gần xong rồi, chỉ còn build MCP server rồi xem nó kích hoạt. Agent báo đã có mọi thứ cần thiết và bắt đầu build. Nó hỏi anh một câu ở đâu đó, "thôi nào", rồi nó viết code ngay trước mắt (demo trong video đăng ngày 14/10/2026).

Anh không cho xem nhiều code, chỉ chỉ ra tool send_alert và schema của nó, thứ sẽ nói cho agent biết phải làm gì. Trên màn hình, handler đọc process.env.PRISMATIC_ALERT_WEBHOOK_URL, trả về lỗi isError: true nếu biến này thiếu, dựng payload gồm severity, title, message, integration và sentAt, và nếu ALERT_DRY_RUN bằng "1" thì trả về "[DRY RUN] Alert not sent." kèm payload thay vì gửi (demo trong video đăng ngày 14/10/2026).

Vì đây là một server, việc tiếp theo là build nó: vừa tạo xong thì phải build và cho nó chạy. Lệnh trên terminal:

cd mcp-server && npm run build && cd ..

Build có vẻ đã xong (demo trong video đăng ngày 14/10/2026). Rồi anh nhớ ra phải đăng ký server. Theo Brian (video đăng ngày 14/10/2026), bước này chỉ riêng một số agent cần, không phải tất cả: về cơ bản anh bảo Claude "mình có một MCP server mới, thêm nó vào", đồng thời chỉ cho nó chỗ tìm biến môi trường, để URL webhook không bị định nghĩa ngay trong MCP server mà nằm ở chỗ khác, theo best practice thông thường. Lệnh trên terminal:

claude mcp add --scope project alerts -e 'PRISMATIC_ALERT_WEBHOOK_URL=${PRISMATIC_ALERT_WEBHOOK_URL}' -e 'ALERT_DRY_RUN=${ALERT_DRY_RUN:-0}' -- node mcp-server/dist/index.js

Terminal báo đã thêm MCP server stdio tên alerts vào project config (demo trong video đăng ngày 14/10/2026). Lần tới khởi động, Claude sẽ nhận server này. Anh thoát và khởi động lại. Gõ /mcp để xem danh sách server: "Tuyệt vời", trên màn hình là mục Project MCPs với alerts, trạng thái connected, 1 tool (demo trong video đăng ngày 14/10/2026).

17. Chạy trọn vòng skill + MCP, rồi mang skill sang Codex

Giờ màn hình rộng hơn rồi. Brian lạc sang nhầm cửa sổ một chút, "lỗi tôi", rồi quay lại. Anh gửi prompt "như lúc trước": về cơ bản là nói integration bị lỗi, dữ liệu nằm ở đây, báo cho cả team. Prompt trên màn hình:

Acme's Salesforce sync is failing. Check fixtures/acme-sync-failure.json and alert the team.

Anh mở Slack để theo dõi xem alert có tới không, rồi đọc to "production auth failure". Trên màn hình, Claude đọc file, báo "Now I'll invoke the alert-writer skill with this context.", nạp skill alert-writer, rồi viết rằng đây là một production auth failure với 3 lần lỗi liên tiếp và 1,284 bản ghi đang chờ, đáng alert ở mức critical, và nó sẽ nạp tool send_alert để gửi (demo trong video đăng ngày 14/10/2026).

Ở đây mọi người thấy nó tìm được skill, "hay đấy", anh nói; tất cả là cùng một hệ sinh thái. Nó tìm được skill để xử lý event, tạo tin nhắn, rồi gửi alert. Và "ta-da", trong kênh Slack alert đã hiện ra, mọi thứ ổn (demo trong video đăng ngày 14/10/2026).

Một điều nữa anh muốn cho xem là Codex, tức là các agent khác (demo trong video đăng ngày 14/10/2026). Câu hỏi: cần gì để chuyển một skill của Claude sang một thứ như Codex, sang chuẩn mở? "Tôi hứa đây không phải tất cả những gì chúng tôi làm khi chuyển skill Claude của mình sang mọi agent khác", anh nói, nhưng để anh cho xem. Anh mở một terminal thường. Về cơ bản là copy skill từ chỗ của Claude và dán vào chỗ của Agent Skills. Lệnh trên màn hình:

cp -r .claude/skills/alert-writer .agents/skills/

Sau vài tiếng "whoops" và một câu "geez louise", skill đã nằm trong đó. Anh thoát Codex để chắc nó nhận skill, khởi động lại, rồi đưa đúng prompt skill ban đầu: "Draft a Slack…", "đúng cái này". Trên màn hình là OpenAI Codex v0.152.0, model gpt-5.6-sol (demo trong video đăng ngày 14/10/2026).

Codex báo: đúng, nó ở đây, dùng skill alert-writer vì đây là một integration failure alert, vân vân. Nó cũng kết luận event này đáng một alert critical, và nó còn nhận luôn MCP server, nên có thể sẽ thấy một alert nữa đi qua từ đó. "Hay đấy", Brian nói (demo trong video đăng ngày 14/10/2026).

18. Chỗ MCP rối, quan điểm của Brian, và knowledge + access

Quay lại slide để tổng kết. Về MCP, anh nghĩ mình đã nói phần lớn trong lúc làm, nhưng đây là những chỗ MCP trở nên rối, nhất là trong ngữ cảnh dev tools nhưng cũng nói chung (theo Brian, video đăng ngày 14/10/2026):

• Auth. Auth cho người dùng cuối qua MCP vẫn là một nỗi khổ thật sự; quản lý tất cả các kiểu phân quyền khác nhau là việc khó (theo Brian, video đăng ngày 14/10/2026).
• Scale. Khó scale; "cái gì cũng khó scale", và khi quy mô tăng thì mọi thứ phức tạp hơn. Theo Brian (video đăng ngày 14/10/2026), có được khả năng scale là việc rất khó, "ai biết chút gì cũng biết điều đó". Slide ghi: remote MCP khó scale, và spec liên tục thay đổi để sửa chuyện đó.
• Context bloat. Định nghĩa tool ăn token. Mỗi lần chạy và đi tìm các tool, nó tốn token chỉ để tìm tool, nên mọi thứ có thể phình lên và có thể khá tốn kém (theo Brian, video đăng ngày 14/10/2026).
• Tool sprawl. Điều này cũng có thể đúng với skill: càng nhiều tool, càng nhiều skill, AI agent càng phải suy nghĩ nhiều, vì nó sẽ thấy một skill tên alert team, một skill khác tên alert manager hay gì đó, và phải bắt đầu cân nhắc giữa chúng; mọi chuyện có thể trở nên khó và chông chênh hơn (theo Brian, video đăng ngày 14/10/2026).

Rồi tới "hot take" của anh, trên slide "Our Take on MCP" với ba ô: "Skip it for dev tools", "Use it to open up your product", "Put the hard parts behind it", và dòng cuối "It's the glue for now. Build so you can swap it later." (video đăng ngày 14/10/2026). Ô đầu trên slide ghi "Skip it for dev tools", còn lời anh nói là: anh không nói là bỏ qua nó, nhưng hãy thật cẩn thận với dev tools, cứ xem bạn đi được bao xa chỉ với skill và CLI của mình.

Như anh đã nói, khi build lại skill, anh và nhóm đã lùi lại được một chút (theo Brian, video đăng ngày 14/10/2026). Prismatic vẫn có MCP server cho dev, nhưng anh nghĩ nó sẽ bị deprecate vào một lúc nào đó. Anh và nhóm đã tiến gần tới mức không còn cần MCP nhiều nữa, vì đã có CLI. Còn việc dùng MCP để mở sản phẩm của bạn ra, anh vẫn nghĩ đó là một use case rất, rất tốt, để người ta tương tác với nền tảng của bạn, nhất là nếu bạn là một embedded platform như Prismatic. Và đặt những phần khó ra phía sau MCP, để người dùng và các AI agent không phải làm nhiều việc như vậy.

Một điều quan trọng nữa anh muốn nhấn mạnh (theo Brian, video đăng ngày 14/10/2026): skill riêng lẻ và MCP server riêng lẻ là một chuyện. Nhưng khi kết hợp, như mọi người đã thấy ở cuối, sau khi tạo MCP server, anh gõ cùng prompt như lúc đầu và agent làm được toàn bộ từ đầu tới cuối (demo trong video đăng ngày 14/10/2026). Anh không phải bảo nó dùng MCP server, không phải bảo nó dùng một skill cụ thể; nó tự tìm ra. Theo anh, kết hợp hai thứ đó là lúc bạn có được cách dùng thật sự mạnh trên nền tảng của mình.

Ở phần kết (video đăng ngày 14/10/2026), anh nói đây là những thứ cơ bản để bắt đầu, và hy vọng buổi này giúp mọi người hiểu sẽ bắt đầu thế nào, cũng như sức mạnh của skill và MCP trong việc tăng tốc công việc dev. Anh cảm ơn mọi người đã tham gia.