Cách build Claude skill cho ngành xây dựng

1. Hơn 100 skill cho ngành xây dựng và một slash command

Tim Fairley mở đầu bằng một con số: anh đã build hơn 100 agent skill cho ngành xây dựng (construction), và phần lớn trong số đó đã trở thành một phần trong quy trình chuẩn (standard process) của các công ty dùng chúng. Trong video này, anh hứa sẽ cho xem chính xác quy trình anh dùng để build skill, đồng thời giải thích vì sao những công ty xây dựng có sẵn một portfolio các dự án đã hoàn thành lại chính là những công ty có nguồn lực tốt nhất để build skill hiệu quả (theo nhận định của anh trong video đăng ngày 02/10/2026).

Trước hết, skill là gì? Với ai chưa quen, Tim định nghĩa skill là một bộ instruction dùng lại được (reusable set of instructions) mà bạn lưu trong ChatGPT, Claude hoặc Gemini.

Anh lấy ngay một ví dụ: skill conceptual estimating (dự toán sơ bộ) của anh. Anh gõ slash command /conceptual-estimate rồi chạy. Điều xảy ra là một bộ instruction dựng sẵn được nạp vào Claude. Vì vậy bạn có thể gọi skill này từ bất kỳ chat nào.

Skill conceptual estimating này chạy đúng quy trình chi tiết mà Tim muốn Claude làm theo khi chuẩn bị một budget estimate hay parametric estimate (dự toán theo chỉ số) cho dự án. Nó xem scope của dự án, hiểu cách dự án được chia nhỏ, rồi tạo ra một work breakdown structure (WBS, cấu trúc phân chia công việc).

Sau đó nó vào cost database của Tim trên Airtable, tìm các đơn giá lịch sử (historic rates) liên quan lấy từ những dự án anh đã làm, rồi gom tất cả lại thành một budget price. Đi kèm là một điểm số chấm độ tin cậy (reliability) và độ chính xác của con số nó vừa đưa ra. Mỗi lần chạy skill này, nó sẽ chuẩn bị đúng một dạng báo cáo conceptual estimating như nhau.

Trong báo cáo đó, skill chia nhỏ dự án, tìm các hạng mục lịch sử có thể so sánh sát nhất, và chấm xem nó tự tin tới đâu về giá đã lập, dựa trên một bộ tiêu chí mà Tim đã build sẵn vào skill. Ví dụ: nếu anh có chi phí dự án lịch sử khớp rất sát với scope of works (phạm vi công việc) của dự án đang làm, và scope đó được định nghĩa rõ trong bộ hồ sơ mời thầu (bid documents), skill sẽ chấm điểm cao. Nếu không có những thứ đó, nó chấm thấp.

Skill còn áp vào đó các khoản lợi nhuận, chi phí chung (overheads) và markup của riêng Tim mà anh đã build vào. Cuối cùng nó cho anh một đơn giá parametric cho toàn dự án, tính trên tổng số mét vuông. Toàn bộ workflow ấy chạy chỉ từ một slash command trong Claude.

Theo Tim, skill quan trọng về bản chất vì bốn điều: chúng làm cho những task ta làm đi làm lại trở nên lặp lại được (repeatable), chúng tiết kiệm thời gian, chúng thêm độ tin cậy cho output, và chúng kiểm soát được chất lượng (performance) của kết quả.

2. Skill khác prompt ở đâu: progressive disclosure

Điểm thứ nhất Tim muốn nói: anh thấy có nhiều nhầm lẫn giữa skill và prompt, nhưng skill khác prompt. Lý do dễ thấy nhất là sự tiện lợi: bạn chỉ cần gõ slash command là gọi được skill tương ứng.

