Cách xây dựng thư viện Skill cho Claude Code

Thư viện skill trong Claude Code là gì và vì sao nên dùng?

Một skill trong Claude Code là một prompt có thể tái sử dụng, được đóng gói thành một quy trình làm việc. Thay vì phải gõ lại hướng dẫn mỗi lần muốn agent lập trình viết một tài liệu yêu cầu sản phẩm (PRD), lên kế hoạch kiến trúc, hay chia nhỏ công việc thành từng ticket, bạn chỉ cần lưu lại quy trình đó một lần dưới dạng skill, rồi gọi ra bằng một lệnh gạch chéo (slash command).

Một thư viện skill đơn giản là một tập hợp các quy trình này được chọn lọc và tổ chức, sao cho mỗi skill khớp với một giai đoạn cụ thể trong quy trình phát triển phần mềm, từ ý tưởng sản phẩm ban đầu cho đến khi code được xuất xưởng và xác thực đầy đủ.

Điểm hấp dẫn của cách tiếp cận này so với một framework agentic trọn gói (như spec kit của GitHub hay các công cụ quản lý toàn bộ vòng đời phát triển phần mềm tương tự) nằm ở tính linh hoạt. Những framework trọn gói thường buộc bạn phải áp dụng toàn bộ quy trình đã được định sẵn. Trong khi đó, một thư viện skill được thiết kế theo kiểu "chọn món" cho phép bạn giữ nguyên những phần trong quy trình hiện có vốn đã hoạt động tốt, và chỉ thay thế những mảnh còn thiếu.

Cách cài đặt thư viện skill cho Claude Code

Với riêng Claude Code, việc cài đặt diễn ra thông qua quy trình plugin marketplace. Bạn chỉ cần chạy một lệnh trong phiên làm việc Claude Code đang hoạt động để thêm nguồn plugin marketplace, sau đó chạy lệnh thứ hai để thực hiện cài đặt thực sự.

Trong quá trình cài đặt, bạn sẽ được chọn phạm vi áp dụng:

• Cài đặt trên mọi codebase bạn làm việc - lựa chọn phổ biến với một lập trình viên cá nhân muốn có cùng bộ skill ở bất cứ đâu.
• Cài đặt chỉ cho repository hiện tại.
• Cài đặt cho cả một nhóm cộng tác viên.

Sau khi cài đặt xong, chạy lệnh /skills ngay trong Claude Code sẽ liệt kê toàn bộ các skill khả dụng, và từng skill riêng lẻ sẽ trở thành các slash command có thể gọi trực tiếp. Gõ một phần lệnh rồi dùng tính năng tự động hoàn thành (tab-completion) sẽ hiển thị gợi ý về các tham số cần thiết, giúp bạn biết trước mỗi skill cần đầu vào gì trước khi thực sự chạy nó.

Với các agent lập trình khác ngoài Claude Code, ví dụ Codex, Copilot hay các công cụ tương tự, quy trình cài đặt không được chuẩn hóa sẵn nhưng vẫn khá đơn giản. Bạn chỉ cần đưa cho agent đường dẫn URL tới kho chứa skill, rồi yêu cầu nó tự cài đặt skill cho đúng công cụ đó. Cách này mất nhiều thời gian hơn một chút so với quy trình plugin gốc của Claude Code, nhưng các skill bên dưới vẫn hoạt động theo đúng cách thức tương tự sau khi đã cài đặt xong.

Outer loop: vòng lặp lập kế hoạch tổng thể trông như thế nào?

Outer loop (vòng lặp ngoài) bao trùm giai đoạn lập kế hoạch ở mức cao nhất, biến một ý tưởng còn thô sơ, hoặc một phần việc tiếp theo, thành một kế hoạch đã được xác định phạm vi đầy đủ và sẵn sàng chia thành ticket.

Bạn chỉ chạy outer loop một lần cho mỗi bộ tính năng hoặc mỗi epic, chứ không phải chạy lại mỗi phiên lập trình, đó là lý do vì sao nó bao gồm ít bước hơn nhưng mỗi bước lại "nặng" hơn so với inner loop.

Bước 1: Viết PRD (tài liệu yêu cầu sản phẩm)

Bước đầu tiên là PRD, một skill PRD nhận đầu vào là một ý tưởng sản phẩm còn lỏng lẻo, sau đó phỏng vấn người dùng bằng một chuỗi câu hỏi được thiết kế để làm rõ, đó là vấn đề cần giải quyết là gì, người dùng mục tiêu là ai, và giả thuyết đằng sau việc vì sao tính năng này đáng để xây dựng. Kết quả đầu ra là một tài liệu có cấu trúc, bao trùm phần "cái gì" và "vì sao", chủ động loại bỏ mọi thảo luận về cách triển khai kỹ thuật.