Nhưng ngoài chuyện đó, skill còn chứa những tầng instruction lồng nhau (nested sets of instructions), được mở ra dần dần (progressively disclosed) khi task cần tới. Ví dụ, nếu Tim có một skill viết scope of works, anh có một trang đầu ngắn mô tả quy trình. Lồng bên trong skill, anh có thể để rất nhiều ví dụ cho các loại scope of works khác nhau mà anh muốn viết: một scope of works phần điện (electrical), một scope cơ khí (mechanical), một scope hạ tầng (civil). Tất cả nằm trong các reference file của skill.

Mỗi lần chạy skill scope of works, Claude đọc trang đầu ngắn để hiểu quy trình, rồi chỉ nạp phần context cần cho task. Nếu Tim đang viết scope of works phần điện, nó nạp ví dụ scope phần điện. Nếu anh đang viết scope phần civil, nó đọc ví dụ civil.

Điều này quan trọng vì nó giúp bạn quản lý context window. Nếu thử tái hiện đúng quy trình này bằng một prompt, bạn sẽ có một prompt khổng lồ chứa 15 ví dụ khác nhau, và tất cả bị nạp hết vào context window. Rõ ràng điều đó làm bạn tốn nhiều token và tiền hơn. Nhưng nó còn làm giảm chất lượng của model, vì bạn đang làm bẩn prompt, làm bẩn context window bằng đủ thứ thông tin không cần thiết, không liên quan tới task cụ thể là viết một scope of works phần điện.

3. Skill là file chia sẻ được, thành quy trình chuẩn của công ty

Thêm một lợi ích nữa: skill thực chất là một file mà bạn có thể tải xuống và chia sẻ với team. Như vậy, bạn có thể có cả một thư mục đầy skill, và thư mục đó trở thành bộ standard operating procedure (SOP, quy trình vận hành chuẩn) của công ty bạn.

Sau đó bạn upload chúng vào ChatGPT hay Claude, tùy bạn dùng gì, và nền tảng đó lưu lại thư viện skill (skill library) của bạn.

4. Hai loại skill: tăng capability hay encode quy trình

Trước khi đi vào framework của mình, Tim muốn giải thích có hai loại skill.

Loại thứ nhất là skill tăng năng lực (capacity, capability) của model. Ví dụ, team anh có một skill construction takeoff (anh vừa nói vừa gõ tên skill và đùa "nếu tôi gõ đúng được"). Skill này giúp model làm quantity takeoff, tức bóc khối lượng từ bản vẽ, và nó làm vậy bằng cách cố tăng độ chính xác của model. Skill này cực kỳ khó build: team cần rất nhiều dữ liệu mẫu và phải chạy rất nhiều lượt test trên nó.

Theo Tim, những skill kiểu này, loại tăng capability của model, không chỉ khó build hơn nhiều mà về lâu dài có lẽ cũng không có giá trị bằng. Lý do: model cứ ngày càng tốt lên, năng lực thô của model trong việc bóc khối lượng sẽ tự cải thiện, khiến skill này ngày càng ít hữu ích.

Loại thứ hai là skill encode quy trình của bạn. Vẫn trong skill takeoff đó, Tim đã ghi vào output format mà anh muốn thấy kết quả takeoff. Với anh, anh muốn output là một HTML viewer, nơi anh bấm vào từng khối lượng và thấy trực quan model đã đếm những gì.

Anh cũng đã nối skill này với bộ assembly chuẩn của mình (standard set of assemblies). Nhờ vậy nó biết rằng với mỗi bộ đèn (light fitting) đếm được trên bản vẽ, nó phải tính thêm 10 mét cáp, hai giờ công lắp đặt, và vân vân. Trong skill này, Tim đã encode nơi thư viện assembly của anh nằm và output format mong muốn. Về cơ bản, anh đã giải thích các sở thích (preferences) của mình về quy trình.

Việc này cực kỳ dễ làm. Một khi bạn giải thích preferences của mình, model sẽ tiếp tục làm theo một cách đáng tin cậy, và loại skill này cũng không bị vượt mặt bởi các bản nâng cấp model trong tương lai. Kể cả khi model trở nên thông minh hoàn hảo và bóc khối lượng hoàn hảo, điều đó không có nghĩa là nó sẽ biết file assembly của Tim lưu ở đâu, hay anh thích output format nào.

Tim giải thích sự phân biệt này ngay từ đầu chỉ để nói một điều: nếu bạn định build skill và bỏ thời gian, công sức vào đó, tốt hơn nhiều là tập trung vào skill encode quy trình của bạn, thay vì đầu tư nhiều thời gian và tiền bạc để cố build skill tăng capability.

Với anh, phần lớn giá trị của một skill đơn giản là bỏ thời gian, công sức ngay từ đầu để định nghĩa quy trình: mọi thông tin nằm ở đâu, output format bạn muốn là gì. Rồi chỉ việc ghi lại tất cả, và từ đó gõ lệnh là skill chạy đúng một workflow như nhau, lặp đi lặp lại.

5. Khung tám bước để build skill

Giờ Tim đi qua quy trình anh làm theo, thứ hoạt động rất tốt với anh, để thực sự build skill. Tóm lại có tám bước:

1. Không bắt đầu từ skill, mà bắt đầu từ workflow của bạn.
2. Định nghĩa một task nhỏ và cụ thể cho skill.
3. Tự hoàn thành task đó bằng cách tự prompt.
4. Định nghĩa thật hoàn hảo output format bạn muốn.
5. Build một bộ test để đánh giá (evaluation test set). Đây là chỗ các dự án lịch sử của bạn phát huy giá trị.
6. Viết bản nháp skill.
7. Test và lặp lại (iterate) tới khi skill cho ra output bạn muốn.
8. Đưa vào production: cho mọi người bắt đầu dùng và cải tiến skill liên tục theo thời gian.

Tim nói giờ anh sẽ đi qua từng bước một cách chi tiết, đúng cách anh làm. Trước đó, anh nhắc ngắn rằng ai muốn có thư viện skill dựng sẵn của team anh cùng một roadmap từng bước để áp dụng AI vào công ty xây dựng thì có thể tìm cộng đồng Contractor OS trong phần mô tả video.

6. Bắt đầu từ workflow, không bắt đầu từ skill

Bước một: đừng bắt đầu từ skill, hãy bắt đầu từ workflow. Ý Tim là: một skill chỉ là một task nhỏ, riêng lẻ. Một task chỉ có ý nghĩa nếu nó là một phần của một mục tiêu lớn hơn, hay một chuỗi task lớn hơn, thứ mà anh gọi là workflow.

Với anh, workflow là một quy trình end-to-end nhằm đạt một mục đích cụ thể. Ví dụ, team anh có một workflow pre-construction (giai đoạn trước thi công). Mục tiêu của workflow pre-construction là giúp công ty xây dựng giành được những hợp đồng có lời (secure profitable work). Quản lý chất lượng (quality management) cũng có thể vẽ ra thành một workflow, với mục tiêu kiểm chứng và xác nhận (verify and validate) rằng thứ đã xây là đúng.

Vậy nên mỗi task riêng lẻ chỉ có nghĩa khi đặt trong một workflow lớn hơn. Đây là quy trình pre-construction, và mỗi bước trong đó hoặc do con người làm, hoặc có thể do AI làm.

Ví dụ, team có một skill go / no-go: nó xem bộ hồ sơ mời thầu và giúp bạn đánh giá dự án có hợp với doanh nghiệp của bạn không. Team cũng có một skill pricing schedule: nó nhận bộ hồ sơ mời thầu, tìm xem chủ đầu tư có phát hành một returnable schedule (bảng giá mẫu nhà thầu phải điền và nộp lại) không. Nếu có, nó kiểm returnable schedule đó để chắc rằng bảng bao quát đầy đủ scope. Nếu không, nó giúp bạn soạn returnable schedule của riêng mình để báo giá dự án.