Ví dụ câu lệnh bạn có thể dùng để gọi skill này:

/prd Xây dựng tính năng cho phép người dùng lưu lại các bộ lọc tìm

kiếm đã dùng để áp dụng lại nhanh trong lần truy cập sau.

Bước 2: Viết spec hoặc kiến trúc kỹ thuật

Bước tiếp theo là spec (tài liệu kỹ thuật) hoặc kiến trúc, và bước này được thực hiện trong một cuộc trò chuyện riêng biệt một cách có chủ đích. Nếu PRD định nghĩa cái gì cần xây và vì sao, thì skill spec sẽ định nghĩa cách làm thế nào, bao gồm kiến trúc kỹ thuật, phương pháp triển khai, và kế hoạch cụ thể để đưa tính năng này vào codebase hiện có.

Việc giữ hai cuộc trò chuyện này tách biệt giúp tránh làm lẫn lộn giữa lý luận về sản phẩm với các quyết định kỹ thuật, trước khi bài toán sản phẩm thậm chí còn chưa được chốt xong.

Bước 3: Chia nhỏ thành ticket

Bước này khép lại outer loop, một skill chuyên biệt sẽ nhận cả PRD lẫn spec làm đầu vào, chia epic thành các ticket có kích thước phù hợp từng phần việc riêng lẻ. Đồng thời ánh xạ các mối quan hệ phụ thuộc giữa chúng và xác định phần nào có thể làm song song cùng lúc.

Bước này còn có thể lấy tài liệu nguồn trực tiếp từ Confluence hoặc các công cụ tương tự thông qua MCP server, thay vì bắt buộc mọi thứ phải nằm trong file markdown cục bộ - điều này rất có ý nghĩa với các nhóm đã lưu trữ tài liệu lập kế hoạch ở nơi khác từ trước.

Inner loop - vòng lặp chiếm phần lớn thời gian làm việc hằng ngày

Sau khi outer loop tạo ra một loạt ticket, dù dưới dạng file markdown, issue trên GitHub, hay ticket trên Jira, mỗi ticket sẽ trở thành điểm khởi đầu cho một inner loop (vòng lặp trong) của riêng nó. Đây chính là nơi tiêu tốn phần lớn thời gian làm việc hằng ngày, đặc biệt với một epic lớn có thể sinh ra tới hàng chục ticket.

Inner loop luôn tuân theo cùng một cấu trúc ba phần cho mỗi ticket, lập kế hoạch, triển khai, xác thực.

Lập kế hoạch trước khi viết code

Agent lập trình được chỉ định vào một ticket cụ thể, và được yêu cầu khám phá phần liên quan trong codebase, rồi đề xuất một kế hoạch triển khai trước khi viết bất kỳ dòng code nào. Bước lập kế hoạch này quan trọng vì nó giúp phát hiện những hiểu lầm về codebase hoặc về phạm vi của ticket, ngay trước khi agent bắt đầu tạo ra code - việc sửa lỗi ở giai đoạn lập kế hoạch rẻ hơn rất nhiều so với việc sửa sau khi một đoạn diff lớn đã được viết ra.

Vì sao xác thực lại quan trọng hơn cả bản thân đoạn code?

Ý tưởng cốt lõi đằng sau cách tiếp cận "xác thực trước" (validation-first) là: việc để một agent lập trình tạo ra một lượng lớn code một cách nhanh chóng chỉ thực sự có ích nếu bạn có cách đáng tin cậy để xác nhận đoạn code đó thực sự làm đúng những gì nó cần làm. Tốc độ mà không đi kèm xác minh chỉ tạo ra nhiều code hơn để xem xét, và nhiều chỗ hơn để các lỗi tinh vi ẩn náu.

Một quy trình xác thực trước sẽ xây dựng bước kiểm tra ngay bên trong inner loop, thay vì coi xác thực như một lượt kiểm tra riêng biệt, tùy chọn, thực hiện thủ công sau khi mọi thứ đã xong. Chính agent đã viết ra đoạn code đó cũng được chỉ định để tự kiểm tra lại kết quả của mình so với yêu cầu của ticket, phát hiện những điểm không khớp trước khi cần đến người xem xét thực sự can thiệp. Đây chính là điều giúp bạn có thể để agent "tự chạy" với mức độ tự chủ thực sự, trong khi vẫn tin tưởng được vào kết quả cuối cùng.

Nếu đã có sẵn quy trình riêng, có nên áp dụng thư viện skill này không?