Mỗi thứ trên là một task riêng lẻ. Chỉ khi đã hiểu toàn bộ workflow, ta mới bắt đầu vẽ ra từng skill riêng lẻ là gì. Và khi đã biết mình muốn những skill nào, lúc đó mới bắt đầu build chúng.

7. Skill to hay nhỏ: cắt ở chỗ cần người kiểm

Tim lưu ý quy trình này có phần lặp đi lặp lại (iterative). Bạn sẽ thấy mình bắt đầu bằng bản đồ workflow end-to-end, rồi đôi khi nhận ra đã chia một việc thành quá nhiều skill, trong khi AI hoàn toàn có thể làm nhiều bước cùng lúc. Khi đó bạn có thể gộp chúng lại thành một skill.

Ngược lại, bạn cũng có thể thấy AI làm khá tệ ở một chỗ, và bạn cần tách nhỏ, phân rã (decompose) task đó nhiều hơn.

Nhìn chung, quy tắc của Tim là bắt đầu bằng skill lớn. Điểm để cắt skill ra là: tại chỗ nào bạn muốn có một người trong vòng lặp (human in the loop) kiểm và xác nhận output của AI. Những điểm cắt đó về cơ bản cho bạn các bước riêng lẻ.

8. Tự làm task bằng prompt trước khi viết skill

Khi đã định nghĩa xong workflow tổng thể, bước tiếp theo không phải là bắt tay soạn skill, mà là tự hoàn thành task qua instruction và prompt cơ bản.

Giả sử Tim vào workflow của mình, và bước đầu trong quy trình là: khi ra quyết định go / no-go, anh muốn AI chuẩn bị một parametric estimate cho dự án. Khi muốn bắt đầu build skill cho việc này, điều anh thực sự làm là giải thích cho AI, hay đơn giản là prompt AI làm việc đó.

Anh thừa nhận điều này phụ thuộc phần nào vào khả năng prompt và hiểu cách AI hoạt động của bạn. Nhưng thật lòng, thứ anh bắt đầu chỉ gồm ba câu hỏi: input context nó cần là gì, quy trình bạn muốn nó làm theo là gì, và output format bạn muốn là gì. Với task conceptual estimating, anh có thể bắt đầu bằng một prompt như thế này (trên màn hình, trong chat "Parametric project estimate" của project mẫu):

I want your help preparing a parametric estimate for the project.
To do this task, you will need to:
1. Go to my historic cost library, which is saved in Airtable. You can access this via the Airtable MCP.
2. Look at the current project documentation and create an initial work breakdown structure for the project.
3. Look at each activity in the work breakdown structure and compare this to my historic cost library. Match each activity to my best historical costs.
4. If there is good information in the project documents and good historical cost information, score this as a high-reliability cost.
5. If there is not good historical cost information and there is not very good information in the project documents, score this as low reliability.
The goal isn't to prepare a detailed lump-sum estimate. The goal is to create a rough order-of-magnitude price that tells me roughly how much the project is going to cost and what the rough breakdown of that price is. The output should be in Excel.

Nói cách khác: dùng kho chi phí lịch sử trên Airtable qua Airtable MCP; tạo work breakdown structure ban đầu từ tài liệu dự án; so từng hạng mục với kho chi phí và ghép với chi phí lịch sử khớp nhất; nếu tài liệu dự án và dữ liệu chi phí lịch sử đều tốt thì chấm là chi phí độ tin cậy cao, nếu cả hai đều không tốt thì chấm độ tin cậy thấp. Mục tiêu không phải là một bản dự toán trọn gói (lump sum) chi tiết, mà là một mức giá cỡ độ lớn (rough order of magnitude) cho biết dự án tốn khoảng bao nhiêu và giá đó chia ra sao. Output phải ở dạng Excel.

Đó sẽ là chỗ Tim bắt đầu. Rõ ràng đây là skill anh đã nghĩ và thử nghiệm rất nhiều, nên anh viết nhanh được một prompt như vậy. Nhưng khi bạn mới bắt đầu hướng dẫn model làm việc này, anh khuyên đơn giản bắt đầu bằng ba thứ đó: input context nó cần, quy trình bạn muốn nó theo, và output format bạn muốn. Về cơ bản, bạn hướng dẫn model theo khung đó, rồi suy nghĩ thật kỹ: nó cần thông tin gì, thông tin nằm ở đâu, các bước trong quy trình là gì, và output là gì.

Sau đó Tim trao đổi qua lại với model để chỉnh cấu trúc này cho đúng, đưa kết quả về output format anh muốn, và ra được một câu trả lời hợp lý.

9. Output format là phần quan trọng nhất

Từ đó đi tới bước tạo ra một output mẫu chất lượng thật cao (Tim gọi đây là bước ba ở đoạn này). Bước này chủ yếu là để output format đúng, và theo anh bạn làm việc đó ngay trong lúc đang prompt model. Nhưng output format là phần quan trọng nhất của bất kỳ skill nào.

Tim dừng prompt đang chạy lại vì anh không thực sự muốn nó chạy hết, rồi nhấn mạnh: khi mới tạo một skill, điều quan trọng nhất, anh không thể nhấn mạnh đủ, chính là output format là gì.

Ví dụ, nếu bạn làm bid leveling (so sánh, cân bằng các báo giá thầu): chính xác thì bạn muốn nó làm bid leveling thế nào? Bảng nào bạn muốn nó điền? Với Tim: anh muốn nó liệt kê main pricing schedule (bảng giá chính), anh muốn ba báo giá nhà thầu nằm thành các cột dọc phía trên, và anh muốn các điều khoản loại trừ (exclusions) của từng nhà thầu nằm ở dưới cùng.

Vì vậy khi prompt ban đầu, anh gần như tập trung vào output format mong muốn, tức cấu trúc và phong cách của output, nhiều hơn là đánh giá độ chính xác tổng thể của task. Tất nhiên bạn vẫn cần hiểu task, nên chạy nó trên một dự án đã hoàn thành trước đây.

Bid leveling là ví dụ tốt cho việc này. Nếu bạn biết trên một dự án cũ đã có người làm bid leveling cho một gói thầu nhất định, đó chính là loại ví dụ Tim sẽ dùng để thử. Về cơ bản, bạn cứ prompt model tới khi ra được output format mình muốn.

10. "Can you please turn this into a skill": bản nháp skill

Khi đã có output format đúng, ngay trong chính chat đó, bạn tạo bản nháp skill. Theo Tim, tạo một skill dễ tới khó tin: tất cả những gì bạn nói với model là "bạn có thể biến cái này thành một skill không". Chỉ đơn giản vậy là có bản nháp.

can you please turn this into a skill

Tim lại dừng lần chạy này vì không muốn nó làm thật. Ý chính: qua cuộc trò chuyện đó, bạn đã nói rõ input là gì, output format là gì, và chính cuộc trò chuyện đã ghi lại quy trình của bạn, kể cả cách bạn sửa model. Vì vậy, rất quan trọng là làm việc này trong cùng một cuộc trò chuyện.

Khi bảo model biến chat thành skill, Tim nói rõ thêm vài điều. Thứ nhất, bạn nêu rõ muốn một skill chung (generic) dùng được cho nhiều dự án.

Điều tiếp theo thực sự rất quan trọng, nhất là với các model mạnh hơn như Opus 5.5, Fable 5 hay GPT-6 Astra (những model Tim nêu tên trong video đăng ngày 02/10/2026): bạn không muốn model viết quá nhiều instruction.

Anh giải thích điều đã xảy ra khi các model mới ra mắt, và nó cũng tùy phần nào vào model bạn định dùng cho task. Với phần lớn task quản lý xây dựng, anh dùng Opus hoặc Fable, hoặc model tương ứng như Astra nếu bạn dùng ChatGPT hằng ngày, vì bạn muốn một reasoning model làm việc này. Anh gần như không bao giờ dùng Sonnet hay Haiku cho task xây dựng, vì bạn thực sự cần khả năng suy luận.