Câu trả lời là có, theo đúng nghĩa cụ thể: thư viện skill được xây dựng theo hướng dùng từng phần (modular) là để bạn "lấy từng mảnh" chứ không phải áp dụng toàn bộ một cách trọn gói. Nếu bạn đã có sẵn một quy trình hoạt động tốt cho việc viết PRD hoặc lập kế hoạch ticket, bạn hoàn toàn có thể giữ nguyên quy trình đó, và chỉ lấy thêm những phần còn thiếu, ví dụ một skill chia ticket xử lý việc ánh xạ phụ thuộc, hoặc một bước xác thực mà bạn chưa từng chính thức hóa trước đây.

Vì mỗi skill chỉ đơn giản là một mẫu  với các tham số đã được định nghĩa rõ, các agent lập trình có thể đọc một kho skill có sẵn và sao chép những skill cụ thể sang một dự án khác hoặc một công cụ khác với rất ít công sức thiết lập, thay vì phải di dời toàn bộ hệ thống.

Vài lưu ý khi triển khai thư viện skill vào quy trình thực tế

• Đừng gộp PRD và spec vào cùng một cuộc trò chuyện: Việc tách biệt hai bước này không chỉ là hình thức, mà giúp tránh tình trạng các quyết định kỹ thuật (ví dụ chọn công nghệ nào, thiết kế database ra sao) len lỏi vào quá trình xác định xem tính năng có đáng làm hay không.
• Dùng skill chia ticket ngay cả khi bạn đã quen tự chia việc thủ công: Khả năng ánh xạ phụ thuộc và xác định phần việc có thể làm song song thường khó làm chính xác bằng tay, đặc biệt với epic lớn có nhiều ticket liên quan chặt chẽ với nhau.
• Luôn yêu cầu bước lập kế hoạch trước khi agent viết code: Ngay cả với những ticket có vẻ đơn giản. Chi phí sửa sai ở bước lập kế hoạch luôn thấp hơn nhiều so với việc phải xem lại một đoạn diff lớn đã viết sai hướng.
• Đừng coi xác thực là bước tùy chọn làm sau cùng: Gắn bước tự kiểm tra ngay vào trong cùng một luồng làm việc với việc triển khai sẽ giúp agent bắt lỗi sớm hơn, và giảm đáng kể khối lượng công việc review thủ công của con người.

Một số tình huống thường gặp và giải đáp

Khác biệt giữa skill PRD và skill spec là gì?

• Skill PRD định nghĩa cái gì và vì sao: vấn đề cần giải quyết, người dùng mục tiêu, và lý do vì sao tính năng đáng để xây dựng. Skill spec định nghĩa cách làm thế nào: kiến trúc kỹ thuật và phương pháp triển khai. Hai bước này nên được thực hiện như hai cuộc trò chuyện riêng biệt, để lý luận về sản phẩm không bị trộn lẫn với các quyết định kỹ thuật.

Bạn có bắt buộc phải dùng toàn bộ skill trong một thư viện không, hay có thể chọn riêng lẻ?

• Thư viện skill được thiết kế theo hướng dùng từng phần, nghĩa là bạn hoàn toàn có thể "lấy từng mảnh" theo nhu cầu. Bạn có thể chỉ áp dụng một skill duy nhất, ví dụ bước chia ticket, mà không cần thay đổi bất cứ điều gì khác trong quy trình lập trình hiện có của mình.

Skill của Claude Code có dùng được với công cụ khác ngoài Claude Code không?

• Các agent lập trình khác có thể áp dụng cùng những skill này bằng cách được cung cấp đường dẫn URL tới kho chứa skill, rồi được yêu cầu tự cài đặt cho công cụ đó. Cách này mất nhiều thời gian hơn so với quy trình cài đặt gốc của Claude Code, nhưng cho ra kết quả tương tự.

Outer loop và inner loop trong quy trình này khác nhau ở điểm nào?

• Outer loop là giai đoạn lập kế hoạch ở mức cao, chỉ thực hiện một lần cho mỗi epic hoặc tính năng: viết PRD, viết spec kiến trúc, và chia công việc thành ticket. Inner loop là chu trình lập kế hoạch - triển khai - xác thực, được chạy riêng cho từng ticket mà outer loop đã tạo ra.

Vì sao xác thực lại được coi là một bước riêng, thay vì chỉ xem lại code sau khi viết xong?

Việc tích hợp xác thực ngay vào cùng quy trình với triển khai có nghĩa agent lập trình sẽ tự kiểm tra kết quả của mình so với yêu cầu của ticket, như một phần của quy trình, thay vì để con người là người duy nhất phát hiện ra điểm không khớp sau một lượt review toàn diện. Đây chính là điều giúp agent có thể làm việc với mức độ tự chủ cao hơn, trong khi kết quả đầu ra vẫn giữ được độ tin cậy.