Nhưng đặc điểm của các reasoning model này là chúng rất giỏi tự suy ra mọi thứ. Điều xảy ra là khi bạn bảo model biến một thứ thành skill, nó có xu hướng ghi lại quá nhiều thông tin và mô tả quy trình quá chi tiết (over specify).

11. Chỉ viết instruction tối thiểu: các quy tắc cho model Claude 5

Tim nói team anh đã test rất, rất nhiều để kiểm chứng điều này, và nó khớp với những gì Claude và ChatGPT đang nói (tính đến lúc video đăng, 02/10/2026): bạn muốn skill chỉ có lượng instruction tuyệt đối tối thiểu. Bạn không muốn nhồi thêm mãi instruction vào model.

Vì vậy, khi bảo nó build skill, rất quan trọng là bạn nói rõ: chỉ instruction tối thiểu đủ dùng (minimum viable instructions), chỉ những thứ thật sự cần thiết, tuyệt đối cần thiết.

Anh mở một bài Substack hay mà anh đã đọc về chủ đề này và nói sẽ để link trong phần mô tả. Bài viết ("6 rules for prompting Claude 5 models", tổng hợp từ các hướng dẫn của Anthropic và buổi nói chuyện của Boris Cherny, Head of Claude Code, tại Y Combinator) có nhúng video với tiêu đề "We Cut 80% of Claude Code's Prompt". Tim tóm lại: điều thú vị là Claude nói rằng với các model mới, họ đã cắt 80% system prompt và điều đó làm model chạy tốt hơn (theo video đăng ngày 02/10/2026). Bài viết chia nhỏ những gì thực sự nên có trong prompt và skill của bạn.

Quy tắc 1: định nghĩa "xong" trông như thế nào (define what done looks like). Đó chính là chuyện output format ta đang nói. Quay lại hai loại skill ở trên, đây đơn giản là ghi lại preferences của bạn về output format. Ta trao đổi qua lại với Claude, ghi lại output format mình muốn, rồi đảm bảo output format đó nằm trong skill. Như vậy ta định nghĩa khi nào task kết thúc và output mong muốn ra sao.

Quy tắc 2: định nghĩa toàn bộ công việc ngay ở front matter của skill. Phần mở đầu của skill nên nói, ví dụ: "nhiệm vụ của bạn là hoàn thành quantity takeoff cho dự án này, toàn bộ quantity takeoff", hoặc "việc của bạn là chuẩn bị một parametric estimate cho tổng giá trị dự án". Nhất là với các model thông minh hơn, thay vì chỉ bảo nó làm một task cụ thể mà không có bối cảnh rộng hơn, lỗi người ta hay mắc là mô tả quá chi tiết và định nghĩa từng bước, mà không định nghĩa task tổng thể là gì. Một lần nữa, model rất thông minh nên tự suy ra được nhiều thứ.

Quy tắc 3: đừng đưa những instruction thừa. Theo Tim, đây là chỗ instruction bị phình (bloated): những câu như "double check your answer", "think step by step" hay "explain your reasoning". Chúng từng hiệu quả với model cũ, nhưng giờ đã được chứng minh rõ ràng là không hiệu quả, và nếu có thì còn làm giảm chất lượng model, vì bạn can thiệp quá mức vào cách nó làm task. Trên màn hình, mục "3. Stop asking it to double check" của bài viết giải thích Opus 5 và Fable 5 đã được train để tự kiểm, tự xác minh và tự sửa lỗi; thêm instruction đó chỉ là thêm một bước kiểm thứ hai, tốn thêm chi phí mà lợi ích chưa được chứng minh.

Quy tắc 4: cho model hiểu bối cảnh, tức vì sao nó làm task này. Với conceptual estimating: "nhiệm vụ của bạn là chuẩn bị một conceptual estimate mà tôi sẽ dùng để đánh giá dự án ở giai đoạn đầu". Khi nói cho model lý do (the why), nó hiểu tốt hơn cách làm task.

12. Thay hard rule bằng lý do: bài học từ skill takeoff

Quy tắc 5: thay hard rule bằng lý do (replace hard rules with reasons). Tim nói đây là điều anh thấy thực sự rất hiệu quả.

Ví dụ: khi build skill construction takeoff, anh để ý nó cứ đo hụt, cắt ngắn các phép đo. Anh thử cách nói "bạn luôn phải đo mọi thứ", nhưng chiến lược đó không thực sự cải thiện kết quả.

Thứ thực sự cải thiện là nói cho nó mục tiêu, tức đưa ra lý do: mục đích của việc này là hoàn thành một bill of quantities (bảng khối lượng), và mục đích của bảng khối lượng là để anh lập được bản dự toán. Anh cũng đưa cho nó một ví dụ về chỗ nó đã đo hụt và vì sao điều đó tệ. Khi build skill takeoff, chiến lược đó hiệu quả hơn hẳn so với chỉ nói "hãy đảm bảo đo mọi thứ".

Về cơ bản, những bước trên cho bạn bản nháp skill. Bạn chỉ cần bảo Claude hay ChatGPT lưu skill lại, và sau đó bạn truy cập được nó trong thư viện skill của mình.

13. Bộ test từ các dự án đã làm xong

Việc tiếp theo Tim làm là build bộ test để đánh giá (test evaluation set). Cách làm: anh tìm những dự án trước đây đã từng làm đúng workflow đó. Anh lấy input của task, và lấy output thực tế mà dự án đã có, tức kết quả task đã làm đúng.

Một lần nữa, anh nói đây là lý do anh cho rằng các công ty xây dựng có sẵn dự án đã hoàn thành chính là những người có nguồn dữ liệu tốt nhất để tùy chỉnh và khai thác tối đa các skill này (nhận định của Tim trong video đăng ngày 02/10/2026).

Bạn tìm thật nhiều ví dụ cũ. Theo Tim, năm ví dụ thường là quá đủ, ít nhất cho vòng cải tiến thứ nhất. Bạn tìm năm ví dụ, lấy input context và output, tức kết quả mong muốn. Bạn chỉ đưa cho Claude phần input context. Bạn chạy skill trên dự án đó, xem output format Claude tạo ra, và so với kết quả mà bạn biết là chính xác.

Ví dụ, giả sử team đang build một skill bid leveling. Tim tự sửa lại tên: anh gọi nó là subcontract quotes analysis (phân tích báo giá thầu phụ). Với skill đó, cách làm là đưa cho Claude bối cảnh dự án và ba báo giá, bảo nó thực hiện phân tích báo giá thầu phụ và chạy skill. Rồi ta xem output nó đưa ra so với output đúng thực tế của dự án.

Ta dùng kết quả so sánh đó để ghi lại những gì nó làm sai. Cũng có khi nó còn làm tốt hơn cả cách team đã làm trên dự án thật. Nhưng về cơ bản bạn xem nó sai chỗ nào so với kết quả thực tế: nó có đưa ra quá nhiều exclusions không, các exclusions có bị định giá sai không.

Điều lớn nhất Tim thấy model hay làm là đưa quá nhiều thông tin và làm quá đà. Nên anh thấy gần như chắc chắn bạn sẽ phải sửa lượng output.

14. Ví dụ phân tích báo giá thầu phụ và các edge case

Tim mở format subcontract quote analysis của team. Lần đầu chạy, skill không trả lời gọn trong một trang. Nó tạo ra một workbook bảy tab cho mỗi lần phân tích báo giá, quá nhiều thông tin.

Vì vậy team giới hạn output. Họ quy định rõ bảng pricing schedule nằm ở trên, exclusions nằm ở dưới. Trên màn hình là bảng Excel so sánh hai báo giá cho gói vách ngăn, trần và cửa: mỗi hạng mục có khối lượng, đơn vị, đơn giá và thành tiền của từng nhà thầu cùng cột chênh lệch; bên dưới là phần levelling adjustments, các điều chỉnh để đưa hai báo giá về cùng scope, kèm cột evidence giải thích. Dòng hướng dẫn trên đầu bảng nhắc so sánh tổng đã điều chỉnh chứ không so giá tiêu đề, vì con số rẻ nhất mà có nhiều exclusions nhất lại là con số đắt nhất.

Khi đã test skill, team xem các exclusions thực tế đã được phát hiện trên dự án thật so với những gì AI phát hiện. Nó có bao quát hết không? Nó có bỏ sót gì không? Nó có đưa báo giá vào đúng format không? Nó xử lý thế nào khi một nhà thầu không báo giá theo đúng format?

Điều bạn sẽ thấy là khi đi qua các ví dụ dự án cũ, bạn gặp đủ mọi edge case lộn xộn, và bạn thực sự thấy AI làm ra sao so với kết quả đã được làm đúng.

Rồi về cơ bản, mỗi lần AI làm điều gì bạn không thích, bạn lặp lại và cải tiến. Bạn nói cho AI nó đã sai ở đâu và bảo nó liên tục cập nhật skill. Dần dần bạn sẽ có được kết quả gần như mong muốn.

15. Khi skill không cho ra kết quả mong muốn

Nếu vẫn không ra kết quả mong muốn, Tim gợi ý vài khả năng. Có thể bạn đang giao cho AI một task quá phức tạp mà nó không làm được một cách đáng tin cậy. Có thể bạn không có input context cần thiết.

Ví dụ, nếu bạn muốn build skill conceptual estimating, bạn cần một thư viện thật tốt về chi phí các dự án lịch sử đã hoàn thành, hoặc các bản dự toán lịch sử mà bạn tin được. Nếu không có thư viện đó, bạn không thể thực sự tạo ra một skill làm được việc này. Vậy có thể có một vấn đề mang tính hệ thống hơn: bạn không có dữ liệu để chạy workflow.

Hoặc bạn có thể phải chia skill nhỏ hơn nữa, giao cho nó một task nhỏ hơn, cụ thể hơn mà bạn có thể kiểm chứng.

Cuối cùng, khi chạy quy trình này đủ nhiều, bạn sẽ có output mong muốn và về cơ bản đã build xong skill hữu ích thứ nhất. Tóm lại: test, cải tiến, test lại, đưa về đúng format mong muốn.

16. Đưa vào production và chọn người giữ skill

Sau đó có thể đưa skill vào production, nghĩa là chia sẻ với team và cho họ chạy trên dự án thật. Tim kèm một lưu ý rất lớn: rõ ràng bạn muốn mọi người kiểm lại output skill tạo ra. Đồng thời, theo thời gian, mọi người có thể đưa feedback và cải tiến skill từng vòng. Mỗi lần skill được chạy trên một dự án là một cơ hội để mọi người góp thêm feedback.

Cách Tim khuyên quản lý thư viện skill trong thực tế: có một người sở hữu (owner) các skill. Có thể là một người cho mỗi bộ phận (function): một người quản lý toàn bộ skill procurement (mua sắm, đấu thầu thầu phụ), một người quản lý toàn bộ skill pre-construction. Mọi người gửi feedback cho người đó, người đó tổng hợp feedback và cải tiến skill, thay vì mỗi người tự chạy một phiên bản riêng của skill và tự sửa theo ý mình.

Tim kết lại: đó về cơ bản là toàn bộ quy trình end-to-end anh dùng để build các Claude skill hiệu quả. Ai muốn xem chi tiết hơn về cách build những workflow tạo ra giá trị thì anh gợi ý xem tiếp một video khác của kênh.